Currently (0.15-968-g7b322d2), when you try to load a savegame with a different
/ incompatible savestruct, you get a notice that this savegame may be
incompatible, confirm this notice (there is no other option) and the game
freezes, requiring a SIGKILL (i.e. bad luck if you're running full screen, no
tabbing out, no switching to text console, only ssh / serial in or magic sysrq-k
may help).

To prevent running into this problem, read all savegames' version string when
the savegame menu is initialized, and grey out all the entries which may be
incompatible. Add a friendly message saying which game version this savegame
works with and why it cannot be used with the game version currently running.

This would be a lot more user friendly (you just don't want to have users run
into this situation where the game freezes in the first place). 

The could be a hidden / command line / configuration file / build option to
allow overriding this behavior still allowing to try and load these savegames.

You will probably want include version.c on savestruct or somewhere related to
it, so we can compare the version.

Us would probably end up splitting once again the save file, so it would have a
fourth file that store the savegame version. saveload.c would first try load
this file, and if the version is the same of the game's one, it will continue
the procedure. Otherwise, it will abort.
Or we could also add a fourth file with version, but instead of being processed
on load, being processed on menu. Processing on menu can have collateral effects
ie. high loading time before displaying the menu, etc.

The issue, in fact is that after the error shown up, the loading don't stop. I
mean, the error is not fatal, so the game don't crash when you try load. So, you
read the error message. After you click, calmly accepting the information, the
loading DON'T stop. The game continues trying load the game, even if the warning
was done.

In other words: Us need make the game abort the loading after the error message
is displayed.

setting to important because we cannot have the load game trying run a game that
already had shown up a problem.

Sometimes slightly incompatible savegames worked for me. So there is no reason
to force the player to start over, just crashs or hangs should be avoided.

Well it could for example happen that a dialog variable has renamed and your
finishing of a quest is no longer recognized while being unable to do the quest
again, just as an example (for something that might not be easy to notice).

Yes, I've seen such things recently, normally not much of a problem, I could
solve quests once again, or become a guard member once more, because something
on Spencer had been changed. This happened while upgrading from my prevoius
0.15-SVN-something to a stable version from Debian, I think. Upgrading again to
the current git version crashed the game upon loading. I think crashed should
not happen, and can in theory be avoided if everything has reasonable initial
values which get overwritten when loading a saved game. Things missing in the
file would remain in the initial state, things no longer present would be
ignored. Renamed things could even be translated, which is of course more work.

Well, I know that the game have no interest to allow multi-version-compatibility
(by example, you beat the game on 0.16, and use the 0.16 savegame to play Act 2
on 0.17)

In this case, using default values for savegames compatibility only affect Devs,
because the game automatically forbids you to try a 0.15 savegame on 0.16 release.

However, the priority was set to 'important' because the game crashes or enter
in infinite loop when loading a 'broken' (or old) savegame.

According to my analyzes, we were discussing about the crashes when loading old
save games, and that we should gray out/hide the entries that are no longer
compatible on the game. And now we are discussing about allowing the game to
load old incompatible savegames that will only have effect for DEVs.

Personally I think that this is important to prevent players/developers to
accidentally attempt to load incompatible savegames, with the other bug (which I
forgot the ID) that reports the infinite loop when loading incompatible
savegames. (not always we enter in infinite loop. And sometimes we changed
enemy* struct and have one error for bot. We have nearly 1,000 bots on the whole
game.)

The 'infinite loop' (or rather very long loop) issue has been fixed.

As there is no longer an infinite loop and there is now a savegame converter (in
early stages but still...) which in theory solves the base problem, I took the
liberty to close this issue.

If you still believe the savegame should be grayed out, by all means re-open
this issue. Thanks.

On 01/26/2014 12:24 AM, Tom - Roundup wrote:
>
> New submission from Tom <tomreyn@megaglest.org>:
>
> Currently (0.15-968-g7b322d2), when you try to load a savegame with a different
> / incompatible savestruct, you get a notice that this savegame may be
> incompatible, confirm this notice (there is no other option) and the game
> freezes, requiring a SIGKILL (i.e. bad luck if you're running full screen, no
> tabbing out, no switching to text console, only ssh / serial in or magic sysrq-k
> may help).
>

The game does actually not freeze. But a notification is displayed for
each incompatible data. Since we load many datastructures, you actually
have to "click" many times... What has to be done is to avoid to display
the same notification several times !

> To prevent running into this problem, read all savegames' version string when
> the savegame menu is initialized, and grey out all the entries which may be
> incompatible. Add a friendly message saying which game version this savegame
> works with and why it cannot be used with the game version currently running.

That is not as easy.

Usually, there is no savegame compatibility between "official" releases.
Greying out incompatible savegames could work, in that case.

But, we also have to handle as smartly as possible the development
phase. A datastructure change introduced by a commit does not mean that
you cannot load an 'old' savegame.

For instance, a new attribute could have been added that will be
initialized with a default value if not found in the savegame.
Then we can load the old savegame without any issue.

But we could also have change an attribute's type, for instance, or
even have change the meaning of an attribute (and thus the way we
interpret its value). In such a case, loading an old savegame could
possibly crash the game.

>
> This would be a lot more user friendly (you just don't want to have users run
> into this situation where the game freezes in the first place).
>
> The could be a hidden / command line / configuration file / build option to
> allow overriding this behavior still allowing to try and load these savegames.

I would rather propose to have 2 "coded" behaviors:
- official releases do not load old savegames
- development versions try to load old savegames (with a fix the avoid
   several notifications).