WotC_BenFinkel

Sure, I'll try to summarize. Most of what I say below could be changed to make Overload work; my point is that that work hasn't been done yet and is pretty nontrivial.

The Games Rules Parser (GRP) reads the exact text on the card. So, for [[Cyclonic Rift]], it sees two abilities, "Return target nonland permanent you don’t control to its owner’s hand." and "Overload 6U". It parses those abilities independently. That is, for [[Mind Rake]], its first ability is literally the same as [[Mind Rot]]'s. They literally use the same code, there's not a Mind Rake version and a Mind Rot version.

Not only that, but there isn't any text on the card that says "Return each nonland permanent you don't control to its owner's hand." So we'd need to recognize that that is a text that we need to create. And then that needs to be an ability that Cyclonic Rift has access to (i.e. is loaded into the game when Rift is), but that it doesn't actually have (until you cast it using Ove...

You could apply here if you'd like! We do have an open position on the Rule team.

As for bringing in old sets, it's really equivalent to bringing in a new set for a lot of them (roughly as many unimplemented sentences and keywords). And RTR is actually one of the worst: Overload is a pretty yucky mechanic for a system that expects cards to do what their text says. #wotc_staff

Firstly, that warning is automatically generated because it makes the target lose all abilities. Remember that code for MtG: Arena is generated via parsing the card text. Virtually nothing is hand-coded for exclusively for a single card.

Secondly, Arena usually starts implementing a set weeks after the set is "locked in" because the printing pipeline is longer than digital's. We give feedback about what's likely to be easy or hard to do during the design process, but it's set pretty much in stone before we start committing code. I look forward to the day when Play Design can iterate on a set in Arena, but that's still petty far out. #wotc_staff

You may pick which effect puts it into exile. Remember to disable "automatically pick replacements" in your game options. #wotc_staff

Not losing the counter is a known bug, a fix will come in this month's major update. #wotc_staff

Thanks for the illustrative report! Oddly we don't get a crash in the dev environment, but the GRE also wasn't successfully getting the token to be created (it thought it couldn't attach to anything, so it failed to finalize being created). I've fixed it for the next GRE patch, which is a couple weeks out I think. #wotc_staff

That is not in this patch. #wotc_staff

The big barrier against us doing this is that most games (even those with alt-win cons) end with concession. Even if we made a cool animation, nearly all games that WOULD use it would still see opponents conceding before it played... Still, it's definitely an idea we consider. #wotc_staff

Thanks for the report! I'll look into this tomorrow. #wotc_staff

What did you want to respond with? Was there any chance that some ability was stopping you from performing that action, like Teferi, Time Raveler? This will help me investigate. #wotc_staff

I'm confused about the issue you're seeing.

Are you not getting priority in response to the adventure, Stomp?

Is it that you are not getting priority after it resolves? If so, that IS the expected Arena behavior - when the stack is empty in a phase where Arena doesn't normally provide priority, it wants to pass. What action did you want to performs after Stomp resolved? Could you have performed it before it resolved? If not, could you put a stop on the phase or enter full control to perform your action after it resolved?

The problem that we solved for Legion Warboss is that there are a number of actions you can ONLY perform after Legion Warboss has resolved (e.g. Murder) that, if you don't get priority when the stack empties, it will be too late to perform the next time Arena gives you priority. I'm wracking my brain trying to think of actions that are similar for the Stomp case. #wotc_staff

I believe you have to turn autotap off in your options to enable manual mana spending. We've changed it a lot in the past though, so I don't remember if you also need to be in full control... #wotc_staff

Yup. #wotc_staff

I hesitate to be pedantic (even though it sort of is my job), but it's not exactly like Spectacle. Spectacle is a choice about which alternative cost to pay for an action, which takes place in the step of performing an action outlined by my "favorite" rule, 601.2b. The choice you make for Adamant in Arena takes place later, when determining the total cost, activating mana abilities, and applying your payment (601.2f through 2h, which is sort of one blob in the GRE).

So, there is a rules difference, yes. But there's also a UI difference - when you drag out a spectacle card, the screen dims and what we call a browser opens up of all the alternative costs you could pay (or the normal one). Whereas with Adamant, you'll see the normal battlefield and two buttons in the bottom right of the two autotap strategies. #wotc_staff

Priority time is when you're dragging the card from your hand, payment time is when we reach the step where the game rules demand payment for the action (after picking modes, targets, etc). #wotc_staff

I'd argue our solutions are pretty different. They have you make a choice at priority-time, which constrains which mana is qualified to pay for the cost. We have an autotap-only choice at payment time, which determines which of two autotap solutions to execute.

We have meetings with MtGO and paper R&D about upcoming sets to communicate which cards or mechanics that have digital playability or implementation problems. But in terms of "fingers to keyboard" solutions, our code bases are divergent enough that we don't have too much to discuss about EXACTLY how we're going to solve the problems a new set presents us. #wotc_staff

There's a lot of differences (timing, UI, rules interactions), but I suppose there are similarities too. They both happen between you dragging the card out from your hand and your opponent seeing the action you've performed. #wotc_staff

Thanks for the link. We'll investigate this! #wotc_staff

EDIT: Wait... this video is from July. Nowadays at least we don't autopay if the payment-time solution is different than the priority-time solution. But it appears this is a situation where that happens. We'll find out why.

Mana payment conditions like Adamant certainly were a new challenge for Autotap. I think we did a pretty good job with our solution to the interface though.

If the mana you have available makes it possible for you to choose between paying the adamant cost and not doing so, you will be offered that choice at payment time. There will be two buttons, one which pays the adamant mana, and one which avoids paying it. You can also at that time manually produce the mana you want. #wotc_staff

That's not how summoning sickness works - it's not a status that is added and removed from creatures. When determining if something can attack (or pay costs with the tap symbol), it can do so if you've controlled it since the beginning of your last upkeep or if it has haste (or some other ability that allows it to do so). Having haste doesn't have any lasting effects that persist when you remove it. #wotc_staff