posted 09-06-13 23:17 EST (US)
I have begun a quest to learn about the format of a Stronghold map file. Needless to say that won't be an easy task, but if I find any useful information, I plan on putting it here for the benefit of the community.
To start, for anyone else pursuing the same thing, I have found that, in order to have a clean base map to compare against, you must first save your map, open it, and then save it again without making any changes or entering the map landscape editor. Copy this map to a directory outside of your maps folder. After that, you can open the map in Stronghold from your maps directory, make a change, save it, and compare the new version to the original to try and discover where that value lives in the file.
To begin, the file always starts with FF FF FF FF. A large amount of information following this seems to be affiliated only with the minimap image shown in the loading screen. I'd speculate that the bytes here are ARGB color values until large strings of zeros start appearing, perhaps some other information regarding the size of the image also.
For all the information that follows, assume that a 160x160 map with all default values is being used as the base unless otherwise noted.
I have discovered where to edit the date. You can change the value at 0x40F37 to change the month. 00 corresponds to January, 01 to February, and so on.
Starting at 0x40F33 is the year information. The year value has the lower-order bytes on the left - changing 0x40F33 by 1 will change the year by 1, changing 0x40F34 by 1 will change the year by 256, and so on, until you run into the bytes for the month.
The trader information (as in, which goods are available at market) is stored between 0x48EDE and 0x48F36. Skipping every three bytes (although it may be possible to edit them to the same effect), each byte represents a boolean value indicating whether or not a good is available. Zero indicates false, nonzero indicates true. Three of the bytes in this pattern appear unused (or if they are used it is not for trade information).
Popularity is set at 0x40FE3. Starting goods are found between 0x40F43 and 0x40F93, and the values are little-endian as with the starting year. The use of the bytes between popularity and starting goods is currently unknown.
Buildings are enabled by every other byte between 0x40FE7 and 0x410A0.
The barracks units can be enabled or disabled by changing every second byte between 0x52E5B and 0x52E67 (close to the end of the file). There is something strange about the archer, however. Saving and reloading the map, I always find it enabled. The three pairs of bytes after these addresses enable/disable the weapons you're allowed to produce.
In a map corrupted so that all landscape tiles have the same appearance and height, the first large field of zeros corresponds to the tile appearances only. It is unknown if the height changes the available appearances or what values correspond to what appearances.
In the same map, 0x235-0x258 represent the entirety of the level description. The size of the entry is variable - adding characters changes the number of bytes. The correlation between the actual bytes in this data and what shows up in the description is still unknown. It is possible there is some sort of compression algorithm or encryption being used to store the data. It appears that this is placed after the minimap information, although this could be incorrect.
Starting at 0x950, there appear to be a series of what I would guess are offsets or addresses for certain sections of data within the level.
Following this data is a series of repeated bytes interrupted by what has the appearance of garbage. Somewhere in here is height data. How the height information is distributed per tile is still unknown, but it is known that one byte is used to record a single height. 00 is the lowest possible height, FF is the highest. I am guessing that the data here is mixed in with things like pathing information. I have a theory that the height data is stored as such: a height is indicated, and then the tiles at that height are linked to it, rather than specifying the height for each tile sequentially. One thing I have found is that the data can shift in increments of half-bytes...
The minimap in the editor menu is created at run-time using landscape data, where the minimap in the editor loading screen is loaded from the level file.
That's it so far. More to come as I find it (unless the mods would find it more appropriate to catalog this information in another manner).
-DOOMBRINGER-
"DOOMBRINGER, make a parking space IMMEDIATELY!"
"DOOMBRINGER declares it to be SO!"
"DOOMBRINGER, I command you to lay siege to THE ISS!"
To start, for anyone else pursuing the same thing, I have found that, in order to have a clean base map to compare against, you must first save your map, open it, and then save it again without making any changes or entering the map landscape editor. Copy this map to a directory outside of your maps folder. After that, you can open the map in Stronghold from your maps directory, make a change, save it, and compare the new version to the original to try and discover where that value lives in the file.
To begin, the file always starts with FF FF FF FF. A large amount of information following this seems to be affiliated only with the minimap image shown in the loading screen. I'd speculate that the bytes here are ARGB color values until large strings of zeros start appearing, perhaps some other information regarding the size of the image also.
For all the information that follows, assume that a 160x160 map with all default values is being used as the base unless otherwise noted.
I have discovered where to edit the date. You can change the value at 0x40F37 to change the month. 00 corresponds to January, 01 to February, and so on.
Starting at 0x40F33 is the year information. The year value has the lower-order bytes on the left - changing 0x40F33 by 1 will change the year by 1, changing 0x40F34 by 1 will change the year by 256, and so on, until you run into the bytes for the month.
The trader information (as in, which goods are available at market) is stored between 0x48EDE and 0x48F36. Skipping every three bytes (although it may be possible to edit them to the same effect), each byte represents a boolean value indicating whether or not a good is available. Zero indicates false, nonzero indicates true. Three of the bytes in this pattern appear unused (or if they are used it is not for trade information).
Popularity is set at 0x40FE3. Starting goods are found between 0x40F43 and 0x40F93, and the values are little-endian as with the starting year. The use of the bytes between popularity and starting goods is currently unknown.
Buildings are enabled by every other byte between 0x40FE7 and 0x410A0.
The barracks units can be enabled or disabled by changing every second byte between 0x52E5B and 0x52E67 (close to the end of the file). There is something strange about the archer, however. Saving and reloading the map, I always find it enabled. The three pairs of bytes after these addresses enable/disable the weapons you're allowed to produce.
In a map corrupted so that all landscape tiles have the same appearance and height, the first large field of zeros corresponds to the tile appearances only. It is unknown if the height changes the available appearances or what values correspond to what appearances.
In the same map, 0x235-0x258 represent the entirety of the level description. The size of the entry is variable - adding characters changes the number of bytes. The correlation between the actual bytes in this data and what shows up in the description is still unknown. It is possible there is some sort of compression algorithm or encryption being used to store the data. It appears that this is placed after the minimap information, although this could be incorrect.
Starting at 0x950, there appear to be a series of what I would guess are offsets or addresses for certain sections of data within the level.
Following this data is a series of repeated bytes interrupted by what has the appearance of garbage. Somewhere in here is height data. How the height information is distributed per tile is still unknown, but it is known that one byte is used to record a single height. 00 is the lowest possible height, FF is the highest. I am guessing that the data here is mixed in with things like pathing information. I have a theory that the height data is stored as such: a height is indicated, and then the tiles at that height are linked to it, rather than specifying the height for each tile sequentially. One thing I have found is that the data can shift in increments of half-bytes...
The minimap in the editor menu is created at run-time using landscape data, where the minimap in the editor loading screen is loaded from the level file.
That's it so far. More to come as I find it (unless the mods would find it more appropriate to catalog this information in another manner).
-DOOMBRINGER-
"DOOMBRINGER, make a parking space IMMEDIATELY!"
"DOOMBRINGER declares it to be SO!"
"DOOMBRINGER, I command you to lay siege to THE ISS!"
[This message has been edited by Timballisto (edited 09-08-2013 @ 08:55 PM).]
but it would be great to have an advantage to place units and/or equipment like the mangonel or ballistae wherever you like.. instead of just toying around with the usual tricks..