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

Making and closing from-SaveRAM movie clears casual SaveRAM #4147

Open
YoshiRulz opened this issue Dec 28, 2024 · 4 comments
Open

Making and closing from-SaveRAM movie clears casual SaveRAM #4147

YoshiRulz opened this issue Dec 28, 2024 · 4 comments
Labels
App: EmuHawk Relating to EmuHawk frontend

Comments

@YoshiRulz
Copy link
Member

YoshiRulz commented Dec 28, 2024

initially reported on Discord or maybe TASVideos Forum but I lost it

see also #2437

@YoshiRulz YoshiRulz added the App: EmuHawk Relating to EmuHawk frontend label Dec 28, 2024
@YoshiRulz YoshiRulz added this to the 2.10 milestone Dec 28, 2024
@Morilli
Copy link
Collaborator

Morilli commented Dec 28, 2024

This has nothing to do with saveram movie or not; .SaveRAM files are created based purely on the name of the movie. So if movie name == game name then the movie's save ram will overwrite the casual play one.

@CasualPokePlayer
Copy link
Member

CasualPokePlayer commented Dec 28, 2024

So if movie name == game name then the movie's save ram will overwrite the casual play one.

This is not an issue, the game name is placed in first before the movie name. In this case, you'd just end up having game name.game name.SaveRAM be created, which does not affect the casual save.

The issue would likely more come up once you stop playing back a movie. Then proceed to close the ROM/emulator. There's no movie playing, so BizHawk will happily overwrite your casual SaveRAM. The user can avoid this if stopping the movie came by closing the ROM/emulator in the first place and letting that do an implicit movie stop.

Note that this behavior might be relied on in some cases (I've definitely abused it at some point). A fix might best be flagging loaded SaveRAM being from a movie (note this would apply too for power-on and from savestate movies) upon stopping said movie, and warning on the first attempted flush if the user wants to overwrite their casual save.

@YoshiRulz
Copy link
Member Author

Dupe of linked issue then? Either way, not getting into this release.

@YoshiRulz YoshiRulz removed this from the 2.10 milestone Dec 31, 2024
@CasualPokePlayer
Copy link
Member

CasualPokePlayer commented Dec 31, 2024

I think the linked issue is just wrong, there are separate SaveRAM files for TAStudio in the first place. If you proceed to close TAStudio however, you just go back to casual SaveRAM being used, as you aren't using TAStudio anymore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
App: EmuHawk Relating to EmuHawk frontend
Projects
None yet
Development

No branches or pull requests

3 participants