TAStudio must clear state cache after a hex edit / poke / freeze

[SergioMartin86]

Mix between feature request and a bug report. The video here explains it better than a lengthy report:

https://www.youtube.com/watch?v=UjnguAbnapQ

Basically, modifying a value in memory should invalidate all cached states that have been stored ahead, just like changing an input would. This ensures the modification is properly stored if a re-record is made thereafter.

[RetroEdit]

+1 for invalidating the greenzone for frames after a RAM poke.

Personally, I'd like to see new frames after a RAM poke should use a different color/symbol (purple?) for the greenzone in TAStudio to clearly communicate modified game state.

[SuuperW]

If such a feature is made, it should be optional. I want to keep my greenzone when I poke. Also, you might want to include pokes from Lua as well. (I've encountered this situation with Lua pokes several times.)

Clearing cached states the same way an input change does is also not sufficient. You must also capture the current frame, else a rewind to the frame you made changes to will not keep the changes.

And even if you do that, rewinding to a frame before the changes would also not keep the changes. Playing forward from there would cause a desync. Because of this, I do not think this is a good idea. You cannot prevent the user from causing a desync. Attempting to automatically manage this is likely to lead to further confusion and users not knowing when or if their savestate cache contains hacked frames.

Far better imo to make a hotkey that clears greenzone and captures the current frame. Then users who want such behavior can trigger it and there is no confusion about what's in states.

Personally, I'd like to see new frames after a RAM poke should use a different color/symbol (purple?) for the greenzone in TAStudio to clearly communicate modified game state.

I suppose something like this could prevent confusion about greenzone containing hacked states.

[SergioMartin86]

yeah, agree -- a "clear all greenzone and capture frame" is the right thing to do, though I think this is better done automatically upon poke instead of having a hotkey.

The purple coloring also seems very important, lest you forget you're in a hacked/non-reproducible state

[SuuperW]

I think this is better done automatically upon poke instead of having a hotkey.

I would not want this. I want to be able to poke without invalidating.

Also, what would be the performance implications of doing it automatically?

[YoshiRulz]

Tainted savestates is a bug, because cheating in movies is undefined behaviour, and we never should have allowed it.
But since we have it as a "feature" already, I'd support a Cheated flag on states and displaying them in purple or w/e.

[RetroEdit]

UX-wise, I now agree with Suuper in that memory pokes would still require care even if they did auto-invalidate, and retaining flexibility is useful for power-users. Toggling inputs is already a solution for invalidating greenzone.

I think proper robust safety would need #4571

Tainted savestates is a bug

If memory edits didn't save in savestates, that would seem to remove much of the usefulness of RAM pokes and editing in BizHawk's hex editor. It's a genuinely useful TAS workflow for experimenting with different conditions.

[YoshiRulz]

We could have had it so greenzone stops being appended to after you poke, allowing experimentation with no risk.

[SuuperW]

Tainted savestates is a bug, because cheating in movies is undefined behaviour, and we never should have allowed it.

If you never had allowed it, I would not have ever used an official release of BizHawk for TASing. That is not an exaggeration. And I don't see how it's undefined, it seems very clearly defined to me.

We could have had it so greenzone stops being appended to after you poke, allowing experimentation with no risk.

This would genuinely be a useful option to have (though perhaps would be mostly obsoleted with good UI indication of when current or captured states are cheated), but again must be optional. Poking during a TAS is a vital feature for experimentation and many situations heavily benefit from capturing cheated states.

[YoshiRulz]

Can someone estimate how many LOC it would be to add such a flag to, I guess it would be IStateManager?

[SuuperW]

External tools can access the IMemoryDomains emulator service. You would have to either remove that access or modify all MemoryDomain implementations and have them set the flag. But it's not clear how a MemoryDomain would even be able to access such a flag. I guess you'd have to add a member that references the flag, and the emulator core would own the flag. And then every single core would have to be updated to include that flag in its savestates in order for the flag to be preserved when external tools load a state through the IStatable emulator service.

EDIT: I am in favor of removing access to emulator services for external (and internal) tools, btw. (We would probably need some new IExternalApi methods to cover some use cases.)