Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GeneralConfig: Option to autoload most recent savestate at game launch. #3087

Closed
wants to merge 1 commit into from

Conversation

void-ghost
Copy link
Contributor

@void-ghost void-ghost commented Sep 24, 2015

This allows you to continue to play from the last savestate you've made. You don't need to remember into which slot you've saved last, you don't need to wait for some strange heavy iso-disc access to complete before you can play the game (hi, Xenoblade). The game just continues from the last save.

Added a new option into dolphin.ini and a checkbox to Config->General.


This change is Reviewable

@MayImilae
Copy link
Contributor

Why can't you just press F1 as soon as the game has been loaded? That doesn't sound very hard...

And frankly, relying on savestates is a bad habit, as they can be broken by any number of things (see the forum) and destroy your save data.

@void-ghost
Copy link
Contributor Author

You also can ask "why you can't launch dolphin through commandline and specify all the options". And still we have UI and configs.
It's just quality-of-life change. Why not?
On your argument about reliability of savestates - it is problem in itself. If they are unreliable then they should be fixed or removed. And I'm sure that many players use them far more often then in-game saves, even knowing about their limitations.

@MayImilae
Copy link
Contributor

That's not a fair comparison at all! The command line requires obtuse learning of specific commands, and offers no way to learn said commands or how to combine them. A UI is far more friendly, since the only learning required is basic reading. Meanwhile, pressing a single button after a game loads? That's not hard.

And yes, I am definitely worried about users getting too comfortable with savestates - because it is already a problem. If savestates become the primary or only method one uses to save, which this method would encourage, than they will learn the pain of it breaking, which it will inevitably do. They are not meant for long term use! In their unstable state they are useful for temporary things, like saving before a boss so you can reload if you die, and then standard saving afterward, so they shouldn't be removed because of that.

@void-ghost
Copy link
Contributor Author

So let's move it to advanced tab? (As if it'll help...)

@MayImilae
Copy link
Contributor

Well... I could keep going, but honestly... I think it's best to wait on this. sigmabeta is planning to set up a system to create a savestate on emulator close and then auto-load a savestate on reopen. This is to match android behavior, but it would accomplish what you are wanting with this PR far better than this alone, I think. And since it will be a standard behavior for the emulator on a platform, it's going to be vetted, nitpicked, bikeshed, and heavily tweaked to avoid savestate problems! So I think it might be best to wait until sigmabeta implements that, and then just create a version (yes please, in the advanced tab!) for the main Dolphin?

@phire
Copy link
Member

phire commented Sep 24, 2015

Major, i don't think we should block a feature just because someone is planning to possibly do somethi g in the future.

Void-ghost, The idea is good, but I don't like the way it is hacked into hotkeys.

@dolphin-emu-bot rebuild

@void-ghost
Copy link
Contributor Author

Yeah, I was working on save-on-exit too. I see no problem, if it's already in development then I just keep that branch to myself, until it appears in main.

@dolphin-emu-bot
Copy link
Contributor

FifoCI detected that this change impacts graphical rendering. Here are the behavior differences detected by the system:

automated-fifoci-reporter

{
if (!silent)
Core::DisplayMessage("State doesn't exist", 2000);
} else

This comment was marked as off-topic.

@lioncash
Copy link
Member

I agree with @phire with regards to how it's intertwined with the hotkeys.

@@ -177,6 +177,7 @@ void SConfig::SaveDisplaySettings(IniFile& ini)
display->Set("PAL60", bPAL60);
display->Set("DisableScreenSaver", bDisableScreenSaver);
display->Set("ForceNTSCJ", bForceNTSCJ);
display->Set("AutoLoadSavestate", bAutoLoadSavestate);

This comment was marked as off-topic.

@Rukario
Copy link
Contributor

Rukario commented Sep 25, 2015

I'm not really in support of this change.

Like MaJoR said, why not use hotkey to load savestate 1 the moment you boot the game? It's just one step away.

If this option is a thing, how much steps will it take to NOT autoload the savestate on boot?

@void-ghost
Copy link
Contributor Author

It'll take three mouse clicks: General -> Autoload latest savestate -> OK.
Or none (this option is off by default).

@Rukario
Copy link
Contributor

Rukario commented Sep 25, 2015

Lol, the users will have to go through the settings just to be able to turn on or off the autoload feature.

I'm sure if you held the hotkey while starting the game emulation it will be pretty much as if the autoload feature was enabled.

@void-ghost
Copy link
Contributor Author

That hotkey is not bound by default. So, no, user had to remember in which slot he saved last.
So the user had to go to Options -> Hotkey Setting, find "Load State Last 1" hotkey among ~90 hotkey, bind it to some key. And after that he still be needed to hold/smash that hotkey on game launch.
(And I doubt that many players are even aware that "Load State Last 1" means "Load Last Save".)
Compare that to General -> Autoload latest savestate -> OK. The latter is much more straightforward, in my opinion.

@i30817
Copy link

i30817 commented Oct 4, 2015

I've seen people complaining about accidentally quitting a game on emulators so a savestate on close would be nice for them.

@RisingFog
Copy link
Member

Has any progress been made with this PR?

@JosJuice
Copy link
Member

JosJuice commented Apr 9, 2017

We don't want to add this to Dolphin, for the reasons described here: https://bugs.dolphin-emu.org/issues/10012

Because of that and because the PR hasn't been updated in a year and a half, I'm closing this.

@JosJuice JosJuice closed this Apr 9, 2017
@i30817
Copy link

i30817 commented Apr 9, 2017

For what it's worth, that is not much, i just want to say that this part of the argument for closing:

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.

Can be mitigated by just not saving on exit (overwriting it) if the special savestate didn't load on start of the game for some reason and warning the user to try the earlier version of the emulator and normal save. It's not hard to prevent, and something you'd probably want anyway even if savestates were stable.

@JosJuice
Copy link
Member

JosJuice commented Apr 9, 2017

@i30817 By "randomly don't work", I didn't mean that the loading process has a chance of failing, I meant that savestates might be saved with bad data and thus always be impossible to load correctly regardless of which Dolphin version you use.

@i30817
Copy link

i30817 commented Apr 9, 2017

Just noticed i skimmed right over the first line like a schlub. Sorry about that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

10 participants