Natual Menace is always first, issue is/was with second and later not properly adding it's effect. So since non-conditional non-counter instance of Menace (or any other ability) cannot be removed from creature without also removing all other instances, it's not possible to reproduce this bug on creature with natural full-time Menace.
Precisely! #wotc_staff
Thanks, I have a fix for this. As /u/50_Shades_of_Graves alludes to here, the word "creature" is the culprit - once the Scorpion dies it's not a "creature" any more but a "creature card". Still, the damage from it is dealt by a creature - the last-known-information of the Scorpion. I adjusted our code for "prevent" to allow for checking last-known-information objects. #wotc_staff
WotC coding
creature.menaceCounter--; if (creature.menaceCounter == 0) creature.menace = false;
Check out my postmortem of the bug here to see what actually happened! #wotc_staff
This bug is easily reproducible:
- Play a nonhuman creature and give it a menace counter (in this case [[Fertilid]] and [[Blood Curdle]])
- Mutate [[Cavern Whisperer]] onto it, so it gains the menace ability a second time.
- Cast [[Heartless Act]] and remove the menace counter. The creature will now be able to blocked by a single creature.
Note that I've only tested this when the opponent casts Heartless Act during the attackers step, just in case that's the only time this happens. It's also somewhat likely that this logic applies to other keywords as well. I did check with the MTG Judge Chat and they agreed this is a bug, not a rule I'm misunderstanding.
edit: This bug was formally reported here if you want to vote it up to hopefully get this fixed soon.
To clarify, you have to Mutate a menace creature on top? Having menace naturally doesn't seem to result in this bug, I'll try again with mutating. #wotc_staff
EDIT: Yes, mutating seems to do the trick. Let's figure out what's going wrong.
EDIT 2: Alright, got it! Here's what's going on. Whenever we detect that you've gained a new ability, we usually kick off that new ability's continuous effects. However, multiple different places in the code can attempt to start those continuous effects (creating attachment relationships and redestining zone transfers are some somewhat esoteric examples), and we don't want to double-dip starting those continuous effects, so we see if there are any already from this ability.
Menace makes a BlockedByMinCountQualification, which is a continuous effect. When you add menace (say, Menace2, the one from Cavern Whisperer) to something that already has it (say, Menace1, from the Menace counter) we were erroneously thinking we'd be d...
Read moreThe rule for predicting cost adjustments accidentally removed all checks for zone constraints (instead of just the ones about "this spell" - it's not a spell until it's on the stack!). So basically Mystical Dispute is predicting it cost 2 less if there was a blue card anywhere in the game. Oops! I have a fix, but it probably won't be live for a while, especially as it doesn't affect gameplay much (just gives you stops if you can afford U and your opponent controls a spell...) #wotc_staff
I'll be investigating this tomorrow. #wotc_staff
For "A mutated Cavalier of Thorns should no longer be able to target "itself" if you chose to exile it when it dies."
Wait, I thought that each card has that ability. E.G. A Cavalier of thorns mutated with a greathorn. Shouldn't both the Greathorn and the Cavalier choose to exile cards? Can the Greathorn choose the Thorns?
Or am I thinking wrong as in the bug the Greathorn can choose the Greathorn.
According to my chat with MTG rules manager Eli Shiffrin, "another" on Cavalier of Thorns means "other than any card that constituted this permanent". I suppose a Melded creature that became a copy of Cavalier of Thorns would have had the same issue - y'know, if Eldritch Moon were in Arena. #wotc_staff
Awesome find. Awesome bug. No plan to fix; it’s just more fun this way.
We have a fix for this issue coming in the next update. Here's what you can do in the meantime.
Hopefully, that helps!
Thanks for letting me know, everyone! Restart the client and you should be able to get back in. :slight_smile:
(Note: It may take a few minutes but should be fixed. Grab a snack or something, then come back and try again.)
Same here, system is down for maintenance.
What region are you in? Any details that you can give me would be great, so we can look into this a bit farther!
This forum makes it seem like the patch is done, and the game should be up and running. So, how long before we can actually play again? I'm getting tired of loading it up and getting the SYSTEM IS DOWN message.
The game should definitely be operational. Could you walk me through what is exactly happening to you?
As I said, I do think being too strict on it would cause too much queue time. Honestly, I cannot possibly estimate what would lead to acceptable queue times, because I have no data on how many people are looking for a draft at a given time.
Much like normal matchmaking, the pool of players considered would grow larger as the queue time increases, but it should probably start larger than exacts ranks. For instance, it could put bronze + silver together, gold + platinum and diamond + mythic. Or, since I believe the gold population is significantly larger than the rest (I could be wrong), it could be bronze + silver, gold, platinum + diamond + mythic. Or it could be any other split that makes sense to someone who actually has the data.
Again, I cannot possibly know whether or not it's feasible from a queue time perspective, but I thought it would be an interesting discussion w.r.t. whether or not they should consider it in the first place.
"I cannot possibly estimate what would lead to acceptable queue times, because I have no data on how many people are looking for a draft at a given time."
Until a few days ago, we didn't have any of that data for player drafts either :)
This is an interesting question, with both queue time & gameplay implications. Queue time questions we can sort out as we get more data, but the gameplay questions are stickier. In short: one of the key virtues of Draft is the variability from pod to pod. The more similarly each pod you're in drafts, the more repetitive the format will feel.
This is something we talk and think about regularly. For now we feel like non-matchmade is the overall better experience, but we'll continue to monitor and discuss here.
Just posted this in another thread, but we’re aware and looking at this. For player draft, we didn’t need these logs for our debugging purposes, but we understand that they’re also used for trackers, and we like the value those bring their users.
Do you happen to have any insight on why human drafts don't produce log output containing the available card ids, the way that bot drafts do?
We’re looking to get that fixed; no definite timeline to give at this time. We put logs in for our debugging purposes, and in this case we’re getting our info in a different way. But we get that these are useful for trackers, etc. and we want to support that too.
The '"Checking for Updates" should take significantly less time.' part did absolutely nothing though. At least on my end.
Oh, good point! See my other comment in this thread for more info about why, but the first launch with this update could still be long. Shouldn't be any long updates after that.
devtrackers.gg
