You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Started in #11961 and continuing work done in #11841, addressing part of issue mentioned in #10805.
My plan is to take any abilities that trigger "when <permanent/player> is dealt damage", such as enrage abilities, and fix anything with the following criterion:
checkEventType is looking for DAMAGED_PERMANENT or DAMAGED_PLAYER
The ability should trigger only once for simultaneous damage from multiple sources
Ironically, most "Enrage" cards are fine (such as Apex Altisaur), since they use DealtDamageToSourceTriggeredAbility, though that could stand to switch to using the new DAMAGED_BATCH_FOR_ONE_PERMANENT event (this is not necessary though it seems since the filtering used in checkTrigger looks like it takes care of it)
Also, cards like Acidic Dagger, which use DAMAGED_PERMANENT but should trigger on each specific instance of damage meeting its criterion, need not be changed.
However, cards like Aegar, the Freezing Flame (can you tell I'm sorting alphabetically) need to be addressed. All of these cards would get a change similar to what i did in #11961, except the DAMAGED_BATCH_FOR_ONE_PERMANENT and DAMAGED_BATCH_FOR_ONE_PLAYER events would get a new getTargetId override in order to make the code cleaner and since everyone would normally need to say:
Currently in master, 93 cards, 1 token, 4 watchers, and 17 abilities use the DAMAGED_PERMANENT event.
206 cards, 2 tokens, 8 watchers, 1 Plane, and 11 abilities use the DAMAGED_PLAYER event.
Each of these cards will need to be reviewed to see if its using those properly or if they should switch to the single-target (or potentially multi-target) batches.
Additionally, changes made as a result of #11985 would need to hit anything hit by this change if its done after i do this change, so right now I'm going to wait until that issue is resolved before starting this.
Is it possible to have combat and noncombat damage dealt in the same instant? (i'm assuming yes since there are no assumptions made about damage that is lumped into the batch for one permanent)
If that does occur, how should it be determined which part(s) of the damage were in excess of the permanent's toughness/loyalty/defense?
Started in #11961 and continuing work done in #11841, addressing part of issue mentioned in #10805.
My plan is to take any abilities that trigger "when <permanent/player> is dealt damage", such as enrage abilities, and fix anything with the following criterion:
checkEventType
is looking forDAMAGED_PERMANENT
orDAMAGED_PLAYER
Ironically, most "Enrage" cards are fine (such as Apex Altisaur), since they use
DealtDamageToSourceTriggeredAbility
, though that could stand to switch to using the newDAMAGED_BATCH_FOR_ONE_PERMANENT
event (this is not necessary though it seems since the filtering used incheckTrigger
looks like it takes care of it)Also, cards like Acidic Dagger, which use
DAMAGED_PERMANENT
but should trigger on each specific instance of damage meeting its criterion, need not be changed.However, cards like Aegar, the Freezing Flame (can you tell I'm sorting alphabetically) need to be addressed. All of these cards would get a change similar to what i did in #11961, except the
DAMAGED_BATCH_FOR_ONE_PERMANENT
andDAMAGED_BATCH_FOR_ONE_PLAYER
events would get a newgetTargetId
override in order to make the code cleaner and since everyone would normally need to say:Currently in
master
, 93 cards, 1 token, 4 watchers, and 17 abilities use theDAMAGED_PERMANENT
event.206 cards, 2 tokens, 8 watchers, 1 Plane, and 11 abilities use the
DAMAGED_PLAYER
event.Each of these cards will need to be reviewed to see if its using those properly or if they should switch to the single-target (or potentially multi-target) batches.
Additionally, changes made as a result of #11985 would need to hit anything hit by this change if its done after i do this change, so right now I'm going to wait until that issue is resolved before starting this.
Comments welcome @JayDi85 @xenohedron
The text was updated successfully, but these errors were encountered: