New Operations for ControlVariables / "ControlVariablesEx"

[florianessl]

Some suggested new operations for a custom "ControlVariablesEx" command. (These are currently disabled for the vanilla one, Command Code '2022' has to be used)

'210': DateTime: Jetrotal's "GetTime" command

Cherry Picked & refactored Jetrotal's extension from PR #3124 , so it can be used like any other variable operation. In the comments I included a suggestion, for how this could be adapted to also allow name-based lookup via strings.

~'211': ActiveMapInfo~

~Width & Height are two important infos about the current map I've long desired for ControlVariables. I've seen that in the meantime, some new Maniac command has been added, that also finally allows access to these, but that seems to be a specialized command that has its own rules.. And with these considered, access to LoopHorizontal / LoopVertical could also prove very useful. (I can think of at least one case, at least)~

~'212': InspectMapInfo~

~This command provides access to some information that is stored inside the map tree. It could still be expanded in functionality, but the most useful one (for my own purposes at least), I think would be the ability, to read Troop information from the current Map. While I was developing the "Community Edition" for Vampires Dawn this was a pretty annoying hindrance, because I wanted to implement an easy way to just switch between normal RNG battles & overworld encounters. I basically had to write a custom code generation tool to be able to do so...~

'213': MessageSystemInfo

Provides basic info about the system settings for message boxes.

'214': MessageWindowInfo

Provides some information about a currently active message window. Another issue I had, while developing a parallel event, that occassionaly displays some popup information. Normally, you haven't got an easy option of knowing if a message window is currently active & if so, where on the screen it is. You can't really react & redirect your custom drawn picture/strings/etc. to another part of the screen, so that it won't overlap with the system textbox.

[florianessl]

Nearly forgot.. Here's a small test project for these new operations: ControlVarsEx.zip

[jetrotal]

btw, you spoke about retrieve data based on string, maybe this could work as an replacement for https://github.com/EasyRPG/Player/pull/3214

[florianessl]

btw, you spoke about retrieve data based on string, maybe this could work as an replacement for #3214

Yeah, I'll give it some thought when I get back to further developing that feature. (And I'll also consider compatibility for/extending the new JSON command as well) Right now I have to examine my priorities again & focus on some other stuff.

The first (very rough) draft for that feature can be found in my personal repo here:

• liblcf: https://github.com/florianessl/liblcf/tree/features/LcfInspection
• Player: https://github.com/florianessl/Player/tree/features/LcfInspection

[florianessl]

I'll add this here as well, because it is especially relevant for this PR (mentioned in PR #3379 -> https://github.com/EasyRPG/Player/pull/3379#issuecomment-2865938998)

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

And also, regarding the LcfInspection branch:

The first (very rough) draft for that feature can be found in my personal repo here:

• liblcf: https://github.com/florianessl/liblcf/tree/features/LcfInspection
• Player: https://github.com/florianessl/Player/tree/features/LcfInspection

I haven't had time yet to go further into this feature because I'm somewhat burnt out at the moment... But I did some comparison of release builds & found that this first implementation bloats up code size by A LOT.

Last weeks 64-bit Windows build of the HEAD was at 12.805 KB for me. If I include the LcfInspection branches, this grows to 13.664 KB. Not worth it, for a single feature.

So, additionally, to implementing unit tests & including all sorts of sanity checks & validations in the code, I'd also need to restructure it in a way that trades of some performance in favor of less code size. But the way I implemented this feature, is mostly, by extending already existing template definitions in liblcf. I haven't done tests yet, to verify how much space the existing liblcf code takes when compiled, but I guess it's also not negligible for some platforms.. So maybe we could also go a bit further here & optimize the code size for the rest as well. (I'm thinking of some conditional compiler flag for the Wii & 3DS platforms)

[jetrotal]

@florianessl this suggestion could also fit this pr:

Someone on YNO discord asked about a way of detecting if a window is on focus or tabbed out.

They wanted to make some events synched by music and such.

I guess the best way to discover what can influence this variable setting, is the "Pause on Lost Focus" video setting, It's not present on the webplayer, idk why.