Support for runtime patches: MonSca, EncounterRandomnessAlert, EXPlus, GuardRevamp

[florianessl]

Detection

No automatic patch detection yet! (Only .INI settings & cmd line args)

This would either require something like my proposed Draft PR #3352 (Extracting patch info from .EXE via known addresses & signatures) or some database of known patch configurations of games (As proposed in Issue #1210)

Test Game:

BattlePatches.zip

RPG_RT Patches included in this PR

MonSca:

This patch scales the default battle parameters of an enemy based on the contents of some in-game variables.
(Default: V[1001] - V[1010])

When a switch is set (default: S[1001]) to ON, an alternative scaling formula, based on the average party level, is used.

Default formula: val = val * V[...] / 1000
Alternative formula: val = val * avg_level * V[...] / 1000

Variant 'MonScaPlus':
If set, the variable IDs used for scaling will be offset by the enemy's troop index.
-> V[base_var_id + troop_index]

• https://dev.makerpendium.de/docs/patch_db/main-en.htm?page=mon_sca
• 'Plus' Variant: https://rmarchiv.de/games/24

Encounter Randomness Alert

This patch skips the normal battle startup logic whenever a random encounter would be triggered.
Instead a switch (default: S[1018]) is set to ON and the troop ID is stored into a variable (default: V[3355]).

• https://dev.makerpendium.de/docs/patch_db/main-en.htm?page=encounter_alert
• https://dev.makerpendium.de/docs/patch_db/main-en.htm?page=encounter_alert_mepr

EXPlus:

This patch allows to individually boost the 4 party members' gained experience inside battles by applying an extra percentage based on the values of in-game variables.
(default: V[3333] for party member #1; the amounts for other party members are read from the subsequent 3 variables)

If the '[+]' option is enabled, a side effect is added to one of the Actor clauses of 'CommandConditionalBranch':
Whenever this command is used to check for the existence of an actor in the current party, the current party slot (1-4) of this actor is set to an in-game variable. (default: V[3332])

• https://dev.makerpendium.de/docs/patch_db/main-en.htm?page=explus
• https://dev.makerpendium.de/docs/patch_db/main-en.htm?page=explus_plus

GuardRevamp:

This patch changes the way the damage adjustment is calculated whenever the target of an attack is defending.

Normally this calculation is done by simply dividing the damage in half for normal defense situations, and by quartering it when the target has the 'strong defense' attribute. With 'GuardRevamp' enabled, this is changed to a percentage calculation, allowing for more granular control over the output. The given default values of '50%', and '25%' would provide the same results in most situations.

• https://dev.makerpendium.de/docs/patch_db/main-en.htm?page=guard_revamp

Notes

Support for all of these patches can be disabled by setting the compiler flag NO_RUNTIME_PATCHES.

Some of the handling of command line args has been refactored, to allow setting patch parameters inidividually.
Example:
Player.exe --patch-monsca -atk 2003 -exp 2027 -plus --patch-guardrevamp -normal 75 -strong 30

• enables "MonScaPlus" for scaling attack & experience gains by reading from the scaling factors from Variables V[2003] & V[2027] (+ troop_id for this 'Plus' variant)
• enables "GuardRevamp" with a factor of 75% for normal defending & 30% for "strong" defend.

[florianessl]

Ok, this should be ready for review. I also cherry-picked my recent commits that move the handling for "Virtual Key" code mapping because several other PRs & WIP branches depend on these helper functions.

[Ghabry]

Looks solid on first glance.

Only have to do some in-game testing and the extended command line parser. Though in general code looks fine.

Using only one file for these small patches makes sense. Otherwise we have hundreds of small patch files.

Was there a motivation behind this NO_RUNTIME_PATCHES? These patches are not in any "hot" codepaths so this one "is patch on" check doesn't really hurt.

[florianessl]

Looks solid on first glance.

Only have to do some in-game testing and the extended command line parser. Though in general code looks fine.

Using only one file for these small patches makes sense. Otherwise we have hundreds of small patch files.

Was there a motivation behind this NO_RUNTIME_PATCHES? These patches are not in any "hot" codepaths so this one "is patch on" check doesn't really hurt.

Yeah, when you are looking at it closer, that flag doesn't make that much of a difference here. The idea is simply, to provide a way of compiling a "clean" Vanilla-compatible version of the Player without much added bloat of patch support code.

One patch that would be in a rather "hot" code path is the PowerMode branch, where patch functionality is triggered inside the routines responsible for changing variable values... (+ some yet-to-be-implemented PM-compatible Keyboard patch made by Cherry, that implements just the 4th Variable register of PowerMode)

[Ghabry]

We want to support all the old games so this is moving some obscure stuff forward. Will be useful in combination with some patch database later.

Great PR comment and test game btw.

I added a comment about RuntimePatches::MonSca::ModifyMaxSp and co going through some RuntimePatches::ModifyMaxSp function so other patches that do something similar can be delegated in it. But this can be reworked when necessary later.

[Ghabry]

that Lint build failure can be ignored. Is a new feature added by c1 for buildsystem rework and not your fault.

You are just triggering the failure because you added something to the CMakeLists but I won't enforce that you fix this xD

[carstene1ns]

Yeah, wanted to fix this later.