Unfortunate conflation/coupling of quick saves and regular save states

[johnnovak]

Please bear with me and let me describe the problem first.

How to reproduce

Start game and create quick saves

1. Use the A500 quickstart config, then start some game or demo from a disk image (because it's easier to see that state loading works when there is some movement on the screen). Let's say we'll test Rick Dangerous.
2. Save this as a new config called Rick Dangerous.
3. Press End+Shift+1 and End+Shift+2 to create two statefiles. These will be created in the the global states files path as Rick Dangerous_1.uss and Rick Dangerous_2.uss.
4. Loading these states with End+1 and End+2 works. So far so good!

Create manual save state (and break reloading previously created quick saves)

6. Now create a new state file manually, say in Games/Rick Dangerous or something. Call it "blah", so the path of the new state file is Games/Rick Dangerous/blah.uss.
7. Try reloading the previously created quick saves with End+1 and End+2 and note that nothing gets loaded. 🛑
8. Now create two new quick saves with End+Shift+3 and End+Shift+4. Note that these are created as Games/Rick Dangerous/blah_3.uss and Games/Rick Dangerous/blah_4.uss. We have effectively switched the quick save base name by creating a manual save state. 🛑
9. You can reload these with End+3 and End+4.

Untick the manual save state (and break all quick save functionality)

11. Now go to the Miscellaneous tab and untick the checkbox next to the the state file dropdown (left to the "Load State...* button). Try End + 1 - 4 and observe that nothing gets loaded 🛑 By unticking the box, we have cleared the quicksave base name and now we cannot load any quicksave. Moreover, we cannot create new quicksaves either! 🛑

Restore quick save functionality and "get back on track"

13. If we restore any of the save states by manually restoring any previously saves state file, WinUAE will read the base path from the state file and will "get back on track".
14. Now we can use quick load again to reload the quicksaves having the same basename as the manually loaded state, and quick saving works again (using the loade state's basename only, of course).

Why this is a problem

At the very least, this is very confusing behaviour and I don't think any of this "emergent functionality" is desired. All the problems come from the conflation of manually managed save states and quick saves.

In my concrete case, I have per-game configs in my upcoming Amiga game pack. I provide quick saves to skip code checks and lengthy loading sequences for some games. Note the configs ending with [skip intro] and [skip code check] in the below screenshot:

These are stored withing the game folders, e.g.

Heimdall
  +-- Disks
  +-- Manual
  +-- Savestates
      +-- SkipCodeCheck.uss

Now, if someone loads the game normally using the Heimdall config, their quick saves will be stored in $BASEDIR\Quicksaves as Heimdall_1, Heimdall_2, etc.

But if they use the Heimdall [skip code check] config which loads the $BASEDIR\Games\Heimdall\Savestates\SkipCodeCheck.uss state first, the quick saves will be placed next to that state as SkipCodeCheck_1.uss, SkipCodeCheck_2.uss, etc.

This is inconsistent and super confusing. It would take a lot of words to explain it to users how to "manually convert" quick saves created with the Heimdall [skip code check] so they can load them when they use the Heimdall config and vice versa. Well, I don't even want to explain all that because the process is error prone and they'll most likely screw it up.

This severely limits the usability of quick saves for my use case, and I'm inclined to not even mention quick saves at all in the documentation.

Resolution ideas

Solution 1

Do nothing, leave everything as is.

I would simply instruct people to never use quick saves to avoid all this confusion (not ideal). But I genuinely think this weird coupling affects not just my game pack but can cause a lot of confusion for any regular WinUAE user.

Solution 2

Completely decouple quick saves from manually managed save states. I can't imagine many (or any) people actively relying on this weird basename coupling, so I think it's safe to improve the situation by making the following technically backwards-breaking changes:

• Quick saves would always be saved as $CONFIG_NAME followed by the _1.uss, _2.uss, etc. prefixes in the global save states folder set in the Paths tab (if no config was loaded, the name would be default as per the current behaviour).
• This quick save basename would never change. Saving or restoring state files manually in the Miscellaneous tab or by bringing up the save/restore state file dialogs would never change the quick save basename.

Solution 2++

My preferred solution. For my use case, it would be even better to have a per-config save state path setting as well. If this is not specified, the global state file path would be used as fallback.

This would be just handy because it's a pain in the ass to manually browse to $BASEDIR\Games\GameName\Savestates\ every single time you load or restore a state via the fila dialogs (and it's a little bit error prone, too). So if the per-config save state path is defined, the save/restore state dialogs would default to this path instead of the global state file path.

Additionally, quick saves would be created in this per-game path which is a nice touch (and there's less chance for name clashes and overwriting previously created state files).

You could even add this as a "hidden" setting (not exposed on the UI) if you're really not in the mood of changing the UI.

---

Thanks for reading this far @tonioni and for considering my request 😄 Also, Happy New Year 😎

[tonioni]

Unfortunately this is by design (But I don't remember why it was done that way), it parses current statefile path and takes the path part when creating new quick save path. It is guaranteed that there is always someone who depends on this :)

Per-config statefile path via config file is acceptable solution.

[johnnovak]

It is guaranteed that there is always someone who depends on this :)

Haha, tell me about it 😅

Per-config statefile path via config file is acceptable solution.

That would be awesome, thank you @tonioni 💯 If at least the quick saves and the manual saves 100% reliably end up in the designated Savestates subfolder of the game set in the per-game configs, everything would be a lot less confusing. Then I could live with the basename switching behaviour, sure.

[johnnovak]

Saw this being mentioned in the 6.0.0 b1 notes. Thanks for the quick enhancement @tonioni 🥇

Can't test it unfortunately due to the save state creation regression:

• [6.0.0b1] Creating save states doesn't work and crashes WinUAE #321

Another thing, would it be possible to also set the current path of the save & restore save state dialog to statefile_path please? Just once when loading the config. This would be a great usability enhancement as people wouldn't need to manually navigate to the statefile_path dir when doing manual saves.

(☝🏻 ignore that; user error...)

[johnnovak]

Confirmed @tonioni, it works beautifully on 6.0.0 beta 3, thanks! 🏅

Is there any chance to backport these three commits to a new 5.3.2 minor release? Then I could include 5.3.2 in my gamepack due to be out in a month or so. I'm just asking because 6.0.0 might far away, maybe only "production ready" by the end of the year. Of course, if 5.3.2 would be too much work, I understand and I'll just wait.

• Per-config statefile path e9e5017
• Add statefile_path trailing path separator if missing 28ce6f0
• Fixed strange window movement when clicking on title bar and keeping it pressed and "Automatically capture mouse when window is activated" was enabled. 64f1306

[tonioni]

5.3.2 might happen but it probably won't happen in next 1-2 months at least.

[johnnovak]

5.3.2 might happen but it probably won't happen in next 1-2 months at least.

Thanks Toni 👍🏻