Open JayDi85 opened 2 months ago
Thanks for the summary.
What is the rationale for not adding processAction to game engine? Remember that mtg rules evolve over time as new abilities and effects are printed, and what worked in the past may not be sufficient still. I would like to hear what are the bugged side effects of calling processAction.
Syntax updated in #12458:
applyEffects
processAction
standard game methodProcessAction can processing game events too early (e.g. after move one card instead multiple). It can break not finished batches events (process it too early). It (and ApplyEffects) can break dynamic abilities/triggers/effects (ends it too early, e.g. dies triggers). Etc.
The most "killing" places -- continous, state base and other effects that can be called multiple (and sometime random - hello aura) times inside resolve or game cycle.
Another pain place -- mana abilities and mana payment cause it use same ability usage's lifecycle.
It's impossible to fix/replace one thing by another cause some effects need actual game state (want to call ApplyEffects early), but another effects need old game state (call ApplyEffects later). Related to last known information (LKI) limits too.
What is the rationale for not adding processAction to game engine?
It can be added to place like end of turn and other stable places (that calls one time and do not depends in random effects/abilities/cards on battlefield). But it already there.
Current restrictions due many side effects and broken game lifecycles
ApplyEffects
-- RESTRICTED in any places;ProcessAction
-- ALLOWED in one shot effects only (between action steps), all other effects and game engine places are RESTRICTED;ApplyEffects
toProcessAction
-- ALLOWED and welcomed;ProcessAction
toApplyEffects
-- RESTRICTED;ApplyEffects
-- ALLOWED and welcomed;ProcessAction
-- ALLOWED and welcomed;