Original Post — Direct link
over 4 years ago - /u/WotC_BenFinkel - Direct link

We have a fix for this coming this week. #wotc_staff

over 4 years ago - /u/WotC_BenFinkel - Direct link

Originally posted by into_lexicons

thank y'all for your hard work on stuff like this. these are thankless tasks but i wanted you to know it's appreciated.

Thank you! Fixing these things is fun (of course, not as fun as getting them right in the first place!). #wotc_staff

over 4 years ago - /u/WotC_BenFinkel - Direct link

Originally posted by Dall0o

As a dev myself, I have a love/hate relationship with this kind of bug. Stressful but fun too. Thanks for people for breaking software and posting issue after.

Nailed it. Release bugs are the worst from the stress perspective - we have such limited time to fix in time for adequate testing before the "fast follow" release! The puzzle-solving aspect is one of my favorite components of this job. #wotc_staff

over 4 years ago - /u/WotC_BenFinkel - Direct link

Originally posted by darkslide3000

I'm somewhat surprised they wrote it, actually, considering that Magic has a very well-defined set of rules. I bet what happened here is that their Card object has a GetCmc() method, and they just implemented that to always count X as zero... which I guess could easily happen to most of us if we tried to write this code from memory. But if you look at the comprehensive rules, there is a whole block of rules about how to calculate CMC for every eventuality, and it very clearly says

202.3e When calculating the converted mana cost of an object with an {X} in its mana cost, X is treated as 0 while the object is not on the stack, and X is treated as the number chosen for it while the object is on the stack.

You would think for a product this big that has to really get every edge case right they would basically just translate the comprehensive rules into code 1-to-1 for every game mechanic thing they implement (and ideally have an L4 judge with programming experience review it), so I'm surprised that this sort of thing still happened. (If the mistake happened when determining whether the card was "on the stack", there are very clear rules about when to check conditions in the process of casting a spell, too.)

Consider that Lurrus is the first card on MTG:Arena that both allows you cast a spell constrained by its CMC and doesn't provide an alternative cost for doing so (unlike cards like [[Electodominance]]). So right off the bat we're talking about something new, but that looked really familiar - I'm not surprised that our testing strategy missed this case.

In order to even begin proposing casting the spell, some rule or ability needs to grant you permission to do so. Lurrus' code sees a card in your graveyard with CMC <= 2, and so it proposes it, thus you can start casting it. We need an entirely different step in the process, and thus entirely different code, to then step in at the choose-X step to enforce that the resulting CMC is STILL <=2. That doesn't come "free" from just "implement the comprehensive rules 1:1" - Lurrus' "you have permission to cast a CMC <= 2 spell" code needs to check in again there. Fortunately, the fix makes it so all CMC-capped casting permissions will now work fine.

Also, how would you like MTG:Arena to implement rule 100.6b? :P #wotc_staff

over 4 years ago - /u/WotC_BenFinkel - Direct link

Originally posted by freestorageaccount

Re: there being two checks for legality, kind of like with targetting, would a counterpart companion called Big Lurrus that instead read "converted mana cost 3 or higher" not let me cast a 3-point [[stonecoil serpent]]? Because the spell would satisfy that but as a card it would not, so that stage is never reached?

That would probably need some new semantics in the prompting-time version of the noun to mean "or has X in its cost", as that could POTENTIALLY become a 3+ cmc spell. And we'd need to ensure the X-bound logic enforced a MINIMUM X choice. Let alone the autotap concerns... #wotc_staff