Conversation
|
In my opinion, it should only be on by default if it does not result in overwriting the SaveRAM file in the following situation:
As of right now, it does overwrite in that situation. So I am opposed to auto save. Related, I think we should not automatically make SaveRAM files for movies regardless of this setting. Imo, SRAM should never be written to disk while a movie is (or has been) loaded, except when the user does "Save Save Ram As...", which is a feature that does not even exist right now. |
|
To me, this has limited usefulness, but also limited harm given SaveRAM already saves automatically. This is seemingly only relevant for crashes(?), since SaveRAM typically saves when a game or the emulator closes. It being tied to emulator frame increments instead of real time is a bit odd to me, but I guess it's fine because SaveRAM will generally only changes notably after some frames have elapsed. Regarding "Save Save Ram As...", it would probably be a good addition; however, I don't have a particular problem with the current way movie SaveRAM works and occasionally find it useful, particularly as it saves to a separate SaveRAM file. |
It only does this until the movie is stopped. After that, it will overwrite the non-movie file. And I personally dislike the extra files, since it's just a bunch of clutter and I hardly ever want any of them. |
Not sure what you mean by hand-holding, but zeromus's position is explained in more depth here: #2175 The basic argument seems to be implicit Save RAM flushes create confusion and unintentional file clobbers for users who begin using savestates or movies. Thus, it would be better if users learned to always save intentionally. Not sure I totally buy the "fix" zeromus proposes, but I do think it's a genuine problem. For illustration: say a user been playing a game through BizHawk for some sessions and the implicit saving has been working just fine. Trouble happens if they begin using savestates and particularly movies. The "two-step closing" of movie stopping leaving behind a game instance will mercilessly overwrite the preexisting save. This is a dubious counterintuitive behavior; it means by default there is no way for a preexisting non-movie save to coexist with movie recording. |
long overdue; explicit reversal of the "manual only" policy we had prior
YoshiRulz
force-pushed
the
autosaveram
branch
from
e6f87e0 to
ee0f13b
Compare
|
Are there any reasons that don't involve movies? |
SuuperW
left a comment
SuuperW
left a comment
There was a problem hiding this comment.
RE: savestates
I think that auto save after loading a savestate could be confusing and lead to unwanted loss of .SaveRAM files. The loaded savestate might be from a movie, or a different play session. I don't think there's a good way to detect this even if you know what the user wants, and I also don't think simply turning off auto save after any savestate load is a good idea. I think this problem is a good argument for never having auto save.
But there's really two "auto save" things. This PR is changing the autosave that will only get used as a backup in case EmuHawk crashes. The other auto save is flushing SRAM on ROM close or core reset. I don't see any reason why these two should differ in terms of when they are active aside from the user setting.
| } | ||
| } | ||
| } | ||
| //TODO should we be calling `OnRomChanged` from this ctor? it handles this and a bunch of other things also done here |
There was a problem hiding this comment.
If a ROM gets loaded, it should be getting called by the method that loads the ROM, e.g. LoadRom through LoadRomInternal.
| UpdateCoreStatusBarButton(); | ||
| UpdateDumpInfo(); | ||
| SetMainformMovieInfo(); | ||
| _trackingAutoSaveRAM = Config.AutosaveSaveRAM && MovieSession.Movie is null; |
There was a problem hiding this comment.
This does not work, because the movie has not been set yet at this point. If you open a ROM and then TAStudio right after starting EmuHawk, _trackingAutoSaveRAM will be true. (assuming the config option is on) (... so why is SetMainformMovieInfo being called here??)
This should probably also be a value that just tracks if a movie was used, since a user may wish to change the auto save setting after opening a ROM.
3 participants
Are there any reasons not to do this? HDDs aren't widespread anymore, the user can still turn it off if they want, and I never did figure out what this handholding argument was about.