Player
Player copied to clipboard
EasyRPG
Support for runtime patches: MonSca, EncounterRandomnessAlert, EXPlus, GuardRevamp
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:
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.
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.
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.
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)
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
@florianessl imo this is ready for merge. Can you just rebase it once on the master branch to ensure that nothing broke (compile wise) in the meanwhile?