Error with auto-upgrading pretty old savegame to rev 50: stance

[ChrisOelmueller]

• Store this savegame in .unknown-horizons/save/: Attachment: loading_problem.sqlite
• Try to load it

Failed to load /home/eoc/.unknown-horizons/save/loading_problem.sqlite
Traceback (most recent call last):
  File "/home/eoc/UH/unknown-horizons/horizons/main.py", line 325, in start_singleplayer
    _modules.session.load(options)
  File "/home/eoc/UH/unknown-horizons/horizons/spsession.py", line 43, in load
    super(SPSession, self).load(*args, **kwargs)
  File "/home/eoc/UH/unknown-horizons/horizons/session.py", line 230, in load
    savegame_db = SavegameAccessor(options.game_identifier, options.is_map, options) # Initialize new dbreader
  File "/home/eoc/UH/unknown-horizons/horizons/util/savegameaccessor.py", line 61, in __init__
    game_identifier = self.upgrader.get_path()
  File "/home/eoc/UH/unknown-horizons/horizons/util/savegameupgrader.py", line 408, in get_path
    self._upgrade()
  File "/home/eoc/UH/unknown-horizons/horizons/util/savegameupgrader.py", line 349, in _upgrade
    self._upgrade_to_rev50(db)
  File "/home/eoc/UH/unknown-horizons/horizons/util/savegameupgrader.py", line 50, in _upgrade_to_rev50
    db('UPDATE stance set stance = "hold_ground_stance" where stance = "hold_ground"')
  File "/home/eoc/UH/unknown-horizons/horizons/util/dbreader.py", line 48, in __call__
    self.cur.execute(command, args)
OperationalError: no such table: stance

[stubb]

The attached file has the savegamerev 15, not sure if its worth looking into this issue at all. I remember that some early savegame revs were made invalid, does someone knows more about this? I wasn't able to find a related commit.
Adding a MIN_SAVEGAME_REV to the constants would be nice to check if an upgrade is possible at all.

[stubb]

Is there any interest in getting such an old savegame to load? My interpretation is that this issue is about a proper handling for such old savegames?

[ChrisOelmueller]

I'd be fine with simply refusing to load savegames past a certain revision as long as that's handled gracefully. Definitely better than a crash.
As you can see from the traceback though, the problem seems to be in savegame-upgrader code itself, which is a bit more hairy, at least in terms of fixing the crash (need to check that the upgrade code still works correctly for other saves).

Do we have some details on which changes / releases broke approximately which savegame versions? Without this data, would you just place arbitrary cutoff points somewhere? Perhaps checking which savegame versions were produced by each release (and maintaining that list in the future) could be good, this is not the first time I'd have liked a table like this, and it seems simple enough to look up.

[stubb]

Its only checked via the GUI code if a savegame is upgradeable, iterating over a list from the real savegame rev to the rev which is used for new savegames and checking if there is a upgradecode for each step. This prevents the crashing, but simply is used in the wrong placed in my opinion. Thats something that needs to be fixed.

Currently the upgradecode for the lowest rev is 49, so I think 48 will be work. Maintaining such a list, maybe in the changelog would be a good starting point. Also some testing which is the lowest rev we can upgrade currently.

[stubb]

2014.1 74
2013.3 73
2013.2 71
2013.1 70
2012.1a 56
2012.1 56
2011.3 43
2011.2 15
2011.1a 12
2011.1 12
2010.1 8

Not sure whats a good place to store that information, maybe in the beginning of the Changelog?