Restore From Dump

[takkaria]

Originally Posted by 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.

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]

Originally Posted by 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

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.)