Restore From Dump

[eastwind]

A long time ago, in a galaxy far far away, I was able to successfully hex edit a save file for a game that might have been Angband, or Moria, or something else.

One of the things I recall was that the save file had a checksum built into it, so that if you edited a single value you needed to recalculate the checksum and modify that as well or the loader would puke on you. But I don't know if that was Angband or if that feature is still present.

Even further in the past, I remember a save file where I tried and tried to find the value I wanted to edit, to no avail, finally having to compare two save files made a turn apart where all I did was drop money (I think I was trying to hack myself some free money). The problem was about a dozen values changed in that one turn (timers and what not), and I had to go through those by process of elimination until I figured out where the field I needed to touch was.

And even then the hex value stored at the magic offset didn't make any sense. Until *finally* I twigged to the fact that the game had been written in Basic, and all the values were stored as floating point, because that's how numbers got represented internally in Basic. *And* of course the floating point values were stored byte-swapped (aka little endian).

[DavidMedley]

I didn't notice any checksum in this. I just couldn't find the Cur Exp value in the save file, and didn't want to bother with things like resting turn count or history. (I know that wasn't the main point of your tale.)

[Diego Gonzalez]

Changing the savefile format to plain text... Could be useful? Or wise?

[Derakon]

It'd certainly be nice to have a human-readable save file. But it'd be a lot of work for something that's rarely actually useful. It'd also bloat savefile size and save/load times somewhat, though I doubt it'd be noticeable on modern computers.

My guess is that if someone were to present it as a fait accompli then it'd be accepted into the codebase, but I'd be surprised if any of our regular contributors thought it worth the effort.

[takkaria]

A long time ago, in a galaxy far far away, I was able to successfully hex edit a save file for a game that might have been Angband, or Moria, or something else.

One of the things I recall was that the save file had a checksum built into it, so that if you edited a single value you needed to recalculate the checksum and modify that as well or the loader would puke on you. But I don't know if that was Angband or if that feature is still present.

Both Angband and UMoria had that feature. Most Angbands probably still do - but it was lost from V with a rewrite of the savefile code maybe around 3.2.

And even then the hex value stored at the magic offset didn't make any sense. Until *finally* I twigged to the fact that the game had been written in Basic, and all the values were stored as floating point, because that's how numbers got represented internally in Basic. *And* of course the floating point values were stored byte-swapped (aka little endian).

That definitely wasn't Angband

[takkaria]

It'd certainly be nice to have a human-readable save file. But it'd be a lot of work for something that's rarely actually useful. It'd also bloat savefile size and save/load times somewhat, though I doubt it'd be noticeable on modern computers.

My guess is that if someone were to present it as a fait accompli then it'd be accepted into the codebase, but I'd be surprised if any of our regular contributors thought it worth the effort.

Someone (Elly) once did produce something a lot closer to a plain text save file format with key=value pairs or similar. Back in 2010 or whenever it was, it made the savefiles huge and loading them noticeably slow. I rejected the patch for performance and file size reasons - it seemed like a bad tradeoff. Might be different now!

[Pete Mack]

Tak--
In concert with a compression library, human-readable save files might work. It is IO that is slowest, tho decimal-binary conversion still remains a hog.* Xml machine-encoding schemes are a possibility; they are widely used as a compromise between human readability (ASCII), schema conservation (XML), and performance in both disk and CPU.

Here is one written in C.

http://exip.sourceforge.net

The most elegant, though, would be to use the existing parser model to read and write the save file.
You'd have to flatten the various lists--one for dungeon architecture, other for monsters, objects, inventory, and player stats.

As a matter of fact... maybe i should give it a try.

* even in CPU-heavy apps, decimal conversion takes something like 50% of processor time.

[takkaria]

I don't really see the value in re-engineering the savefile code. It would add a load of weight and complexity to achieve the same result, and the advantages (which are minimal) don't seem worth it. But I'm not in charge anymore

[Diego Gonzalez]

Another approach could be to modify the wr_byte and such functions to write readable representation of the data. We could write # comments in the savefile to separate the big sections if someone needs to locate something in the generated code. Its a compromise solution.

[Pete Mack]

Tak--using parse models is a lot more robust to code changes. In essence, the read and write parts of the savefile share schema logic.

[Nick]

A large part of the savefile is byte encoding of dungeon levels, which have no relationship to the parser. I'm with takkaria on this one - I can see it might be an advantage to have human-readable savefiles, but it would be a large amount of work and it's low on my priority list.

[eastwind]

Besides, there ought to be some things only a wizard can do. Union rules and all.

[Sideways]

I don't really see the value in re-engineering the savefile code. It would add a load of weight and complexity to achieve the same result, and the advantages (which are minimal) don't seem worth it. But I'm not in charge anymore

It could be worth it if the human-readable savefiles were also less prone to being broken by updates to the game. (Not that human-readable code would be the only way to achieve that; but it might be a way.)