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]

Originally Posted by Nick

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

Can we get a release date on this?

[Nomad]

Originally Posted by Nick

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

Originally Posted by bio_hazard

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]

Originally Posted by kaypy

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]

Originally Posted by Carnivean

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.