Need pointers on understanding the code base, specifically load/save format

[jackdw]

Downloaded the source and have it compiling on my system. I am trying to start figuring out certain blocks of code, starting with the save/load game which is an interest of mine.

To make sure I (thought) I understood the compression, download http://www.7-zip.org/sdk.html and tried using their example decoder application in C#, and it complained that the properties loaded from the first 5 bytes (after the 8 byte header for OTTX files) is incorrect.

Am I just reading the code wrong (its been years since I read C++ to be fair), or are there some functions that I am missing on?

Thanks for help getting me started!

[Alberth]

Save / load game format is defined in the source code, in src/saveload, as you no doubt has discovered. It's a quite non-trivial format, and it's not stable, every now and then patches get merged that change the file format. In addition, if you want to decode stuff, you basically have to build the all data structures of OpenTTD. As such, the best decoder and encoder for a savegame is the game itself. It also buys you free backwards compatibility for everything since the original TTDX program, as well as forward compatibility, except if a new version changes the data you're using.

So do yourself a favor, and build whatever you want to do in the game itself as a patch.

[ino]

OTTX is specifically xz format. After stripping OTTX (first 4 bytes), it become standard .xz and you can decompress it like any other .xz file.

Mind you, even though the file is RIFF-like, it is very complicated. Even parsing the file to get to specific section already require a lot of code. I have written a tool to manipulate sign in save game before, and it definitely not trivial.

[lcd_47]

Mind you, even though the file is RIFF-like, it is very complicated. Even parsing the file to get to specific section already require a lot of code. I have written a tool to manipulate sign in save game before, and it definitely not trivial.

Decoding is tedious (mainly because you have to compute various offsets manually), but I wouldn't really call it complicated. The main problem in writing an external decoder is that some information is only computed at runtime, and duplicating those calculation in the decoder would be next to impossible.

I wrote two Perl scripts, one that unpacks saved games (the result is directly loadable), and another that decodes the data and formats it based on a template. The second script is unfinished but it's mostly usable; it would take maybe a day to finish. If you want them they're at GitHub.

[ino]

Decoding is tedious (mainly because you have to compute various offsets manually), but I wouldn't really call it complicated. The main problem in writing an external decoder is that some information is only computed at runtime, and duplicating those calculation in the decoder would be next to impossible.

Yeah you end up duplicating tons of code from the game itself. But I'd still call it complicated.

My use was that I have a list of sign I want to place in the game, as I want to real-world station locations into the map. Having work with RIFF before, I initially expect to read chunk name, read chunk size, skip, and repeat, until I find the chunk for SIGN. Turns out the size is not coded for array data, so it gets more complicated than I expected. My entire code is only around 200 lines of C++ code (with a few functions copied directly from OTTD code, like SlSkipArray) though. I was lazy and handle compressing/decompressing by hand (xz/unxz + hex editor).

[orudge]

For what it's worth, I've worked on a couple of projects to decode OpenTTD games in C#. One, which was fairly feature-complete, basically includes a slightly trimmed down version of OpenTTD in DLL (or .so / .dylib) format, and uses it to pull data from the game. At some point I really should release it! The other, which is not, was more of an experiment in being able to read the raw saved games directly, and using a tool to basically translate the saveload tables in the OpenTTD source into a format that could be understood by my game parser. (Basically just reimplementing the saveload functions in C#.) I think I got it pulling out some basic data on things like companies, but it would be quite a bit of work to cover vehicles, industries, towns, etc. It would have the benefit of not requiring large binary dependencies, but would be more of a pain to keep up-to-date than the first solution.