#2825 Autosaves can not be disabled

[wintertime]

A number of documentation comments I found tell, if the autoSavePeriod option is 0 there should be no autosaves generated. But thats not what happens.

I already found the cause in a wrong if-statement and prepared a bugfix, which is attached and can be used with git am.

Whats missing is some compatibility code.
For some reason I dont know, this option gets saved inside the savegame instead of a game option file and it was by default 0 although it should have been 1. With the bugfix applied this would cause everyone not starting a new game to not get any more autosaves.
The problem is, if the option would get changed to 1 if its read in from a save as 0, it would again get impossible to disable it.

[Mike Pope]

For some reason I dont know, this option gets saved inside the savegame instead of a game option file

This is normal. All client options are saved in the client-options file within the savegame. When you change the a client option with the ClientOptionsDialog (with the title "Preferences"), it is written to the global client options file, but it also changes the in-game value, which will be written to any subsequent saved games. Or at least this is what is supposed to be happening:-).

You are otherwise correct about the bug, which was almost certainly my mistake. Please apply the patch.

[wintertime]

Ok, I rebased and pushed it.
You plan on relying on users to notice the lack of autosaves and changing the option or not?

[Mike Pope]

The default changed, so only old games will have a problem, which the user can correct if they like. We can describe the situation in the release notes, some people read them. Further than that would require some hairy backward compatibility code --- feel free to write some if you like, but beware that we can not distinguish people who will be surprised by the lack of autosaves from the people that deliberately set the option to zero (and may have been annoyed by the bug). I have a rule of thumb that if backwards compatibility code required mind-reading that we are should fall back to just making progress.

[wintertime]

Yeah, I could imagine some crazy code looking if the 0 is in the config file, not changing it, if its in the savegame changing it to 1 once and increasing the savegame format version number to avoid repeating it, but its probably not worth it.

[Mike Pope]

Certainly not worth increasing the savegame version, which should only happen for big changes/major release.

Feel free to close this bug as fixed.

[wintertime]

Funny, thats again one of these admin only things on SF.

[Mike Pope]

That is just wrong. I found some settings for the bugs tracker and gave them a kick to allow more developer privileges. Have another try now. You may want to log out and log in first.

[wintertime]

Thank you, I can edit issues and there seems also mass edit available now, but only on the bugs tracker, not the other 6.
I could even use edit milestones to fix a long time annoyance and set current as default, to make it less likely reporters keep the wrong fixed_10.1 one. :)

[Calebrw]

I could even use edit milestones to fix a long time annoyance and set current as default, to make it less likely reporters keep the wrong fixed_10.1 one. :)

Thank you.

[Mike Pope]

but only on the bugs tracker, not the other 6.

Should be fixed now. I waited to hear if it worked.

to fix a long time annoyance and set current as default

Excellent. I could not find a way to do that when I last looked.