New Command: 2053 - Set Interpreter Flag

[jetrotal]

RPG_RT.ini Flags - VarMin and VarMax

A flag that controls minimum and maximum variable range.

Usage inside RPG_RT.ini:

VarMin=-100
VarMax=100

---

New Command: 2053 - SetFlag

Change Patch Flags during gameplay.

Usage, as a @raw command:

@raw 2053, "Flag Name", onOff_Value_IsVariable, onOff_Value

@raw 2053, "rpg2k3commands", 0, 1 //2k3 commands on 2k games

@raw 2053, "dynrpg", 0, 1 // dynrpg patch

@raw 2053, "maniacs", 0, 1 // maniacs patch
@raw 2053, "maniac", 0, 1 //  maniacs patch alternative

@raw 2053, "keyPatch", 0, 1 // ineluki's key patch

@raw 2053, "unlockPics", 0, 1 // call pics while dialog box is open

@raw 2053, "commonThisEvent", 0, 1 //common events can use "this event"

@raw 2053, "2kbattle", 0, 1 //Battle system from rm2k

[Mimigris]

Didn't tested the command, but just tested a bit the flags for the RPG_RT.ini. For documentation info, it seems that the values set in the RPG_RT.ini have priority compared to the values set in the RPG_RT.ldb (currently only accessible by manual editing with lcf2xml). An issue related to the pull request that I've noticed is that exiting a game and selecting another will keep the values set as the maximum and minimum in the RPG_RT.ini even if it should not be the case (e.g. setting the minimum and maximum to -99 and 99 in a A game and then choosing to play a 2k game will keep the maximum as -9 and 9 instead of -999999 and 999999 - this issue does not seem to happen if it is set from the RPG_RT.ldb). (On the chat you also mentioned that the debug menus that use digits to input values do not work correctly if the value is set at a low value, though this is not related to this pull request)

For the command itself though, not a code problem but rather a design problem as mentioned yesterday, but I'm still not sure if there is really a point in having it. For most of the possibilities offered by these patches, there is no point in keeping the patches disabled since disabling them only remove possibilities, enabling them do not remove anything (Maniac change the range of values accepted for the variables though it can be ignored if it bothers you, see my comment below). Disabling/Enabling patches on the fly, as opposed to setting them on startup and only on startup and not changing them, would only allow you to have a period of time where some parts of some commands would be ignored (if extension of an existing command), be completely ignored (if use a of a custom command), or change the range of a value accepted in the case of Maniac from what I understood (this only affects Maniac, and so specific values; would be better to have a command specifically to change the limits, if there is an interest in having that, instead of editing it this way). That's just what I think: my opinion is neither wrong or good, don't think it as a truth, though I wonder what are your opinions on it (you, as well as other contributors or anyone interested in it).

If I remember correctly also, enabling/disabling Maniac on the fly will change the range of values that is accepted. I'm not sure if it's a really good idea to have it like that, though manually setting the range should work as a way to avoid it if you consider this as an issue.

[jetrotal]

An issue related to the pull request that I've noticed is that exiting a game and selecting another will keep the values set as the maximum and minimum in the RPG_RT.ini even if it should not be the case (e.g. setting the minimum and maximum to -99 and 99 in a A game and then choosing to play a 2k game will keep the maximum as -9 and 9 instead of -999999 and 999999 - this issue does not seem to happen if it is set from the RPG_RT.ldb).

Fixed on last Commit.

(On the chat you also mentioned that the debug menus that use digits to input values do not work correctly if the value is set at a low value, though this is not related to this pull request)

This needs its own issue, since it's related to the Debug Screen and can also be affected by the current .ldb changes.

For most of the possibilities offered by these patches, there is no point in keeping the patches disabled since disabling them only remove possibilities, enabling them do not remove anything (Maniac change the range of values accepted for the variables though it can be ignored if it bothers you, see my comment below). Disabling/Enabling patches on the fly, as opposed to setting them on startup and only on startup and not changing them, would only allow you to have a period of time where some parts of some commands would be ignored (if extension of an existing command), be completely ignored (if use a of a custom command), or change the range of a value accepted in the case of Maniac from what I understood (this only affects Maniac, and so specific values; would be better to have a command specifically to change the limits, if there is an interest in having that, instead of editing it this way). That's just what I think: my opinion is neither wrong or good, don't think it as a truth, though I wonder what are your opinions on it (you, as well as other contributors or anyone interested in it).

I kinda aggree with that. For what we know, enabling patches don't break anything on games (the exception being variables range from maniacs, that only sounds like a problem for going from maniacs to vanilla, not the other way around).

But, I'm having the caution to suggest that a smart dev could chose to use a patch just for a fraction of their code. You guys have no idea how that would help collective projects, like chain games. That would transform vertical decisions done only by the maintaners of some projects into horizontal ones. Allowing more impressive resources used on such collective games.

[jetrotal]

But a Big fat warning by me to be compatible later: Because this is for cooperative games. I will change this later so that the patches are only active for the interpreter that toggled the flags on and the flags are lost when the current frame ends. This avoids conflicts and is less error prone.

Do you think this "onEventEnd" listenner you plan to do could be generic enough to be linked to other commands/other features?

maybe there are usecases for it...

[Ghabry]

The values are automatically reset when the frame is popped from the stack. But an event handler here: Sure, why not. We already talk about callback hooks at certain locations to make the multiplayer integration easier. So a few more do not hurt ^^.

Maybe they can be even exposed via the WASM Api. Then you can hook them in the web player through JS. 🤔