-
Notifications
You must be signed in to change notification settings - Fork 855
[LGN] Rework Whipgrass Entangler #10802
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Made a class for "Ability linked with an Effect", that also takes responsability of manually calling its effect's newId method.
|
Whipgrass Entangler - (Gatherer) (Scryfall) (EDHREC)
|
xenohedron
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is quite interesting. Is Whipgrass Entangler really the only card affected here? Or could this root cause manifest as other bugs? If it's a broader problem, then I'd be wary of a card-specific workaround.
Mage/src/main/java/mage/abilities/effects/common/continuous/GainAbilityTargetEffect.java
Outdated
Show resolved
Hide resolved
Mage/src/main/java/mage/abilities/effects/common/continuous/GainAbilityTargetEffect.java
Show resolved
Hide resolved
Mage/src/main/java/mage/abilities/effects/common/continuous/GainAbilityTargetEffect.java
Outdated
Show resolved
Hide resolved
Mage/src/main/java/mage/abilities/common/LinkedSimpleStaticAbility.java
Outdated
Show resolved
Hide resolved
I do not know for sure. |

So the starting point was #8363.
Investigating that, I found out that the
ReplacementEffectwas changingUUIDright after being paid.Once I figured out how to stabilize that (more on that later), I started different tests, and multiple of the same activation of the same Entangler could be paid with a single cost paid. That one was due to the applies of the
ReplacementEffectnot identifying the parent ability differently from the others ones from the same source.I did introduce a
LinkedSimpleStaticAbilityto solve both the issues:-> It does share an handshake
UUIDwith itsEffect, and theEffectcan use the handshake to identify its parent ability. That handshake changes on copy of theAbility, but both copy of parent and child do share the new handshake after copy.-> For the
ReplacementEffecthaving non-stableUUID, I did reinforce the ability field inGainAbilityTargetEffect, the main idea being that the ability should make a copy that has new ids for both the parentAbilityand the childEffect. And there should be noIdchange after that.So the
LinkedSimpleStaticAbilitytakes full responsibility of manually calling its Effect'snewIdmethod with a weird setup: the Effect'snewIdis overwritten to do nothing, and the parent Ability can callmanualNewIdinstead, which call the inheritednewIdof theEffect.That way,
GainAbilityTargetEffectmakesUUID-fresh-but-stableLinkedSimpleStaticAbility+ReplacementEffectin its constructors, which are later used in theGainAbilityTargetEffect::applyto add theReplacementEffecttoObjects(here the targetted Permanent).The changes made do not alter any other card (there is that one copy + newId for the ability in the main public constructor of
GainAbilityTargetEffect), so it is safe to merge, but any other use ofLinkedSimpleStaticAbilitywill probably need careful consideration on if and when theEffect's id must be reset to a fresh one.fix #8363