Savefile compatibility

[Nick]

Can anyone provide me with a single good reason why savefile compatibility is desirable now?

In the past, the big reason was monster memory. That is now in a separate file.

If there is no such reason, then the plan would be that, for example: Angband 8.1.0 would be released; 8.1.1, 8.1.2, ... would all be savefile compatible (as changes in the third digit are just for fixes); then when 8.2.0 is released 8.1.x savefiles will (probably) not work in it.

[MattB]

Nope.
Go nuts.

[bio_hazard]

... for example: Angband 8.1.0 would be released; ...

Can we get a release date on this?

[Nomad]

... for example: Angband 8.1.0 would be released; ...

Can we get a release date on this?

Judging by the timeline of releases from 3.0 to 3.1 to 4.0, you should expect Angband 8.1.0 to land in 2074.

[AnonymousHero]

Not really.

However, there is one case where it might conceivably be desirable, namely Linux distributions where you might get updated from 8.1.3 to 8.2.0 semi-automatically. However, people using those usually know what they're doing -- as long as you get a reasonably clear error message from the game (and it doesn't corrupt the save file) people could just downgrade.

(Though as you say minor version definitely should -- otherwise it'd get a bit too frustrating.)

[Carnivean]

Is there any reason that you couldn't have a save file converter for the players that want to keep playing a character that's in the middle of a game?

[kaypy]

Not having to figure out how to convert save files across is kind of the point to breaking compatibility...

[tumbleweed]

As far as I can tell from glancing over the savefile howto, Angband should already have the facilities in place to support gracefully rejecting whole savefiles or even just the individual parts it can't load any more.

Which makes me wonder why current iterations of 4.0beta crash and burn horribly when attempting to load old 4.0beta saves from before the break.

[Carnivean]

Not having to figure out how to convert save files across is kind of the point to breaking compatibility...

I get that.

However, you have 2 defined file types, with largely overlapping data. Outside of the core game, it seems like it should be possible to fill as much of the new file as exists in the old file, and fill the rest with an acceptable default value. This would leave you with a save file that loads in the new version, without having to change the core game code to facilitate it.

Is there a technical challenge to doing this that I'm not aware of?

[Derakon]

I get that.

However, you have 2 defined file types, with largely overlapping data. Outside of the core game, it seems like it should be possible to fill as much of the new file as exists in the old file, and fill the rest with an acceptable default value. This would leave you with a save file that loads in the new version, without having to change the core game code to facilitate it.

Is there a technical challenge to doing this that I'm not aware of?

Someone has to write the code to do the conversion. If you have that code, you might as well just use it to automatically upgrade savefiles when run under the new version -- you don't gain anything by making it a separate process. The entire point of breaking savefile compatibility is to not have to write that code in the first place.

[Carnivean]

Someone has to write the code to do the conversion. If you have that code, you might as well just use it to automatically upgrade savefiles when run under the new version -- you don't gain anything by making it a separate process. The entire point of breaking savefile compatibility is to not have to write that code in the first place.

Ok, if we assume that to be true (and I have no reason to doubt it), then how hard is that process? Assume that only version X-1 is required.

[AnonymousHero]

I get that.

However, you have 2 defined file types, with largely overlapping data. Outside of the core game, it seems like it should be possible to fill as much of the new file as exists in the old file, and fill the rest with an acceptable default value. This would leave you with a save file that loads in the new version, without having to change the core game code to facilitate it.

Is there a technical challenge to doing this that I'm not aware of?

Yes. It's -- as they usually say in techincal litterature -- a highly non-trivial undertaking. In this case for mostly practical reasons having to do with numbers and positions of those numbers changing all over the place in unpredictable ways.

You can certainly mitigate some of this by choosing a standardized and self-describing file format for savefiles (e.g. JSON or XML), but that's only 1% of the solution.

Ok, if we assume that to be true (and I have no reason to doubt it), then how hard is that process? Assume that only version X-1 is required.

Incredibly hard, unfortunately -- even for a single version. You'd be suprised if you tried it.

(At bottom it all has to do with the non-linearity of changes to programs and the effects of those programs, but I won't bother you with the abstract details.)

EDIT: I should say, that avoiding breaking compatibility is a lot easier (if you have good testing in place and/or are extremely focused on it), but that constrains the things you can do enormously. It's always a trade-off.

[Nick]

As far as I can tell from glancing over the savefile howto, Angband should already have the facilities in place to support gracefully rejecting whole savefiles or even just the individual parts it can't load any more.

Which makes me wonder why current iterations of 4.0beta crash and burn horribly when attempting to load old 4.0beta saves from before the break.

You'll notice that the method in the howto relies on there being a new function to read items every time items are changed. My plan in the restructure process was to have no savefile compatibility with previous versions. So I blew away all the old item readers, and started with just one. Thing is, this one has changed during the rewriting process, so it is no longer compatible with savefiles form early in the rewrite, and there is no nice system of tiered item readers to allow it to fail gracefully.

So this behaviour is not unexpected; it shouldn't ever happen for savefiles from actual proper versions, though.

[Nick]

However, there is one case where it might conceivably be desirable, namely Linux distributions where you might get updated from 8.1.3 to 8.2.0 semi-automatically. However, people using those usually know what they're doing -- as long as you get a reasonably clear error message from the game (and it doesn't corrupt the save file) people could just downgrade.

Thanks - this is a good point. I will make sure to make the error message helpful.

It's also good for me to see that sometimes it's Linux that makes my life more difficult rather that one of the other OSes

[Carnivean]

Yes. It's -- as they usually say in techincal litterature -- a highly non-trivial undertaking. In this case for mostly practical reasons having to do with numbers and positions of those numbers changing all over the place in unpredictable ways.

Thanks. Without looking into the code, and I'm hopeless at reading C, I wouldn't have known that.