Darkvater wrote:OpenTTD saveload code can intelligently store and restore pointer relations, compress arrays and handle ALL savegames up to the very first version released
Didn't know that... Doesn't that lead to messy data structures over time?
Darkvater wrote:There are plans to change the saveload system to make it data-driven (eg have some XML-style (since everybody seems to like XML I'll call it that) data descriptors) and be more tolerant to unknown values, but it will take a little while, and is certainly not top priority.
That good ... Didn't know that either...
Priorities are what they are and i don't pretend to be able to change for certain anyone's but my own. If the itch get's to bad I'll stratch it myself.
Darkvater wrote:OpenTTD saveload code can intelligently store and restore pointer relations, compress arrays and handle ALL savegames up to the very first version released
Didn't know that... Doesn't that lead to messy data structures over time?
No. Complicated SL code, possibly, but not messy -- all the mess is wrapped up into nice neat SL_* macros, and everything that gets written is always the latest format, so there's no need to translate from the current internal values to old internal values.
As Dalestan said with the added addition of an AfterloadGame() function that converts possibly old savegames to new ones. Eg if you load a savegame from before v25 (and v25 changed all signals' position in the map array from m3 bits 0..2 to m2 bits 3..5) then in that function code is run to convert these things.
So indeed, the only "mess" is the SL_* macros and their VERSION_FROM and VERSION_TO parts.
TrueLight:"Did you bother to read any of the replies, or you just pressed 'Reply' and started typing?" <@[R-Dk]FoRbiDDeN> "HELP, this litte arrow thing keeps following my mouse, and I can't make it go away."
AN advantage of having two separate save formats (one for disk, one for network sync) is that they can be totally divorced. The network sync doesn't need to worry about version mis-matches in the least; the game only connects with like versions, and the only risk is is somebody modifies their game without changing the version (which is deserving of a hearty error message and disconnect). This would mean that the network sync's save-loader could be pared down to what's required, without being complicated with code designed to read and convert older saved games from disk.
Separated from the network sync system, the disk based save-loader is free to have the overhead of human-readable formatting, or at the very least a self-documenting structure. Unlike newgrf, this is something that XML and similar very definitely are designed to handle. Sure, it'd be much bigger (although XML tags are so redundant that they comress really well) but it would be easier to modify with third party tools, such as external scenario editors, and much easier to parse in order to write a saved game compatible with other, similar games, like Patch. In fact, if Patch's dev team went on board with this idea, there could be a common format that wouldn't be bound to saved game version increments to keep everything good.
Naturally, if this were done, a converter for older saved game versions would need to be made available. The basis for this is in the current code base, and could be removed from the game in favour of an external converter. Once written and stable, that wouldn't need to be updated at all; there's no need to add extensions for features that old game versions will never have.
Of course, this all represents a large amount of work, and the luxury benefits of an easily modifiable saved game format, external scenario editor, cross-game compatibility, etc need to be weighed up against the upheaval, the sustained, intensive testing that a new saved game format would require and the extra work that would have to be taken on by unpaid devs to do this.
