Emulator Issues #10012
Add auto save state on exit feature
This is a feature request. I'd find an auto-save-state-on-exit feature very useful. With that, when the user stops emulation Dolphin would automatically save the game state. Next time the user chooses that game, the auto-saved state would be loaded automatically instead of the game cold-booting. Perhaps an item could be added to the game list right-click menu to delete the auto-saved state too?
#2 Updated by JosJuice about 4 years ago
It was suggested that Android would do that, but it hasn't been implemented. (It does take a screenshot while exiting, though.)
To anyone who wants to work on this: Please keep in mind that this will make it significantly easier for users to start relying on savestates. Not all users are aware that savestates aren't compatible between certain updates and might be unstable, so this can lead to trouble.
#3 Updated by JMC4789 about 4 years ago
For that reason alone I'd personally reject this feature request.
Until we get to a point where savestates can be compatible for long periods of time/permanently, something like this isn't really reliable. And savestates can bake in bugs, especially on dualcore where games can get into invalid states.
#5 Updated by markk about 4 years ago
I can think of a couple of ways to avoid problems when resuming a state created with an earlier version. But neither is really ideal, either for the user or developers.
Include program version details in the state file. Only auto-resume if the version matches, otherwise maybe present a confirmation dialog with a warning. Perhaps highlight the games which have auto-saves in the game list. Prior to updating Dolphin the user could e.g. auto-load the state then get to the next in-game save point (so the auto-saved state would not be needed).
Create auto-save state files with names which include the Dolphin program version. If the user updates the executable, old auto-saved state files wouldn't be automatically loaded. But they would remain on disk so the user could try loading manually if needed.
Include some kind of version info in the state file. By which I mean state file version because the only changes between some different program versions might not affect the save state format. But having to think "does this need to bump the state file version" for every commit would be a real pain...
The intended use case for auto-saved states would be a quick way to suspend and later resume gameplay without having to manually save and load state. E.g. if the user intends to continue playing the next day but didn't reach the next in-game save point yet.
#6 Updated by JosJuice about 4 years ago
- Status changed from New to Working as intended
Exactly what you describe in suggestion 3 is already implemented in Dolphin since a long time ago. This makes the confirmation dialog with a warning that you describe in suggestion 1 unnecessary - if the savestate format version is different, we already know that trying to load the savestate will end up breaking everything because things are in the wrong places, so let's not offer the user the option to try loading it.
Furthermore, when it comes to suggestion 1: Highlighting games with autosaves is rather pointless, because if you have autosaves turned on, every game you've played will be highlighted (and I'm going to assume that users won't switch autosaves on and off all the time for different games, because then they might as well just make savestates manually without losing time). Besides, just highlighting them won't explain to users that they need to make proper saves prior to updating. We need to write a text about it somewhere, but is it really possible for us to make it show up in a place/way so that users actually will care about it and not forget? And there's an even bigger problem that hasn't been addressed: One of the most commonly reported problems with savestates is that making normal saves sometimes becomes impossible after using savestates too much!
Not automatically loading incompatible save states but keeping them on the disk (suggestion 2) makes perfect sense, but it's a more or less obvious thing to implement considering that we already can detect incompatible savestates.
If the intended use case is when the user hasn't reached a proper save point, this feature will only be useful sometimes. I think it would be better if the user has to take the few seconds to make savestates manually in those cases rather than ending up using savestates even when they don't need to because Dolphin "conveniently" does it for them automatically and they don't know any better. There are many people who don't know how saving works and won't question something that makes booting games quicker.
Anyway, the savestate instability problems are more problematic than version incompatibilities. If the user updates Dolphin and savestates don't work, they can go back to the old version. If savestates randomly don't work and the user hasn't made regular saves, they've lost all their game progress. As long as that's not solved, we should be very very careful with implementing automatic savestates.