Stalwart Successor trigger bug
Stalwart Successor is bugged. It doesn't trigger when a non-token creature enters with counters
Originally posted by @padfoothelix in https://github.com/magefree/mage/pull/13473#discussion_r2063935290
[[Stalwart Successor]]
Stalwart Successor - (Gatherer) (Scryfall) (EDHREC)
{1}{B}{G} Creature — Human Warrior 3/2 Menace (This creature can't be blocked except by two or more creatures.) Whenever one or more counters are put on a creature you control, if it's the first time counters have been put on that creature this turn, put a +1/+1 counter on that creature.
After a bit of manual testing, I believe this is due to the fact that when a nontoken creature enters with counters, that permanent is null when the COUNTERS_ADDED event occurs. The checkTrigger method therefore returns false and the effect doesn't apply.
you must use game.getPermanentEntering(event.getTargetId()) to find entering permanent
There are many used of == GameEvent.EventType.COUNTERS_ADDED -- so it can be affected by entering token bug too.
Please report the buggy token/ability that cause buggy enter with counter (miss event). Default createToken code is fine and it add counters to existing permanent only, not entering:
not actual below
well, I see potential problem due CreateTokenEffect rework in #12704 by @Grath -- now it contains multiple tokens list, but some code still use single token like apply method from above.
Not sure is it related or not, but must be research anyway.
Potentially buggy tokens that use withAdditionalTokens (if it enters with counters than can miss counter and add counter event too):
Except the bug here is in NONtoken permanents entering the battlefield?
Also withAdditionalTokens adds the tokens to lastAddedTokenIds so you're wrong that the apply code you found is bugged with my rework - it uses the same mechanisms for creating varied tokens as Chatterfang et al, which effects needed to be updated to support; it was just that there was no way for a CreateTokenEffect to specify that it was one instance of creating multiple different tokens.
Ok, I see the reason -- it's by design. All permanents that come with used game.setEnterWithCounters will add counters on entering permanents, not real:
So there are potentially ~30 places that must be checked, search by == GameEvent.EventType.COUNTERS_ADDED -- that code must use both getPermanent and getPermanentEntering search.
Good usage example:
Yes, that makes sense. The event is fired correctly, it's the abilities that check it need to account for entering permanents.