Most when-this-card-enters-the-battlefield triggers aren't actually coded as triggers; they happen as part of resolution. (This is why you don't get the usual order-your-triggers interface, and can't, for example, choose whether to resolve them before or after ones coded as actual triggers like
Soul Warden.)
I've looked into the specific case with
Graveborn Muse in some detail. My findings ain't good.
(For clarity's sake, when I talk about "the stack" here, I mean it in
the technical sense. I talk about the M:tG game-level stack a bit at the end, too; I'll disambiguate that one by capitalizing, as in "the Stack".)
With normal events, the engine can deal very well if a card's event handler tries to dispatch another event; it stores the various globals it uses for bookkeeping (affected_card, attacking_card, event_result, etc.) onto a dedicated stack, dispatches and resolves the new event, and pops the old values back off.
With triggers, this approach doesn't work so well. Besides the overall globals (a superset of the event ones), which are stored on the normal stack (which works better than the dedicated one these days, though the reverse was true when Micropose MTG was first released), the engine also has to keep track of whether each individual card has already responded to the trigger. It does this by setting STATE_PROCESSING on each triggered card as it's clicked on to activate (or activated automatically, if it's a mandatory trigger and only one card is responding). These can't be stored, reset, and then restored nearly so easily as the handful of controlling globals, and the exe doesn't even try. What it
does do is omit clearing STATE_PROCESSING at the end of dispatch_trigger() if the trigger was dispatched while another trigger was already running, which is still better than nothing.
It might be sufficient to store everything's STATE_PROCESSING flag at the start of dispatch_trigger() and restore them all at the end, but I'm not certain what all the implications are. I'm afraid to touch it until I fully understand the function and all the ones it calls; and the one doing the actual work - sub_475A30() - handles not only the trigger interface, but normal prompting for and selection of fast effects, casting, etc. as well. It is gigantic and convoluted.
The easy way out, making the number of cards to be drawn by draw_cards() visible, definitely won't be enough (with three
Graveborn Muse in play,
Lorescale Coatl would get 3 counters instead of the 1 it gets now or the 9 it should get), and it won't interact properly with cards that respond to TRIGGER_REPLACE_CARD_DRAW.
Modern trigger rules are actually a lot easier to implement than the fourth-edition ones Manalink uses. I may just do that instead, though again, I'll need to grok sub_475A30() and all its subfunctions first. This'll have the added benefit of letting us respond when triggered effects are on the Stack, so we can code the rest of
Stifle,
Trickbind, and
Voidslime (just those three, right?). I do worry a little about running out of room on the Stack, though; the engine can only handle 32 effects on it at once, which won't be hard to get to -
Braingeyser for eight cards with four copies of
Lorescale Coatl in play and boom. Not to mention that each effect takes up one of the 150-cards-per-player-per-turn limit that we already run out of pretty frequently ("AddCard error: No more room in cd to add a card"). Making the Stack bigger will be quite difficult; making the 150-card limit bigger extremely so.
Posted: 23 Sep 2013, 09:53