Save compatibility?

[Sarin]

So...I've come back after a long time, and I am wondering...would save files from earlier 2.4 dev (1301086950) version be compatible with newest versions?

[geever]

So...I've come back after a long time, and I am wondering...would save files from earlier 2.4 dev (1301086950) version be compatible with newest versions?

I think it should work but not sure. Try loading it and if there is no error/warning on the console and the base buildings are not mixed up, it's probably compatible. If so, resave it with the current version to avoid problems with future revisions.

-geever

[ManicMiner]

My saves don't work from previous versions and the complaint seems to be due to mission maps being renamed or disappearing from the game. I recompiled all maps from source when I updated earlier this week, and that's when the saves broke.

I haven't had time to look at it but if the only thing that screws up a saved game between versions is a map / grid name mismatch and the only reason they're stored in the save game is because of mission history it should be very simple to stop save game corruptions.

[geever]

My saves don't work from previous versions and the complaint seems to be due to mission maps being renamed or disappearing from the game. I recompiled all maps from source when I updated earlier this week, and that's when the saves broke.

You follow Compatibility Announces, don't you?

-geever

[ManicMiner]

Hi,

Yes I do but that wasn't the point. I wasn't complaining the games won't load, but I was commenting on the reason given as to why they won't load.

The savegame format didn't change for months so probably you won't notice it.

The saved games I lost were from April and May of this year so it was always going to be borderline. If the saves had broken due to weapon adds/removes or base component adds/removes I wouldn't have bothered mentioning it (although these were saves from early on in the game so it was all standard tech and standard buildings).

But, according to the logs, the reason they wouldn't load was ascribed to map names from inside the savegame.

There are two ways I could interpret that error:

1.  The error relates to data about missions that have already been played. If this is the case, why should a defunct map name "break" the game load? It's not as if those old missions can ever be replayed so it doesn't matter if the map isn't there anymore.

2. The error relates to data about upcoming missions e.g. UFOs already on screen whether shot down or not already have the battlescape map predetermined. In which case, why would that need to be stored in the savegame instead of the load function just logging a warning and selecting a different map?

The point I'm trying to make is, ideally the game engine should determine which maps are available for upcoming missions, and which aren't - NOT the savegame - so it seems like a very bizarre reason to give for a savegame being rendered unplayable.

[geever]

You still didn't attach your savegame. You think that the map name causes the issue, but I'm not so sure on that. Please attach your savegame so I can test what's wrong.

-geever

[ManicMiner]

Sorry - I thought I did. I'm not at my gaming machine but these are from a pen drive I used to back some stuff up a few months back. They might be the right ones but I can't guarantee it. In any case, on my gaming rig I think I've overwritten most of the saves that wouldn't load.

[geever]

I've checked your savegame and I'm not surprised...

Code: [Select]

Warning: No MapDef with id 'city_rma_medium'!
...

^ There are warnings about missing mapDefs, but it was not the reason the savegame was rejected.

Code: [Select]

...Running subsystem 'base'
Invalid base index -1
...subsystem 'base' returned false - savegame could not be loaded

^ This is the real reason. Your bases have no index saved.

The commit added base indexes to savegames was pushed on Sun, 3 Jul 2011 09:35:54 +0000 (11:35 +0200) into master repository of UFO:AI. And that was definitely months ago, just as I said in the announcement. Your savegames are from April which is seven months old, please, please don't waste my time! thanks!

-geever

[ManicMiner]

You didn't mention that change ANYWHERE in Save Compatibility though. If people don't know you've implemented something that will eventually break savegames then you can't expect them to trawl through code commits to figure it out!

[geever]

You didn't mention that change ANYWHERE in Save Compatibility though. If people don't know you've implemented something that will eventually break savegames then you can't expect them to trawl through code commits to figure it out!

What do you think Compatibility Announcements is for?

-geever

[ManicMiner]

I've just searched for "Compatibility Announcements" on the forums and your last post was the first one since 2009 to mention the phrase.

Even if you're talking about these:

http://ufoai.ninex.info/forum/index.php/topic,3963.0.html
http://ufoai.ninex.info/forum/index.php/topic,3936.msg29791.html#msg29791

They still don't resolve the observation: Your savegame break in July appears not to have been mentioned anywhere.

[geever]

I've just searched for "Compatibility Announcements" on the forums and your last post was the first one since 2009 to mention the phrase.

I won't continue arguing with you, I feel like feeding a troll.

The savegame compatibility change was announced here. I didn't collect all the changes were made in a year or two but why should I? I have better things to do! The effort you made on blaming me could have been spent on rewinding your Git checkout to a version you can convert your savegames with, then update again. I finished this discussion with you.

-geever

[ManicMiner]

Suit yourself. You're the one who's making this out to be a bigger issue than it is, and taking a constructive observation completely the wrong way.

Like I said almost from the first, I didn't mind losing savegames at all and expected all manner of breaks and also said I would've dismissed most other factors for savegame breaks seen in the logs as not worth pursuing - but was concerned that SOME savegame breaks may be caused due to changing information about MAPS being stored in the savegame.

And the only reason I queried that was quite clear:

I recompiled all maps from source when I updated earlier this week, and that's when the saves broke.

I fully expect savegames to break after seven months of not playing but I was surprised to see references to missing maps in the log.

You talk about timewasting - how about YOU wasting MY time trying to locate savegames I don't want or need recovering purely so that you can prove the obvious and then go off on a total irrelevant tangent with the straw man "duh, if you'd compiled from source in July like nobody told you to, the savegames wouldn't be broke" LOLfest.

There was a much simpler question you could've answered... why do savegames refer to mission maps at all, and is there any likelihood that'll break save games. It would've been more pertinent. It's a desiqn question and doesn't need any reference to code.

So, you want to waste your own time creating work for yourself and other people just so you can win an argument with someone who's not even being argumentative, that's your problem.