search

sourcehold / sourcehold-maps

Reverse engineering the map file format of Stronghold
GNU General Public License v3.0
20 stars 3 forks source link

Public Brain Dump #11

Open J-T-de opened 4 years ago

J-T-de commented 4 years ago

Already sorry for the mess, but it is hard for some information to find the correct place. This is why I dump it here (before I forget it), some parts might also need to be discussed.

  1. there are not only .map and .sav files, but also multiplayer save files *.msv.
  2. This is something I did quite a while ago and I am not 100% sure of it anymore, maybe validate before adding: the 0th unit in the Unit Array Data Section (1015) is an "uninitialized unit" if I remember correctly (not currently selected unit). If one places a unit on a new scenario map, the unit (with minimum information) gets written in this section. If one selects the unit, it gets initialized (copied in the correct unit slot. There are other ways to trigger this initialization
  3. Someone some time ago found out, that there is not only a unit cap, but also a game-sprite cap. If placing a map full with units, and afterwards placing a rock, this person claimed that units disappeared due to a sprite cap. So it makes sense to assume, that one of the sections contains all sprite data...

General map info

  1. The data should be partly in here, right?

General game experience

  1. viewbox should be specified in section 1018 and 1019 (see PR) and the screen resolution

  2. I am quite sure that game speed is not saved (or at least it gets ignored), as in Single-Player, a game always starts with the players current speed and in multiplayer, the game starts with game speed 40 (game speeds are adjustable with the UCP)

  3. zoom level is probably saved (at least for the scenario editor) per session, and not in the map file. same seems to be true for the flattened view

  4. Map orientation is saved in section 1044

  5. It might be useful to split shc_data.CT in multiple lua files and work with imports as I updated the stuff in my repo. It's hard to find stuff in a single large file. Maybe also add a file where all the section offsets are at runtime?

  6. It is kinda hard find stuff in the repo (like (this)[https://github.com/sourcehold/sourcehold-maps/blob/master/sourcehold/maps/__init__.py] and (this)[https://github.com/sourcehold/sourcehold-maps/blob/f8c6914dc89bacada9aa6ffc928b3b222fd512cf/sourcehold/maps/sections/__init__.py], which would have saved me a lot of time if I had found it earlier, I find myself reinventing stuff regularly, only to find it at some point somewhere in the repo). Some restructuring (plus some documentation) would be amazing.

  7. One easy refactoring would be to merge the folders (structure)[https://github.com/sourcehold/sourcehold-maps/tree/master/structure], (documentation)[https://github.com/sourcehold/sourcehold-maps/tree/master/documentation] and cheatengine (only the structures) like this: structure/kaitai structure/cheatengine When I am done, I can add my construct definition to structure/construct (there are still some unresolved problems, unfortunately, but I am working on it) and put the *.CT file into a folder like process_inspection (In analogue to file_inspection).

Cheers!

gynt commented 4 years ago

(I numbered your comment to make it easier to reply)

  1. awesome, I do not have any .msv files, but they are very welcome.
  2. that would make some sense! It also happens for buildings and players, so we can at least verify if it is the same for buildings.
  3. I assume the underlying entities truly disappeared from the game? Or were they invisible? That is crucial to know, because if it is the latter case, then it could be a game rendering cap, not a file imposed cap.
  4. yes! Unlocking a map works for example. But I cannot find these sections in process memory, so debugging them is a bit tedious (loading map, checking all UI elements for changes). I am going to work an a comparison of all .map files to see what changes. There is a section (in .sav files) that grows over time, interestingly enough.
  5. nice work!
  6. I observed the same thing.
  7. Agreed.
  8. Cool! Thanks, that brings us a step closer to offline rendering of maps.
  9. Yes will do. Some offsets are still wrong, but one place to update them makes sense.
  10. Yes, the subfolders are terrible. I will make everything less hierarchical, and reflect the wiki a bit more. Any comments are welcome.
  11. Will do!
J-T-de commented 4 years ago
  1. (Just for people stumbling about this, gynt opened an issue: https://github.com/sourcehold/sourcehold-maps/issues/12 )
  2. Please check this before you take this granted, past me is sometimes sloppy and current me is always suspicious about past me^^
  3. I cannot remember, I will find out
  4. The growth might happen due to statistics appended somewhere... I analyzed the section sizes of Stronghold, Stronghold Crusader and Stronghold Crusader Extreme, I still need to write it down...
  5. I will think about it. But as I have no full overview (and files import other files), this will be quite some work that things don't break...