kinda wish we could have gotten a "Developer's Note" to go along with the client update bug.
kinda wish we could have gotten a "Developer's Note" to go along with the client update bug.
Sure thing:
Background: Arena has a ton of different assets to handle all the cards, frames, indicators, VFX, etc. One of the things we need to do is ensure that none of these assets get corrupted, either during download or because of random weirdness with the hard drive. We used to check all the assets for consistency at every startup, but as the asset size continued to grow, this became too costly. Now Arena validates the assets on download, assumes they're good as they reside on-disk, but if it encounters any assets errors during gameplay it will flag itself to startup in "safe mode" next time. This means it will re-scan the assets to make sure none have been corrupted, then re-download any that are. This (as well as several other things) occurs while the client is saying "Checking for Updates".
The bug: In the original IKO release, there was an asset error that could be thrown in certain common circumstances (I think it was viewing a split-card). This didn't cause any visible problem, but it did flag to do "Safe Mode" on next client launch, which causes the long startup times. There wasn't any corruption or redownloads, but it still takes time to check everything (much more if you don't have an SSD).
Hopefully that helps. The length and "inside baseball" nature is what made me leave it out of the notes, but happy to share it here.
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.
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.
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.
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