Sign in to follow this  
whereami

.MAP file format?

Recommended Posts

Does anyone know offhand what the raw byte structure of the .MAP files WU uses are? I wish to know how data is contained in these files, how it could be modified, etc.

I want to create my own .MAP files, using some pre-existing heightmap data. In this case more specifically, I have a byte array I would like to use as the heightmap data, and using it to output a 16-bit greyscale image is simply not the intuitive route for me to take.

(Especially given the sparse nature of programs that can correctly handle and preserve the quality of 16-bit PNG's...)

Edited by whereami

Share this post


Link to post
Share on other sites

Each .map file is basically a dump of a two dimensional array.  The possible values of each node are unique to that file.  For example, rock_layer.map is the height of each point, map_cave.map holds information about each tile (type, actions remaining, etc), and so on.

 

Take a look at the Wurm API post pinned at the top of the Tools sub forum for more information and code.  Terrain gen from a byte array won't be as simple as you think.  Wurm has two layers, rock and dirt.  They're two different height maps, with dirt on top of rock.  If the two map files have the same height value for a given node, then rock is exposed at the surface...

 

Share this post


Link to post
Share on other sites
7 hours ago, Ricowan said:

Terrain gen from a byte array won't be as simple as you think.  Wurm has two layers, rock and dirt.  They're two different height maps, with dirt on top of rock.  If the two map files have the same height value for a given node, then rock is exposed at the surface...

 

 

I am completely aware of this fact, it shouldn't impose any major challenges on what I intend to do. I have already prepared algorithms to accommodate for this.

I also wish to use a programming language other than Java to compile these maps. (Java sux) This is why I do not simply add the API as a reference to the tool I am using.

I did take a close look at the WU API, but looking at the sourcecode didn't immediately answer my question, not sure if I missed something or what.
 

The API already explains how the data itself is structured in the file;

Spoiler

0x00000400  :  05 00 FD A2 ..

05 = 5 = TileType ID

00 = 0 = Tile Aux Data

FDA2 = 64930 = Height of that corner.



That part was helpful though it wouldn't have been hard to figure out. After attempting to reverse-engineer one of the files however, my curiosities lie more with the structure of the actual file rather than the tile data.

Example:

Spoiler

The byte information in my given example is from a freshly-created Adventure map, specifically the "top_layer.map" file.

0x00000000 : 47 4A 21 98 B2 78 1B 9D 00 0B 00 00 .. 00 (0's continue until byte 1024)
0x00000400 : 05 00 FD A2 05 00 FD A2 05 00 FD A2 .. 

 

 

Typical practice means the first few bytes in a file are supposed to be a file signature. Is that what that 1024-byte information gap is? It's awful long for a file signature, and I don't see any code that would generate it in the API. Perhaps there is configuration information there somewhere that does something? The actual tile information doesn't seemingly start until the 1024th byte. All maps I've managed to generate have this.

 

Also looking at the second line of bytecode there, you can see that the information abruptly starts, in the far corner of the map, with a decimal value of 64930 - That's quite high for being in the middle of what should be underwater. Perhaps the height values there are inverted? This also doesn't seem apparent after searching the API code.

Share this post


Link to post
Share on other sites

Header is 8 bytes magic number (47 4A 21 98 B2 78 1B 9D) followed by 1 byte version (for now it's always 0) and 1 byte size exponent (in your case it's 0B = 11 in decimal, so map size is 2^11=2048). Actual data as you noticed starts at 1024 bytes, this is needed to keep things aligned for performance reasons.

 

The data is in chunks of 4 bytes per tile, so your first tile is 05 00 FD A2

The first byte is the tile type (5 - dirt) 

The second is "data" that is unused for dirt. If it was e.g. grass or a tree that would include information on it's age etc.

Third and forth is the height as a signed short, in our case -606

 

The encoding for other map files is different but follows the same gist. If you want to look at  the specific code you'll need to decompile common.jar and look at com.wurmonline.mesh.Tile class &co 

 

  • Like 2

Share this post


Link to post
Share on other sites

Thank you for taking the time to reply. That's plenty information for me to figure the rest out on my own. Needed to make sure I was on the right track!

You know, here I was decompiling the API and other maptools others had made. Never once did I think to look at how WU actually loads these maps for itself... XD doh!

Thanks again, Cheers. (Thread can probably be closed if we do that in this subforum...)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this