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.