|
| Thread: Save format - SoD/HotA |  This thread is pages long: 1 2 · NEXT» |
|
ignus
Tavern Dweller
|
posted November 15, 2019 10:16 AM |
|
|
Save format - SoD/HotA
Hi guys,
I want to extract stats of my game progress from saves. Do you have any information about H3 save format? I know that save have to be extracted by ZIP and that saves with passwords are encrypted. My question is about not encrypted saves. I found some information how to find Hero information in saves but it's too little for me.
I want extract information from save about:
- players heroes (skills, stats, mana points, movement points, spells) and heroes available in tavern for each player
- armies
- castles (buildings, spells from mage guild)
- gold&resources
- actual turn
- player timer
|
|
Salamandre
Admirable
Omnipresent Hero
Wog refugee
|
|
posted November 15, 2019 10:28 AM |
|
|
|
It would be easy to do if using era /wog, real time script displaying such data
|
|
ignus
Tavern Dweller
|
|
posted November 15, 2019 10:59 AM |
|
|
|
Yeah, it's one possibility and there is chance that I'll go that way. I want to try read this data from save file too.
|
|
Maurice
Hero of Order
Part of the furniture
|
|
posted November 15, 2019 12:37 PM |
|
|
It's doable, but writing a parser for the data isn't trivial. I've tried to create something like that in Excel, but it's only rudimentary and still requires manual data selection. For me it's good enough, to provide me all the details I need (Mage Guild buildup, Town buildup and troops within, Heroes buildup, location of stat boosters and whether the selected Hero has visited it yet and stuff like that).
____________
The last Reasonable Steward of Good Game Design and a Responsible Hero of HC. - Verriker
|
|
ignus
Tavern Dweller
|
|
posted November 15, 2019 01:23 PM |
|
|
I have some experience with parsing games files from Baldurs Gate and infinity engine.
Some description of format like:
https://gibberlings3.github.io/iesdp/file_formats/index.htm
would be awesome.
The most important is how to read offsets to specific sections inside saves.
For now I would like to collect as many information about save format as it is possible, because I don't want to reinventing the wheel from beginning.
|
|
Maurice
Hero of Order
Part of the furniture
|
|
posted November 15, 2019 02:37 PM |
|
|
ignus said:
The most important is how to read offsets to specific sections inside saves.
That part I haven't been able to crack yet, either, despite some attempts at doing it. I suspect the game determines some data sections implicitely, making it hard to put the finger on them.
This is where in my parser, the manual part comes in. I can readily identify the start of the map section as well as the start of the Town section (and by proxy, also the Hero section which follows right after it). I've spotted the individual player information as well and have identified several data elements (like which Hero is in which slot, their resources, etc), but some are still unknown to me.
I have also found the sections with the Black Market, Dragon Utopia and similar, as well as the Seer Quests, but found it hard to reliably parse them because it's hard to pinpoint the exact starting position on the various entries.
____________
The last Reasonable Steward of Good Game Design and a Responsible Hero of HC. - Verriker
|
|
AlexSpl
Responsible
Supreme Hero
|
|
posted November 15, 2019 03:01 PM |
|
|
|
Afaik, there are no detailed descriptions of the H3 savegame file format publicly available. So you'll have to reinvent the wheel.
|
|
ignus
Tavern Dweller
|
|
posted November 15, 2019 03:17 PM |
|
Edited by ignus at 16:12, 15 Nov 2019.
|
Maurice said:
That part I haven't been able to crack yet, either, despite some attempts at doing it. I suspect the game determines some data sections implicitely, making it hard to put the finger on them.
So it'll be much more work 
Maurice said:
This is where in my parser, the manual part comes in. I can readily identify the start of the map section as well as the start of the Town section (and by proxy, also the Hero section which follows right after it). I've spotted the individual player information as well and have identified several data elements (like which Hero is in which slot, their resources, etc), but some are still unknown to me.
How do you identify starts of these sections?
Maurice said:
I have also found the sections with the Black Market, Dragon Utopia and similar, as well as the Seer Quests, but found it hard to reliably parse them because it's hard to pinpoint the exact starting position on the various entries.
So each building have possibility for own entry and thanks to it can specify artifacts/armies and it's separated from map sections?
AlexSpl said:
Afaik, there are no detailed descriptions of the H3 savegame file format publicly available. So you'll have to reinvent the wheel.
 I'm not sure if I can handle it, but at least I'll try. Meantime I'll also try plugin way to read that stats.
If I'll find something about save format I'll write it here.
|
|
Maurice
Hero of Order
Part of the furniture
|
|
posted November 15, 2019 04:15 PM |
|
|
ignus said:
How do you identify starts of these sections?
Initially through trial and error, but with that experience I can now easily visually identify them. Still, I don't know how I can tell a computer how to identify them fast and easily.
Quote:
So each building have possibility for own entry and thanks to it can specify artifacts/armies and it's separated from map sections?
Basically, yes. You could possibly change the guards and rewards that way.
____________
The last Reasonable Steward of Good Game Design and a Responsible Hero of HC. - Verriker
|
|
ignus
Tavern Dweller
|
|
posted November 15, 2019 05:26 PM |
|
|
Maurice said:
Initially through trial and error, but with that experience I can now easily visually identify them. Still, I don't know how I can tell a computer how to identify them fast and easily.
Have you maybe some example save file with example offsets for these sections? I think that it would help me a lot.
|
|
avatar
Promising
Supreme Hero
|
|
posted November 15, 2019 06:36 PM |
|
|
Guys from vcmi project did some time ago heroes3 map format parser. Savegame is some kind of zipped map, I guess.
https://github.com/vcmi/vcmi/blob/develop/lib/mapping/MapFormatH3M.cpp
____________
|
|
Maurice
Hero of Order
Part of the furniture
|
|
posted November 16, 2019 09:24 AM |
|
|
ignus said:
Have you maybe some example save file with example offsets for these sections? I think that it would help me a lot.
I’m currently away from home, so can’t help you at the moment. Should be home in a couple of days.
The map format is interesting and something I’ve already mapped for the most part. Will post it once I am home.
____________
The last Reasonable Steward of Good Game Design and a Responsible Hero of HC. - Verriker
|
|
Salamandre
Admirable
Omnipresent Hero
Wog refugee
|
|
posted November 16, 2019 11:08 AM |
|
|
|
Doesn't this allow cheating in MP, as HD mod prohibits viewing saves without proper password?
|
|
ignus
Tavern Dweller
|
|
posted November 16, 2019 03:41 PM |
|
|
Maurice said:
ignus said:
Have you maybe some example save file with example offsets for these sections? I think that it would help me a lot.
I’m currently away from home, so can’t help you at the moment. Should be home in a couple of days.
The map format is interesting and something I’ve already mapped for the most part. Will post it once I am home.
Thanks, it is great for me!
|
|
ignus
Tavern Dweller
|
|
posted November 16, 2019 03:44 PM |
|
|
Salamandre said:
Doesn't this allow cheating in MP, as HD mod prohibits viewing saves without proper password?
I don't want to read encrypted with passwords saves for now. Maybe in the future I'll try decrypt save if someone'll give correct passwords.
|
|
Maurice
Hero of Order
Part of the furniture
|
|
posted November 16, 2019 07:37 PM |
|
|
Salamandre said:
Doesn't this allow cheating in MP, as HD mod prohibits viewing saves without proper password?
I don’t think so. MP savegames are encrypted anyway and I doubt the encryption is easy to hack.
____________
The last Reasonable Steward of Good Game Design and a Responsible Hero of HC. - Verriker
|
|
Maurice
Hero of Order
Part of the furniture
|
|
posted November 20, 2019 08:02 PM |
|
Edited by Maurice at 20:11, 20 Nov 2019.
|
Each maptile in the game is saved to the savegame, starting from the top left of the surface map down to the bottom right of the subterranean map (if present), reading it from left to right like you would a book. There are no coordinates given for each maptile, since they’re all implicitely referring their coordinates by their position within the total map string. Coordinates of the map are specified elsewhere, near the start of the savegame.
Each maptile follows a basic formatting, that’s 26 bytes in size, with an optional 8 bytes for each subsequent maptile object within the same tile. I’ll give a Witch Hut as an example, since that’s the map object I first fully analysed successfully. The byte string could look something like this:
00 1C 00 00 00 00 40 10 71 00 00 00 01 00 20 40 03 00 01 00 00 00 01 00 01 01
The first byte, 00, is the ground type. Type 00 is the dirt ground, other types have a different value.
The second byte, 1C, is the variation code. There are quite a lot of different terrain tiles for a given type, that all look slightly different from one another and this value indicates which variation is in this particular tile.
The next 4 bytes always seem to be 00 00 00 00. I have not seen a case where this wasn’t so, but that doesn’t mean they can’t be anything different. I just haven’t seen any case where this was something different. As such, I do not know what these bytes represent.
The next byte, 40, seems to be a bitmask. Other values I’ve seen are 80 and C0, though I haven’t yet fully figured out what they represent. I suspect they handle direction of accessibility of the tile in question.
The byte following it is the actual accessibility of the tile. A value of 10 Hex (or 16 in decimals) means that the tile can be moved upon by a Hero and anything else means it’s blocked off.
The next 10 bytes deal with the object itself (here 71 00 00 00 01 00 20 40 03 00)
The first 2 reference the exact line within the ObjNames.txt file (keep in mind there’s an offset of 1, since the first object had an ID of 0!). The Witch Hut has a value of 71 00 here, which translates as line 114 (71 Hex is 113 in decimals, plus the offset of 1 due to object ID 0 starting the line) and if you check the ObjNames.txt file, you’ll see that line 114 is indeed the Witch Hut.
The two bytes following it are 00 00 here, since the Witch Hut doesn’t use them. However, some other objects do; for instance, object 16 (line 17) is called a “Creature Cache”. It’s one of the resource hoards, guarded by creatures (Cyclops Stockpile, Dwarven Treasury, Griffin Conservatory, Imp Cache, Medusa Stores, Naga Bank and Dragon Fly Hive) and those two bytes indicate exactly which subtype is positioned there.
Each object is linked to another table, that keeps track of the state of the objects. The two bytes following the subtype take care of this link. In the above example, those have a value of 01 00, which means it links to the second entry in that table (keep in mind that the first entry in the link table starts at 0). The link table itself follows after the actual map tile data and holds a reference to the actual contents of the object. It seems rather complicated to do it this way, but I guess they had their reasons.
Finally, those 10 bytes are concluded by 4 bytes that have a different meaning for the different objects. For this Witch Hut, it’s 20 40 03 00 and those bytes form a bit mask. In order to understand the bitmask, you need to write out the bytes into their bit values, reversing their order (since they use Little Endian formatting, instead of Big Endian formatting for their byte order). As such, for the Witch Hut you need to write it as 00 03 40 20 instead. Translating those 4 bytes into a bit string yields 00000000 00000011 01000000 00100000. This bit string contains 4 data elements, of different size. The first 11 bits are always 0 for Witch Huts. Then you have 8 bits that form the skill ID contained within the Witch Hut. Here, that string reads 00011010 and converting that back to a byte value, we get 1A in hex, or 26 in decimals, which means this Witch Hut contains the Resistance skill. You can find the follow-up order of the skills in the file SSTRAITS.txt, which describes the Secondary Skills in more detail. Then you get 8 bytes that indicate which player has visited it, 1 bit for each player. Player 8 is to the far left, down to player 1 on the far right. As you can see here, the bit string reads 00000001, which means player 1 visited this Witch Hut (and hence, knows its contents), while other players have yet to reach it. The final 5 bits in this mask are always zero for Witch Huts.
There are 8 more bytes left in the above example. The first four of these - 01 00 00 00 – indicate how many references to Def files there are. In this case, there’s only 1: there is no other object in the same tile, just the Witch Hut. Any other objects in the same tile, even if it’s just a small pebble or another nearby object that partially obscures or is partially obscured by the Witch Hut, have their own Def file reference here in subsequent entries. In that case, those 4 bytes have a higher value.
The second set of 4 bytes can be repeated, depending on the number of entries that should be there. These 4 bytes split into 3 data fields, which indicate which section of which Def file to use. The first two bytes – in the example above, those are 01 00 – reference the position within the Def file table that follows the map data. This indicates which Def file to show on the map. The following 2 bytes (here 01 01) indicate an offset within the Def file. Since most Def files cover more than one tile, the game has to figure out which parts of the Def file to show on which tile for the object on the map. The offset indicates which section that has to be.
Now each object has its own meaning for the various data entries above. In specific, this deals with bytes 11-12 and with bytes 15-18. I will try to list the ones that I have figured out in a comprehensible manner in a follow-up post.
____________
The last Reasonable Steward of Good Game Design and a Responsible Hero of HC. - Verriker
|
|
Maurice
Hero of Order
Part of the furniture
|
|
posted November 20, 2019 10:04 PM |
|
|
Below are all the objects I have figured out by now. Most other objects have no special attributes, but I still need to explore a number of them. I will only list the contents of bytes 11-12 and bytes 15-18, as they differ between the objects. For the other bytes, I reference to the previous text. Keep in mind that when bytes form a bitmask, their order needs to be reversed before converting the bytes into bits.
Object 7: The Black Market
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Reference to the data table preceding the actual map tile data.
Remark: The contents of the Black Markets on the map are stored before the map data. The value of bytes 15-18 indicate the position within this table.
Object 12: Campfire
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Bit Mask.
Bit Mask: Bytes 0 through 23 are always 0. Bytes 24-27 indicate the quantity contained with the Campfire, bits 28-31 indicate the resource type.
Remark: None.
Object 13: Cartographer
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Always FF FF FF FF.
Remark: Not sure how the game handles this one, there has to be a visited player mask. It’s probably stored within the player data instead of the object data.
Object 16: Creature Hoard
Bytes 11-12: Indicates the subtype of the hoard.
Bytes 15-18: Reference to the data table following the data of the map shadow (fog of war) towards the end of the savegame file.
Remark: The contents of the Creature Hoards are stored in a data table following the fog of war map. The value of bytes 15-18 indicate the position within this table.
Object 17: Dwellings
Bytes 11-12: References the line in the CrGen1 (or CrGen4) text file of the specific creature type.
Bytes 15-18: Indicates the specific Dwelling in the Dwelling data table.
Remark: The Dwelling data table is positioned between the Def file list and the general player data.
Object 22: Corpse
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Bit Mask.
Bit Mask: Bits 0 – 14 are always 0. Bit 15 indicates whether the Corpse is still lootable. Bits 16 – 25 form the Artifact ID that is contained within the Corpse. Bit 26 is always 1. Bits 27 - 31 form a Corpse counter (which means there can be only 32 Corpses on the map).
Remark: The bit string doesn’t contain a visited player mask. Instead, this is formed by the third set of 4 bytes in the general player data, following the amount of Gold the player has.
Object 24: Derelict Ship
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Bit Mask.
Bit Mask: Bits 0 – 4 are always 1. Bits 5 – 18 are a reference to the data table following the fog of war section. Bits 19 – 26 form the visited player mask. Bits 27 – 31 are always 1.
Remark: The contents of Derelict Ships are stored in a data table following the fog of war map along with those of the Creature Hoards.
Object 25: Dragon Utopia
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Bit Mask.
Bit Mask: Bits 0 – 4 are always 1. Bits 5 – 18 are a reference to the data table following the fog of war section. Bits 19 – 26 form the visited player mask. Bits 27 – 31 are always 1.
Remark: The contents of Dragon Utopias are stored in a data table following the fog of war map along with those of the Creature Hoards.
Object 29: Flotsam
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Content type.
Remark: Content type 0 is nothing, 1 is 5 Wood, 2 is 5 Wood and 200 Gold, 3 is 10 Wood and 500 Gold.
Object 30: Fountain of Forture
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Bit Mask.
Bit Mask: Bits 0 – 14 are always 1. Bits 15 – 18 indicate the quantity by which it changes the Hero’s attribute, where a value of 1111 indicates it will change it by -1. Bits 19 – 26 are always 0, bits 27 – 31 are always 1.
Remark: The visited Hero mask is maintained with each individual Hero, not with the object.
Object 31: Fountain of Youth
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Always FF FF FF FF.
Remark: The visited Hero mask is maintained with each individual Hero, not with the object.
Object 33: (Anti-Magic) Garrison
Bytes 11-12: Indicates whether it’s a normal Garrison (00 00) or an Anti-Magic Garrison (01 00).
Bytes 15-18: References the data table with object contents, containing the creature ID’s that are present within the Garrison, along with their quantity.
Remark: The data table follows the Fog of War data at the end of the save game file, along with the contents of various treasure hoards.
Object 39: Lean-To
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Bit Mask.
Bit Mask: Bits 0 – 17 are always 1. Bits 18 – 21 indicate the Resource type held within, with bits 22 – 25 the quantity of that resource. Bit 26 is always 1. Bits 27 – 31 are an object counter for Lean-To’s.
Remark: With just 5 bits for the object counter, there is a maximum of 32 Lean-To’s on any given map. The visited player mask is the fourth set of 4 bytes in the general player data, following the Gold quantity.
Object 48: Magic Spring
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Bit Mask.
Bit Mask: Bits 0 – 18 are always 1. Bits 19 – 26 form the visited player mask. Bits 27 – 31 are an object counter for Magic Springs.
Remark: With just 5 bits for the object counter, there is a maximum of 32 Magic Springs on any given map. Unlike other visited player masks, this one is in reverse order: player 1 is in the left-most bit, up to player 8 in the right-most bit.
Object 52: Mermaids
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Always FF FF FF FF.
Remark: Visited player mask is in the Hero data of each Hero.
Object 54: Monster
Bytes 11-12: Contains the Creature ID of the specific monster.
Bytes 15-18: Bit Mask.
Bit Mask: Bit 0 indicates whether the monster carries a treasure. Bits 1 – 10 are unknown, but seem to always be 0. May be related to the treasure they’re carrying, or referencing the creature table. Bit 11 is unknown, but may be related to the treasure type. Bit 13 indicates whether the stack can grow (0) or not (1). Bit 14 indicates if it can flee (0) or not (1). Bits 15 – 19 indicate its aggressiveness, where a value of 28 actually means -4, which is compliancy. Bits 20 – 31 indicate the quantity of creatures within the stack.
Remark: Aggressiveness ranges from Compliant to Savage in the map editor, which is translated into an aggressiveness value on map generation. The possible aggressiveness values depend on the range chosen: for Friendly, it’s from 1 through 7, for Aggressive it’s from 1 through 10 and for Hostile it’s 4 through 10. Savage monsters are always at 10. Therefore, it’s possible that a Friendly monster ends up with an aggressiveness of 7 and is less likely to join a Hero than a Hostile stack that ended up with an aggressiveness of only 4.
Object 55: Mystical Garden
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Bit Mask.
Bit Mask: Bits 0 – 20 are always 1. Bit 21 indicates whether it can still be looted this week. Bits 22 and 23 are always 01. Bits 24 and 25 indicate whether the Garden yields Gems (01) or Gold (10). Bit 26 is always 1. Bits 27 – 31 are an object counter.
Remark: With just 5 bits for the object counter, there is a maximum of 32 Mystical Gardens on any given map.
Object 56: Oasis
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Always FF FF FF FF
Remark: The status of having visited the Oasis is likely contained within the Hero data of each Hero, although I haven’t identified the specific bytes yet.
Object 57: Obelisk
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Determines the position in the data table that follows the Def link table, but before the general player data.
Remark: The data table contains the visited player mask for each Obelisk.
Object 59: Ocean Bottle
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Determines the position in the data table that follows the Def link table, but before the general player data.
Remark: The data table contains the text that is displayed to the player collecting the bottle.
Object 62: Prison
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Contains the ID of the Hero held within the Prison.
Remark: All the attributes of the Hero are contained within the Hero data, not in the Prison data.
Object 63: Pyramid
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Bit Mask.
Bit Mask: Bits 0 – 10 are always 1. Bits 11 – 18 contain the Spell ID of the spell held within the Pyramid. Bits 19 – 26 are the visited player mask. Bits 27 – 30 are always 1. Bit 31 indicates whether the spell is still present within the Pyramid, or if it has been looted already.
Remark: None.
Object 78: Refugee Camp
Bytes 11-12: Contains the Creature ID of the creature in the Refugee Camp.
Bytes 15-18: Contains the quantity of the creature.
Remark: None.
Object 81: Scholar
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Bit Mask.
Bit Mask: Bits 0 – 8 are always 1. Bits 9 – 18 are the Spell ID that is trained by the Scholar. If no spell is taught, these are all 1. Bits 19 – 25 are the Secondary Skill ID that is trained by the Scholar. If no Secondary Skill is taught, these are all 1. Bit 26 is always 0. Bits 27 and 28 determine the Primary Skill that the Scholar teaches. Bit 29 is always 0. Bits 30 and 31 indicate the type of bonus being taught (00 = Primary Skill, 01 = Secondary Skill, 10 = Spell).
Remark: Bits 27 and 28 are always set to a value other than 11, as these also indicate the Primary Skill to be taught if the Hero already knows the Spell or Secondary Skill being offered.
Object 82: Sea Chest
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Bit Mask.
Bit Mask: Bits 0 – 18 are always 1. Bits 19 – 28 contain the Artifact ID of the Artifact in the Sea Chest (if any). Bit 29 is always 0. Bits 30 – 31 indicate the type of loot within the Sea Chest (00 = nothing, 01 = Gold, 10 = Gold and an Artifact.
Remark: None.
Object 83: Seer’s Hut
Bytes 11-12: References the Quest list table, between the Def data and general player data.
Bytes 15-18: References the location in the data content table, towards the end of the save game, after the Fog of War data.
Remark: The Seer’s Hut data table is a data string in its own right, that merits a separate post. Will detail this later, as I’ve already figured out the format.
Object 84: Crypt
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: References the location in the data content table , towards the end of the save game, after the Fog of War data.
Remark: None.
Object 85: Shipwreck (1 & 2)
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: References the location in the data content table , towards the end of the save game, after the Fog of War data.
Remark: One Shipwreck is beached and on the shore, the other is wrecked on some cliffs in the middle of water.
Object 86: Shipwreck Survivor
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Contains the Artifact ID of the Artifact that the survivor rewards for being picked up.
Remark: None.
Object 88, 89 and 90: Shrine of Magic Incantation, Shrine of Magic Gesture and Shrine of Magic Thought
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Bit Mask.
Bit Mask: Bits 0 – 8 are always 1. Bits 9 – 18 contain the Spell ID of the Spell held within the Shrine. Bits 19 – 26 are the visited player mask. Bits 27 – 31 are always 1.
Remark: None.
Object 91: Sign
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: References the data content table, before the general player data. Contains the actual text that the sign shows to the player upon visiting the Sign.
Remark: None.
Object 92: Sirens
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Always FF FF FF FF.
Remark: The visited Hero mask is held within the Hero data, not in the object.
Object 94: Stables
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Always FF FF FF FF.
Remark: The visited Hero mask is held within the Hero data, not in the object.
Object 102: Tree of Knowledge
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Bit Mask.
Bit Mask: Bits 0 – 15 are always 1. Bit 16 is always 0. Bits 17 and 18 indicate the cost of using the Tree of Knowledge: 00 is free, 01 is Gold and 10 is Gems. Bits 19 – 26 are the visited player mask. Bits 27 – 31 are an object counter.
Remark: With just 5 bits for the object counter, there is a maximum of 32 Trees of Knowledge on any given map.
Object 104: University
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Bit Mask.
Bit Mask: Bits 0 – 6 are always 1. Bits 7 – 18 reference the location in the data content string that follows the Fog of War data, containing the 4 Skills held within the University. Bits 19 – 26 are always 0. Bits 27 – 31 are always 1.
Remark: The visited player mask is held within the general player data.
Object 105: Wagon
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Bit Mask.
Bit Mask: Bits 0 – 2 are always 1. Bits 3 – 6 contain the Resource ID of the resource held within the Wagon. Bits 7 and 8 indicate whether the Wagon contains Resources (11) or an Artifact (00). Bits 9 – 16 contain the Artifact ID if there’s an Artifact to be looted. Bit 17 indicates whether the Wagon contains Resources (0) or an Artifact (1). Bit 18 indicates if the Wagon can still be looted (1) or has been looted already (0). Bit 19 – 26 are the visited player mask. Bits 27 and 28 are always 0. Bits 29 – 31 contain the resource quantity, if the Wagon contains a resource.
Remark: None.
Object 108: Warrior’s Tomb
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Bit Mask.
Bit Mask: Bits 0 – 8 are always 1. Bits 9 and 10 are always 0. Bits 11 – 18 contain the Artifact ID of the Artifact within the Tomb. Bits 19 – 26 are the visited player mask. Bits 27 – 30 are always 1. Bit 31 indicates whether the Tomb has been looted already (0) or not (1).
Remark: None.
Object 109: Water Wheel
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Bit Mask.
Bit Mask: Bits 0 – 18 are always 1. Bits 19 – 26 are the visited player mask. Bits 27 – 30 are always 0. Bit 31 indicates whether the Water Wheel can still be visited (1) or whether it has been depleted already (0).
Remark: None.
Object 110: Watering Hole
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Always FF FF FF FF.
Remark: Whether a Hero has visited a Watering Hole is tracked within the Hero data of each Hero.
Object 112: Wind Mill
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Bit Mask.
Bit Mask: Bits 0 – 14 are always 1. Bits 15 – 18 indicate the amount of resources to be obtained from the Wind Mill. Bits 19 – 26 are the visited player mask. Bit 27 is always 1 and bit 28 is always 0. Bits 29 – 31 are the Resource ID of the resource that can be collected.
Remark: None.
Object 113: Witch Hut
Bytes 11-12: Not used (always 00 00).
Bytes 15-18: Bits 0 – 10 are always 0. Bits 11 – 18 contain the Skill ID of the Skill taught by the Witch Hut. Bits 19 – 26 contain the visited player mask. Bits 27 – 31 are always 0.
Remark: None.
____________
The last Reasonable Steward of Good Game Design and a Responsible Hero of HC. - Verriker
|
|
ignus
Tavern Dweller
|
|
posted November 21, 2019 08:04 AM |
|
Edited by ignus at 08:05, 21 Nov 2019.
|
It's awesome! Thank you so much. So beginning structure for tile in savegame looks similar to tile structure from map file, it's the source code from VCMI which reads tile from map. Sizes and order can be different but there should be also information about rivers, roadType and roadDir inside savegame.
auto & tile = map->getTile(int3(z, c, a));
tile.terType = ETerrainType(reader.readUInt8());
tile.terView = reader.readUInt8();
tile.riverType = static_cast<ERiverType::ERiverType>(reader.readUInt8());
tile.riverDir = reader.readUInt8();
tile.roadType = static_cast<ERoadType::ERoadType>(reader.readUInt8());
tile.roadDir = reader.readUInt8();
tile.extTileFlags = reader.readUInt8();
tile.blocked = ((tile.terType == ETerrainType::ROCK || tile.terType == ETerrainType::BORDER ) ? true : false); //underground tiles are always blocked
tile.visitable = 0;
I'll sit and do some analyses evening.
|
|
ignus
Tavern Dweller
|
|
posted November 21, 2019 06:26 PM |
|
|
|
I found that tiles without objects have 22 bytes of length. Map section is very high, maybe one of first sections in savegame file.
|
| |
|
|
