oh you mean "one can make an event without changing any wld file", that's true and of topic.
regvn, pls describe the type of portal you want to use (its appareance) and its location, I will make the change for you (and may be you wanna do it for a dark map as well).
regarding details:
- from your picts, the first portal is defined by a shape (the "Portal_Out.smod" file) and an effect (the 22nd in the world_a1.eft file); the second is only materialized by an effect (most of recent maps use these rifts-like portals).
- the portal definition can also include a named area that displays a name when the mouse is over it, I included one and set it to "Deep-Desert2", you can provide your own description with a new comment in the world/1.txt file with the tag number 66
Also note that I've used the "last but one" OS map that provides 2 portals to Cornwell's Ruins (the standard one, map 5 and the new -dread- relooked one (map 82)) - I didn't use the very last map with the 3 new portals to dungeon 55, 60 & 65+ in the middle of Keo.
regarding target of portal, the wld file contains a destination but only the one defined in the server sided 1.svmap file is relevant, you must edit your file and insert a new (#8) record.
(as an example, here is a valid def for all portals defined in the 1.wld file)
if the portal is linked to a mob / boss you will use an unique faction identifier bigger than 1000 (instead of the 1 listed above) and you will edit the map.ini file (edition of 1.svmap is still required).
have fun with your new map - original & creative idea are quite scarce.
Is the wld file 'packed' somehow? (dont know how to explain it)
I mean, I was trying to figure out the structure (data types lenght) and those stuff, to be able to hex insert new models in an existant wld. And that way, taking a map, deleting the buildings/shapes and adding other buildings, so it would be an 'original' map, diferent from the ones we're used to.
Does every wld (FLD) file have the same internal structure?
I've tried searching for 'patterns', counting bytes and so but, (If I got right) DUN files are made of 3d objects from the Entity folder, while FLD must also have topographic info somewhere inside the WLD file, and I have no idea how to seek where that data start and end (to separate the tophografic data, from the entities data). And of course I dont know how 'real' data types (e.g. coordinates 0.00) are stored in Hex.
ok, you are in the right way and your assumptions are correct.
The wld files start with an 32-bit identifier, 'DUN\0' for dungeon, 'FLD\0' for "field-map".
The sole difference between these 2 formats is the description of the global scene.
All data are little-endian encoded, they are wintel data (the previous idents were reversed).
All following integers and floats are read using little-endian encoding.
All floats are simple-precision floating values as per IEEE 754, with most of languages you simply read a float4 or read 4 bytes and cast the address of them to the address of a float4.
The file also contains string, they are - for the wld files - defined on 256 bytes, aligned at left of buffer (string starts at offset 0), they are not length prefixed, they are zero-terminated, all remaining bytes (until offset 255) are garbage random data. let's call such block a "String256".
For field-map, there is, as you assume, a topographic block, it starts with the map-size (int32), it is 1024 or 2048.
Then comes a map-height, meaning "something" that describes the height of the ground for each point of the mesh; I don't success to understand it (it the last unknown part) but its size is constant and is equate to 0x000C0C03 if size is 1024 and 0x00301803 if size is 2048.
These figures equate to: 0803h + 0C0400h and 0803h + 301000h = 0803h + 4 * 0C0400h.
(and a map with a side of 2048 is of course 4 times larger than one with a 1024 side)
the meaning of the header (0803h bytes) and the coding of "heights" is unknown. (so no way to build a new terrain).
May be someone fluent with maps generator softs can understand these data and/or gives advices based on common practices in this domain.
The FLD maps also contain some "texture-sound" couple (I didn't invest to get their purpose).
The block consists in:
- number of records: int32
- record:
String256 name of a tga file (of course actual file is a DDS)
float4 unknown (0x00000041 and 0x00008040 are frequent)
String256 name of a wav file
After that point the structure of FLD & DUN files are the same. Here are some additional information:
The first item is a String256, for FLD it's a .wtr file (water definition that defines apparently the "sea" under the map-height), for DUN it is a .dg file that defines the dungeon geometry (a new kind of stacks of layers, far most complicated than smod, and using yet another vertex formats).
Then come 7 blocks, each defines an array of smod files stored in a specific subfolder of "./Entity" (or world/dungeon) and an array of vertices (that defines where & how the shape is inserted).
All these blocks share the same format:
- number of strings to follow: int32
- n * String256, smod filename to be read from Building, Shape, Tree, Grass, Vani (x2), world/dungeon, Mani
- number of vertices to follow, int32
- vertices as:
- index of a smod, int32
- coords x1, y1, z1, float4
- coords x2, y2, z2, float4
- params k,m,n, float4
(the meaning of parameters depends of the block, for most of them it seems to be some orientation and azimut).
That is not the full structure but it should help you to go further in your coding.
float4, that's what I was looking for. I didn't understand how to convert them to decimal and reverse yet (I barely can use VB.net which isn't that good), but with all that info I'll have fun investigating what a wld is made of.
float4, that's what I was looking for. I didn't understand how to convert them to decimal and reverse yet (I barely can use VB.net which isn't that good), but with all that info I'll have fun investigating what a wld is made of.
Update:
I update this since it doesn't worth making a new thread about.
I've been doing some tests with python about the wld format (using the info Castor gave us).
I've used 35.wld for the test. (Apulune)
The terrain data starts at byte 8 and finish at byte C0C0A (has a lenght of C0C03).
It seems those bytes indicates point heights, but I don't know if they are Int or Float values.
I've tested using Int values, with a value of 38 (wich is just above the water level).
So, you replace that block of bytes (0x00000008 to 0x000C0C0A) and fill them with 26 (38 dec), and you get a flat terrain like this one:
Of course thats useless, since you still have to manually adjust the position of buildings, trees, rocks, etc
Another test I made was making a grayscale bitmap in photoshop (1024x1024), then hex edited that bitmap, and copied the byte values and pasted them in the terrain block data.
The result was this:
The levels are too rough make a playable terrain. But I asume the problem is that I don't know what kind of values goes there, int or float.
I still can't understand the wld format past the SMOD blocks. Theres a .wrt file, then a lot of data (may be vertex info), some .wav files, a few dds files (for Sky definition I think), and the file ends. And understanding that, would make posible to create an original .wld map from scratch.
I'm sure the guy who made shaiya-edit (python), would know better how to get this done. I'm just too noob at coding. And sadly Castor is gone.
Hope this helps anyone (still) interested in old SHaiya.
I'm still searching a way to read a bitmap grayscale value and translate to a map height value in python. But sadly PIL and Numpy won't work on my Win7 x64, no matter what.
Some asked how to print to a file instead of console:
logfile = open("log.txt", "w")
#then replace PRINT var with PRINT >> logfile, var
#example:
print >> logfile, '------------------------line of text-------------------------------'
xyz = struct.unpack('fff', wld.read(12)) #XYZ
print >> logfile, 'X Y Z:', xyz
To run python scripts, save the code as 'mifile.py', and do 'python mifile.py' on a DOS windows
Or use Sublime Text, a free notepad-like code editor, pressing CTRL + B will run the code (of course you need python installed). Just take a look at those shaiya_edit python scripts posted here at epvp and you'll see how it works.
I've made a script to change a building/object/plant location in a map, but I find it useless, what I want is to insert/delete an object.
Very good work there Sominus. Nice to see you worked hard at it for so long and came up with some great results from it all. Should be very useful to those wanting to edit / add their own portals, or to actually study / understand how the files are made up.
-Header
-Map Size
-TerrainData
-Entities: (Smod filenames + location coordinates. They include smod files and vani, mani. The last 2 are for animated entities.)
-EFT file and vertex (it includes coordinates where each effect will show in game.
After that, some maps have wav sounds, some others doesnt. And I dont know how to determine where to insert the next block (portals and named areas). So far all attemps just end up in DC (map read error).
And for topography data, it seems that values are in pairs (?).
This is from a terrain data:
Code:
22 24 B5 24 E9 24 4C 25 E5 25 AB 26 8E 27 72 28 26 29 9B 29
If you read them in pairs, look how every 2 values, they are close values:
eg. 24.....25.....26....
I've tried to read them as floats, but the resulting numbers made no sense.
My guess is the terrain is built up from basic triangles (as opossed to squares).
If you're fluent with C#+WPF you can use this tuto for rendering vertex. It also has an intro to 3D structures:
The point is, try to read the terrain data (in diferent ways/formats) so that WPF code would render the vertex.
I've tried but it was to **** slow on my comp.
PS: Would love some Castor hints about the structure past the .EFT section :P
Nice work Sominus; your tries regarding the map-height data are very interesting!
The topography demo in the WPF sample also gives some generic info, unfortunately not linked to deeper explanations that could help to understand the shaiya-cooking.
Regarding the .wld format, your info are correct; here is the whole structure of the WLD files (some so nice old plain C):
// a 1-byte unsigned value
typedef unsigned char byte;
// string with fixed length of 256 characters,
// no length-prefix, a single zero-terminal (plus garbage)
typedef char String256[256];
// array of names
struct Names {
long count; // number of names to follow
String256* names; // array of Str256
};
// 3D point, float based
struct fPoint {
float x, y, z;
};
// coordinates to place a 3D object in a field
struct Coordinate {
long id; // id of a 3D model (whose filename is in the linked Names)
fPoint pos; // position to draw the given model
fPoint pt2, pt3; // possibly rotation & scaling matrixes (pt2 vary, pt3 is quite always (0,1,0)
};
// array of Coordinate
struct Coordinates {
long count; // number of records to follow
Coordinate* coord; // array of Coordinate
};
// coordinates to place a 3D object in a field, used by 'MANI' items only
struct Coordinate2 {
long unk; // unknown
long id; // id of a 3D model (whose filename is in the linked Names)
fPoint pos; // position to draw the given model
fPoint pt2, pt3; // possibly rotation & scaling matrixes (pt2 vary, pt3 is quite always (0,1,0)
};
struct Coordinates2 {
long count; // number of records to follow
Coordinate2* coord; // array of Coordinate2
};
// an area in which a music is played
struct MusicZone {
fPoint pt1, pt2; // coordinates of the area (which is always rectangular)
float unk1; // quite always 0.0f
long id; // id of the .wav file within the linked Names list of files
long unk2; // quite always 0L
};
// array of MusicZone
struct MusicZones {
long count; // number of records to follow
MusicZone* zones; // array of MusicZone
};
// ZoneList
struct ZoneList {
fPoint pt1, pt2; // coordinates of the zone
long count; // number of idents to follow
long* idents; // array of identifiers
};
// array of ZoneList
struct ZoneLists {
long count; // number of records to follow
ZoneList* list; // array of ZoneList
};
// a circular area in which a music is played
struct MusicSpot {
long id; // id of the .wav file within the linked Names list of files
fPoint pt; // center of the spot area
float dist; // radius of the area
};
// array of MusicSpot
struct MusicSpots {
long count; // number of records to follow
MusicSpot* spots; // array of MusicSpot
};
// coordinates where an effect takes place (is rendered)
struct Vertice {
fPoint pos; // position to draw the given effect
fPoint pt2, pt3; // possibly rotation & scaling (pt2 vary, pt3 is quite always (0,1,0)
long id; // ident of effect within linked .eft file
};
// array of Vertice
struct Vertices {
long count; // number of records to follow
Vertice *verts; // array of Vertice
};
// Portal
struct Portal {
fPoint pt1, pt2; // portal-area
long unk1; // quite always 0L, possibly condition to use the portal
String256 s1, s2; // not localized string (likely Korean info, name of dest map, ...)
byte map; // identifier of target map
short faction; // id of faction that can use the portal
byte unk2; // quite always 0
fPoint pt3; // location of move in target map
};
// Spawn Area (area where toons are moved)
struct SpawnArea {
long unk1; // quite always 1
fPoint pt1, pt2; // the area
long unk2; // quite always 0
long cntr; // country indicator
long unk3; // quite always 0
};
// Named Area (an area owning a name displayed when one enters the zone)
struct NamedArea {
fPoint pt1, pt2; // the area
long unk1; // quite always 0L
String256 s1; // conditionnal name of a file from Interface\worldname
String256 s2; // comment or filename ?? (unlocalized - Korean)
long mode; // 2: s1 defines the bmp-file for area name, 0: the caption is read from <world_index>.txt
long unk2; // quite always 0L
};
// NPC definition
struct NPC {
long type; // NPC's type
long typeID; // index in type
fPoint pt; // position
float orient; // orientation ([0..2Pi[)
long cntAltPos; // number of alternate positions to follow
fPoint* altPos; // array of alt. pos., the NPC moves across these pts if any
}
struct World {
long wType; // "DUN" or "FLD" if read as char[4]
// if wType == 'FLD\0'
// map-field
long mapSize; // 1024 or 2048 for all seen .wld
unsigned char* mapHeight; // 0x0C0C03 bytes if mapSize is 1024, 0x301803 bytes if mapSize is 2048
// .tga, .wav couples
long count; // number of records to follow
struct TextSound {
String256 tgaName;
float unkwn; // 4.0 & 8.0 are usual
String256 wavName;
} *texSound;
// endif wType == 'FLD\0'
// common parts
String256 inner; // "inner layout", ".wtr" (water) for a field, ".dg" for a dungeon
// .smod objects present in the field
// modules from Entity/Building
Names buildNames; // array of .smod files
Coordinates buildCoord; // location of buildings
// modules from Entity/Shape
Names shapeNames; // array of .smod files
Coordinates shapeCoord; // locations of shapes
// modules from Entity/Tree
Names tree_Names; // array of .smod files
Coordinates tree_Coord; // locations of trees
// modules from Entity/Grass
Names grassNames; // array of .smod files
Coordinates grassCoord; // locations of grasses
// modules from Entity/Vani
Names vani1Names; // first array of .smod files
Coordinates vani1Coord; // first locations of "vani"
Names vani2Names; // second array of .smod files
Coordinates vani2Coord; // second locations of "vani"
// module from World/dungeon
Names dungnNames; // array of .smod files
Coordinates dungnCoord; // locations of dungeon
// modules from Entity/Mani
Names mani_Names; // array of .smod files
Coordinates2 mani_Coord; // locations of "mavi" ** 1 additional long per record
// visual effects
Name effctFile; // name of file defining effects (from Effect folder)
Vertices effctVert; // location of the effect
// unknown
long unk1, unk2, unk3; // 3 unknown longs, always zero
// modules from Entity/Object
Names objctNames; // array of .smod files
Coordinates objctCoord; // locations of objects
// waves from Sound/Music
Name musicNames; // array of .wav files
MusicZones musicZones; // location of "sounded-areas"
// waves from Sound/Back
Name backgNames; // array of .wav files
ZoneLists backgZones; // array of ZoneList
MusicSpots backgSpots; // array of MusicSpot
// unknown
long unk4; // 0 for FLD and some DUN; if <> 0, some DUN fail to process (to be rechecked)
// Portals definition
long cntPortals; // number of portals to follow
Portals* portals; // array of portals
// Spawn Area definition
long cntSpawn; // number of spawn area to follow
SpawnArea* spawnArea; // array of SpawnArea
// Named Area definition
long cntNamed; // number of named area to follow
NamedArea* spawnArea; // array of NamedArea
// NPC definition
long cntNPC; // number of NPC to follow
NPC* npcs; // array of NPC
// end of comman part
// if wType == 'FLD\0'
// weather definition
String256 skyName; // name of .bmp file used to draw the sky (from Sky\)
String256 clouds1; // name of .tga file used to draw some clouds (from Sky\)
String256 clouds2; // name of .tga file used to draw some clouds (from Sky\)
// endif wType == 'FLD\0'
// some globals dimensions of the map (11 float)
fPoint pt1; // quite always (255.0, 255.0, 255.0)
fPoint pt2; // quite always (128.0, 128,0, 128.0)
fPoint pt3; // 128.0 x 3 or different values
float z1, z2; // ???
// if wType == 'DUN\0'
// some dungeons define additional data (for instance 768 bytes for 81.wld)
// I haven't spend time of them so far.
// endif wType == 'DUN\0'
};
The first part is the "mesh" description, it includes all linked/included .smod files and their poistions; it could be a bit boring, for instance when the 81.wld lists more than 9000 blade of grass ... (see 81.desc.txt.zip, as a dongeon sample)
The secon part contains the "game-elements", the elements with which the player interacts, this includes portals, spawn, named areas and NPC.
These items are *NOT* used by the .wld file, the server, and only the server, defines actual portals, NPC or areas (from the .svmap file) and communicates these info to the client.
*But* it looks like (it's an esay assumption) that the .svmap files are generated from the .wld files, and we can imagine some authoring tools that allow visual insertion of NPC (and other) in the field.
Some years ago, we all paintfully looked for .svmap for each new published .wld ... the answer was there :'(
Now it can take a few seconds to load one and generate the second.
My first edit ---> yin yang portal<--- 08/05/2008 - CO2 Weapon, Armor, Effects & Interface edits - 18 Replies this is my first edit ..
a yin yang portal
extract the file in c3-->effects
HOPE U LIKE IT :)
http://img174.imageshack.us/img174/757/46413335tr 7.th.jpg
[request] how to make any portal item to Crag Mine Field Portal 06/17/2008 - RF Online - 2 Replies can any one make any portal item like, Armory 213 portal item, accretia HQ portal item to ->> crag mine field portal item.. it hard to go back to crag mine field when i got Disconnected from server..
Request for lvl 115 Backsword Edit and 100 Robe Edit 11/17/2007 - CO2 Weapon, Armor, Effects & Interface edits - 0 Replies Hey Guys, Is there any chance someone could show me some cool edits of the lvl 100 and 115 Tao robes, and the 110 and 115 Backswords? Just post some screenies for me and upload them if you like :p
They're gonna be on a large female though so make them sexy! :D :cool:
![[Request] Edit .wld and Portal](https://www.elitepvpers.com/forum/iconimages/shaiya-private-server/request-edit-wld-portal_ltr.gif){kind=small}
