Follow-up Comment #13, bug #19029 (project freeciv):
Attached patches for S2_4 and trunk with backward compatibility measures
(they're basically identical). This allows these versions to understand all
2.3.x savefiles while keeping a clean format for new savefiles.
Using the savefile compat mechanisms, relative to the previous patch, these
remove backward compatibility cruft from the core save/load functions (saving
~20 lines each). But they add ~5x that to loading, and ~2.5x that to saving.
The latter can probably go one day, but the former will be around forever.
It's a little hard to see this as a win... on the other hand, it means 2.4.x+
savefiles are noticeably smaller due to the new semantics of comment #11.
* A general comment on the compatibility mechanism design: it is particularly
hard to do complex transformations when loading secfiles, since standard
functions can't be used as most data structures aren't set up (we don't even
have map.xsize/ysize). It's hard to see how it could be otherwise while
keeping the compat code away from the main code. Save compatibility is easier
since we have the in-memory data structures (although there's a small chance
of future disturbance of save compatibility code if the in-memory data
structures change significantly, whereas ideally you'd want never to have to
touch it again).
The way I've done it is that from now on, S2_4/trunk "kXX_XXXX" means the sane
version, where before this patch it meant the broken version; "kvbXX_XXXX" and
"knownv2" are not used at all. This means that old S2_4/trunk savegames with
player indices less than 32 will load fine (because sane==broken in that
case), but ones with >=32 will silently break. As cazfi noted elsewhere, that
case is probably rather theoretical. If anyone cares, such files can be
recovered by saving them with saveversion=2.3.0 in an old S2_4/trunk build,
then loading them into a new S2_4/trunk build.
I've taken no measures to allow old trunk/S2_4 to load new savefiles, as that
seems pointless.
I've tested it every which way: starting with file #15322 and with a version
that's been through a fixed S2_3, I've loaded that into a fixed S2_4, saved it
back in 2.3 format and loaded it into broken and fixed S2_3s, both in the same
S2_4 session and via a S2_4 savefile, which I also loaded into a fixed S2_4.
In all cases I looked at the known info on the minimap for both players, and
diffed/eyeballed the savefiles.
Also I tested loading a new "broken" S2_4 savefile (file #15323) and verified
that it did the right thing for player indices <32 when loaded into a fixed
server.
> After fighting a while with gen-roads related savegame issues,
> I really wonder if being able to save in old format is so
> important feature that it's worth the huge maintenance work.
> How many people ever actually save in older format?
I've also wondered why we've committed to maintaining that capability. What's
the use case, beyond occasional convenience for developers?
(But since it's there currently, this patch supports it -- it was not the
hardest part by any means.)
(file #15324, file #15325)
_______________________________________________________
Additional Item Attachment:
File name: S2_4-KnownSaveBitOrder-4.diff Size:12 KB
File name: trunk-KnownSaveBitOrder-4.diff Size:12 KB
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?19029>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
