search

TASEmulators / BizHawk

BizHawk is a multi-system emulator written in C#. BizHawk provides nice features for casual gamers such as full screen, and joypad support in addition to full rerecording and debugging tools for all system cores.
http://tasvideos.org/BizHawk.html
Other
2.2k stars 385 forks source link

Savestating at/after movie end was disabled #4032

Closed RetroEdit closed 2 months ago

RetroEdit commented 2 months ago

One thing I've been meaning to bring up before the 2.10 release is this change: https://github.com/TASEmulators/BizHawk/commit/e9d6716a331cb3630fdb97e8cc1eeb7c31afad18

This change seems to harm traditional movie rerecording. In 2.9.1 and earlier, I can cleanly continue a movie by playing it to the end, savestating, toggling read-only off, and then load stating to continue the movie. But not in 2.10. There is one workaround: changing On movie end setting to Record. I don't like this workaround because you have to change it before you reach the end of the movie and it's a global setting that can affect later movie sessions if you forget to change it back.

I'm also semi-curious why savestating after the movie end was disabled (edit, I found this: 6364475b2122261e6ecaaa7e2d00bba5380d4f5c). I could potentially imagine it being useful in certain cases, say for instance if you happen to discovered something while pressing some inputs after the end of a movie and want to preserve the inputs. See also #3061.

vadosnaprimer commented 2 months ago

Canonical behavior for the reference https://tasvideos.org/LawsOfTAS/OnSavestates

Morilli commented 2 months ago

Would changing the behavior to allow savestating on the last frame be enough? When making the commit, I was mainly focused on preventing the possible hardcrash, but looking back it should definitely be possible to savestate on the last frame at the very least.

I could potentially imagine it being useful in certain cases, say for instance if you happen to discovered something while pressing some inputs after the end of a movie and want to preserve the inputs.

This has never worked (and isn't supposed to) anyway, because if you're past the end of the movie you're in movie Finished state in which you are not actually recording input. So if you got to an interesting state past movie end and want to preserve inputs, you're out of luck anyway. For that reason savestating there is also not super useful.

RetroEdit commented 2 months ago

Fair enough; I don't like only enabling on last frame, but it seems like a very reasonable compromise for now if the savestates are functionally useless anyway (because you can either save movie for the movie itself or stop movie and savestate for the state itself).

Although it does seem like more of a load/save stability edge case that should be fixable, not something inherently unstable, but development time might be better spent on other things.

Morilli commented 2 months ago

Savestating past movie end could be fixed to work exactly as it should, however when really considering all scenarios I do wonder how useful creating a savestate past movie end really is. Can you save input with that savestate? ... not really. Can you load it as a backup once you extended the current movie? No (this is the part that crashed and if fixed, would just reject the savestate load). Can you continue recording the movie from it if you load it in read+write mode? Also no. From what I've personally seen it seems that most or at least some of the time, savestates past movie end are created accidentally instead of intentionally.

Morilli commented 2 months ago

I'll leave this in a resolved state for now as you can now savestate at movie end, and let's track whatever is/should be happening past movie end in #4035.

As is I don't see much use in being able to savestate in movie finished state.

RetroEdit commented 1 month ago

I think it's partly because the old long-standing default didn't pause at movie end ( #4007 ), so being able to continue a movie even if you were a bit past the last frame was useful.