Change EasyRPG's "SetInterpreterFlag" to make patch overrides temporary

[florianessl]

This PR refactors the EasyRPG feature "SetInterpreterFlag" (#3123), similar to the way @Ghabry suggested there, by making use of some new state flags that have been merged into liblcf.

See liblcf PRs:

• Runtime flags: New bit-fields for storing various interpreter states liblcf#491
• Flags: Do not hardcode one Flag field per class liblcf#492

Rather than setting the global config options directly as before, a new field "easyrpg_runtime_flags" in the SaveEventExecState" struct is used, to make these overrides persist across save/load boundaries.

This makes these config overrides apply only to the Interpreter instance where they have been set, and when the end of the base frame is reached, all of the flags are reset automatically. To make this possible, a new global field "active_interpreter_flags" has been introduced, so the Player functions responsible for restricting use to these custom features can access & consider the state of the active interpreter flags for its check.

Test Project

RuntimeFlags.zip

Set "EasyRPG.ini" accordingly, whether you want to test the explicit enabling or disabling of certain patches.

• Talking to the ladies at the "ON" section should always trigger the test code.
• Talking to the ladies at the "OFF" section should never trigger the test code.
• Talking to the ladies at the "---" section: Here it depends on the patches enabled inside EasyRPG.ini.

Note:
Some extra test code has been introduced via a commit, to make it possible to easily test DynRPG & Destiny support using a simple log command. (@easyrpg_output would always be possible, even without DynRPG enabled)

[Ghabry]

Thanks for finishing the command implementation.

[Ghabry]

Guess this one should be before #3349 as is simpler. All of the conflict in the debug scene. (can you rebase it?) (and remove the testing code)

[Ghabry]

I'll make some adjustments to this myself during the weekend. So no need for you to fix the warnings etc. (also want to check how the code-gen of your code is as this is all checked alot during execution)

Also from now on we should, before adding further flags, think about whether it even makes sense to have them as the flag is only active while in the interpreter context. (also to save flags, we only have 32, so cannot add all of monsca etc. xD).

But is in general useful to have some kind of facility that alters the execution behaviour.

[florianessl]

But is in general useful to have some kind of facility that alters the execution behaviour.

Apropos altering execution behavior:
I've been testing an alternative approach for variable operations & conditional branches for a while now, which uses some sort of dispatching approach using vtables. This could also be used to swap out individual patch implementations for individual interpreter instances, as every interpreter has its own vtable instance.

It seems pretty stable by now & performs well (played through several larger games to really validate that I didn't break anything..)
https://github.com/florianessl/Player/tree/refactor/VariableOps

All this code stems from me experimenting with my ScopedVars branch last year, to make it possible to use all the pre-existing var operations in other new command variants (eg. "ControlVariablesEx" or "ControlScopedVars") without additional overhead.

This would be the important part that is responsible for generating the dispatch tables:
https://github.com/florianessl/Player/blob/refactor/VariableOps/src/game_interpreter.cpp#L5735

[Ghabry]

Good idea with this dispatch functionality. We really have a problem by now with too much "if ManiacPatch" conditions all around the event code.

Better would be to have a "vanilla 2k" and a "maniac patch" version.

Causes some code duplication but event commands usually don't change except for rare bugfixes and reduces the risk of breaking stuff as has already happened far too often when adding maniac stuff :/.

Also allows more compiler flags like "Only Vanilla game support is enough for me" (could be useful for some of the constrained homebrew platforms).

[Ghabry]

In the end my changes were only minor.

Will do some game tests tomorrow, then is ready for merging.

(But the patch stuff needs a refactor someday, Player namespace becomes more and more bloated with this stuff xD.)