-
-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Wanted] Savegame data decoders #45
Comments
I will definitely help with these taks. Unfortunately i don't have time atm but after coming wednesday i can start. |
Here are some Values
Time
Haven't tested world movement with other transportation methods yet. Only on foot. The real time timer gets reset when
Interesting observation: If the player only rotates in a 3D map via mouse, the rotation stops after 10 seconds and the user has to release the mouse button and the in game time advances for 5 minutes The Amiga version is able to load a decoded save game (Party_data.sav) from one of the 10 save games. This helped a lot! :-) Edit: 3C 3D added |
Wow cool findings. Thanks a lot. Will add them to the game soon. |
Here are the number of steps you can take per 5 minutes for all transportation methods.
|
Interesting. Do you know if and where flying is used? |
The bottom of the save game is a little bit different than described here
|
Regarding the flying: Oh, and you can't exit the flight mode! So it's not very usable. |
Events and Dictionary
|
I guess it's a bit flag storing a bit for each popup text? Wouldn't make much sense to store a 2. But not sure about it. |
About the flying. Not all transports can have locations. I guess using an eagle in savegame wouldn't work well as well. I also think it's a cheat as it seems to be able to fly over high mountains and very fast. It would be interesting to find a cheat in the original game now. :D |
Ok the event data at 0x0D14 are the global variable bits. There is a map event which sets a global variable to 0 or 1. The one-time popup in Großvaters Keller sets global var 129 to 1 and the Brunnenmolch event sets 130 to 1. This means there are 16 bytes before that for variable 0 to 127 (I guess for Lyramion world map events). So they start at 0x0D04. There is also a condition event which checks for global vars. But it isn't used for the mentioned events which is strange. I guess text popups are implicitly dependent on global vars. But I haven't figured out how yet. The same is true for triggers. The condition event can force a specific trigger (like hand cursor) but for text popups this isn't used. Instead it has an own value just for that. I looked for a value for the global var value but the Brunnenmolch event chain doesn't have any value at all I guess. |
I did a bit more research. Triggering the text popup in front of the house of bandits will set global vars 1, 2 and 3 to 1. In the savegame byte 0x964 is set to 0x0e (which is a value with 3 bits set in a row). But the offset to 0xd14 (which should contain the bits for global vars 129 and 130) is 944 bytes away and not 16 bytes (1 bit per variable) as I thought before. I don't get it yet. |
I updated the known values in the Ambermoon git repo and added you to the special thanks section there. :) |
I didn't do the math, but could it be something like: This wastes much space in the save game but is easy to calculate, I think. |
About the event bits. I thought of something similar. Maybe I'll have the time to test a few things soon. Yeah I saw your edit about the dictionary but just forgot to add it then. Will do so tomorrow. Could it be that bit 1 of last byte is not used. Did you try to skip the one bit and use a value like 5 (4 + 1) without the 2? Or something like that? I guess checking Gruftschlüssel should be easy with cheat items. Maybe I can do so tomorrow. |
I looked a bit more into the event bits. The difference between offsets 0x964 (world map outside house of bandits) and 0xd14 (grandfather's cellar) is 944 (decimal). This divided by 8 is 118 which is the map index offset between both maps (141 to 259). So I assumed that there are 8 bytes per map which would be 64 event bits per map. I calculated the start of the section to 0x4FC when including map index 0. For map 8 (which is some world map) there is bit 1 set. This map has events in contrast to surrounding maps so this was strong evidence. And then I thought about it and looked at the events on map 259. There are 2 collections. The events themselves and the event list which is referenced by map tiles. The list is never longer than 64 I guess cause that would mean that more than 64 tiles would trigger events. Then I checked the two popups (end of stairs and pond lizard). These are entries 1 and 2 of the event list which would match the 0x02 and 0x04 you mentioned earlier. So every event list index is bound to a bit in the 64 bits per map. These bits turn events on or off. The action event which I thought to be a global variable set action seems to be either a "event bit set action" or something like "disable the current event list entry". I will check this out too. Ok this is definately true. Event 12 in grandfathers house has initially the bit set. This is the hidden key on the table in the hero's room which is only unlocked after the grandfather dies. Moreover event 2 is set after initial event popup (value 4). |
Ok I added the event bits and it seems to work perfectly. The action event is a bit tricky but I found a way it works. Needs testing for all kind of maps though. |
I tested the dictionary stuff. It's not about wrong values. Even "crypt key" and "ruins" work. The crash depends on the amount of entries. The maximum number seems to be 113 entries. So if you remove some other entries you can set the last byte to 7 and get the 3 texts. I guess it is some bug and didn't occur often in original as you need almost every single dictionary word. |
This is great that it works out! 🥳
We should send a bug report to the Thalion guys. 😂 |
Maybe they left one poor developer in Gütersloh who patiently waits for this one bug report for years. 😁 About the event bits. It is a bit strange that there are 64 bits. Because everyone who decoded the map tile data thinks that the map event index of a tile is encoded by 5 bits (1-31). I wonder why there are 64 bits. Maybe the second 32 bits are used for something else or the tiles/blocks can store more than 32 indices. Have to check if there is any map with more than 32 events inside the event list. |
We did make good progress. Most savegame data is already decoded. As Ambermoon uses reserve space (e.g. chest locked states for 511 chests while there are only nearly half that amount), I guess that there are more than 528 event bit sections. But it will be hard to find out how much as the rest will always be 0. Maybe 1000? 1024? Would be cool because a lot of unknown data would make sense then. 😁 |
Ok 3D maps can have more than 32 map events. Spannenberg has 41. So the 64 event bits make sense. |
Ok i'm back and i see a lot has happened already. Could you please give me some direction as to what would be usefull to decode next and to avoid doing things twice. |
Welcome back. We still need the information about quest progress and monster defeat. The quests are controlled by global variables. That's what I already know. But we need to find the exact location of them in the savegame. For example healing Sally will change some variable so her father gives you a reward. After that he won't give it to you again but will talk more friendly to you. Other quests are freeing the people in luminor's tower or delivering the picture to the head of newlake. The savegame before and after completing a quest should be compared and the differences must be evaluated or at least gathered. Same goes for monsters. Before and after defeating a monster group should change something in the savegame. Today I decoded how NPC conversations work. Next update will contain NPC and ability to talk to them. 2D NPCs are already working on my end. |
Ok I found out that the global variables are located at offset 0x0104. There are 1024 bytes. Each bit is used for one variable. So there are 8192 global variable bits. The map event bits (which control if a map event is active/triggerable) start directly behind that at offset 0x0504. There are event bits for maps 1 to 1024 while only 1 to 528 are used in Ambermoon of course. There are 8 bytes (64 bits) per map. So the savegames are decoded up to offset 0x2504. From this offset up to 0x3504 there is an unknown gap of 0x1000 (4096) bytes. Then only after the dictionary word bits there is possibly some unknown data and that's it. So we almost decoded all of the savegame data. Yay! :) Oh and one word at offset 0x3A is also unknown. Maybe someone will find out its meaning. |
Ok the 4096 bytes at 0x2504 are bits which control if characters are visible on the map or not. Like enable states of NPCs/monsters/party members. So were almost done with savegames. :) |
Update: We now have all important data from the savegame. There is not much left to decode and I don't miss anything at the moment. So I will close this for now. If you have some more info, feel free to reopen this. Thanks for your help. :) |
I was just doing some stuff with fights, so this is not needed anymore?
|
No it's not needed anymore. I decoded the character bits today. They control if map characters are active. This includes monsters. So after fights the active bit is just changed and the monster will no longer appear on the map. |
I could need some help with decoding savegame data. Basically it is easy:
You need WinUAE and a hex editor (e.g. HxD) or even better a hex data comparer (e.g. winmerge).
Process of data decoding:
Possible actions to decode:
There may be other stuff that is stored there. Use your imagination what must be stored so a loaded game knows about it. Note that all chest, merchant and party member data is stored in other files. The same is true for exploration of 3D maps. Those data is mostly decoded except for some character values.
What already is decoded:
Some tips with winmerge
You can just drag&drop both files into the program. Most of the times it does not compare the files in binary format. To do so you can go to "File > Recompare as > Binary".
You will see differences highlighted in yellow. Note that some bytes will always changed (like map position or current time). Those values are located at the beginning. So don't bother with bytes prior to offset 58 (hex 3A) as those bytes are already decoded. The only exception is byte 0-5 which are also unknown yet.
If you mark/select data in winmerge you will see the offset and selection length at the bottom of the window for the file.
@Metibor @Thallyrion Maybe you guys want to help.
If you have some results, please let me know here. Thanks in advance.
The text was updated successfully, but these errors were encountered: