Skip to content

Re-Implement locking feature #30

@FramePerfection

Description

@FramePerfection

Is your feature request related to a problem? Please describe.
The original version STROOP has a feature to "lock" variables that invokes the value setter for that variable with a fixed value on each STROOP update. This is occasionally useful for testing purposes.

Describe the solution you'd like
While the original implementation appears to work well enough for some purposes, its behavior does not guarantee any specific state of the game at any point in time, because it is fundamentally desynchronized from the game's update logic.
To address this issue, a hack shall be injected instead that sets the value of specific memory addresses to fixed values at a certain point in the game's update loop, for example after querying input or similar.

Is your feature related to software outside of the scope of STROOP?
A dedicated hack needs to be created that can perfrom the actual "fixing" of the variables. This is always in theoretical conflict with ROM hacks and other, unrelated RAM hacks. Therefore, it may be advisable to provide an option to choose where to place the hack in RAM.

Describe alternatives you've considered

  • Since mupen is an emulator, it should theoretically be possible to spoof its memory reading behavior in such a way that reading specific addresses would always yield the "fixed" value rather than the actual memory contents. However, there is no such API, and it is unlikely to ever exist.
  • LUA scripts can achieve much the same as the proposed solution with a hack, but are less convenient to use. It may be a viable option to control a dedicated LUA script via STROOP, however no such interfacing has ever been done before.

Additional context
The original implementation was deeply interwoven into the concept of a "WatchVariable", which, while providing the option for nearly every variable (so long as it has any form of setter), is an additional burden in extracting the "core" logic from the UI presentation.
As such, this feature should not be implemented before the core logic is cleanly extracted from the UI.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions