Cross-version savegames

[nemchenk]

http://ufoai.ninex.info/forum/index.php?topic=1253.msg6697#msg6697

Note that you will have to start again. The savegame code was worked on hard (mainly by mattn, I think). So savegames between versions are not compatible.

I just want an update on this -- cross-version save games seem quite crucial. Do the devs need any help with this? Some kind of struct<->xml type system, perhaps?

[Mattn]

i don't really see the point in adding such a system.

we keep savegame compatibility in between the different branches, e.g. for 2.2 and 2.2.1

but for 2.3 there are (or will be) so many new features that it just wouldn't make any sense to try to load an older savegame where half of the data is just missing. xml is nice, but imo no good option, i would really like to keep the dependencies low.

[nemchenk]

Would make the -dev versions more playable, and thus play-testable?

And, it doesn't have to be XML -- that was just the first idea.

[Mattn]

what would be your idea for this? please come to our irc channel and let's discuss this there.

[nemchenk]

Hi Mattn,

What time do you tend to be around on irc?

[Mattn]

8cet - 22cet

[Duke]

Has this discussion ever taken place ? What were the results ?

The reason I'm asking is that I glanced at the corresponding code and I think I have an idea how we could create backward compatibility (with rather little effort) while staying *within* the current system of binary saves. It doesn't seem to be a technical problem.

So the most important question is: Do we WANT backward compatibility ?

I strongly support nemchenk's argument

Code: [Select]

Would make the -dev versions more playable, and thus play-testable?
On the other hand, enabling hundreds of users to test 'bleeding-edge'-svn code and report bugs can also be a nightmare (for a small team) in terms of answering bug reports...

Is there a set strategy on this ?

[Mattn]

So the most important question is: Do we WANT backward compatibility ?

in general no - for our svn testers we have a workaround with 2 revisions on save-game breaking and for new releases it doesn't make much sense due to new features and so on.

it would clumber the code imo.

[Duke]

a workaround with 2 revisions on save-game breaking

No clue atm. Is the procedure described somewhere ?

it would clumber the code imo.

Just a little bit imho. Let's make sure we both are thinking of the same approach.
My idea was to pass the (already existing) savegameVersionNr to all those *_Load() functions.
Inside those functions we then could do

Code: [Select]

load this
load that  // old stuff
if (savegameVersionNr >= 27)
    load newAttrib
else
    newAttrib = 42; //reasonable default

As long as we just add attributes to the end of existing structs that would be affordable imho.
Adding completely new structs could be handled by adding a column 'sinceVersion' to the table of _Load/_Save functions.
Admittably, changing the format (eg. short to int) of existing attribs or inside nested structs would clutter the code much more.

Of course you have the better overview of the frequency and type of savegame changes (as I have none).
So let me put it this way:
My plan is to enjoy playing through a 2.3 campaign and report and/or fix every bug I encounter. Guessing from how long it took me to play through 2.2.1, this will take at least 3 months. So from your experience, how many savegame incompatibilities (ie. campaign restarts ?) will I encounter during an average 3 months ?
Or will the workaround you mentioned above allow me to finish the campaign ?

[geever]

No clue atm. Is the procedure described somewhere ?

Not yet. From player's view it's easy:
1. Update to the first revision of savegame-break (use svn logs to find it).
2. Build, run. Load and resave all your savegames.
3. Update to the latest revision (or at least the next).
4. Build, run, enjoy.

-geever

[Duke]

Thx, geever
So the concept is to commit the *_Save() changes to one revision and then the *_Load() changes to the next rev, right ?
Clever

[geever]

Right.

And I'm going to make another save-game break soon.

-geever

[Mattn]

the savegame version is already passed to the load functions - see the data pointer

but it's always clumbering the code - and it makes absolutely sense in between minor releases. but major releases would have it removed anyway - due to the nature of all the new features that aren't saved in old savegames

[Duke]

the savegame version is already passed to the load functions - see the data pointer

Ouch...sorry for wasting your time.
As I said, I only *glanced* at the code, so I was misled by the naming in the interface:
qboolean B_Load (sizebuf_t* sb, void* data)

I must have associated something like (size_t length, void* data).
Is there a special reason why this must be a void* and not a saveFileHeader_t* ??

[RudolfoWood]

Thx, geever
So the concept is to commit the *_Save() changes to one revision and then the *_Load() changes to the next rev, right ?
Clever

Yes, additionally, in older revision check checking (savesubsystem.check) must be disabled for latest addition. That was the part I stumbled upon...