Ah ok, just Maws traits im missing out on as I have Sheggras first and all 3 of Mercys.
Little bug just happened using this team where gorgotha was the last AI troop. Killed him with skull damage and he summoned a daemon but the match ended anyway
Yeah, thereâs tons of bugs with maw. See this video of a match I had: https://account.xbox.com/en-us/gameclip/c2c2c232-f24f-4a62-8d40-c482e634dca4?gamerTag=VegaDark541&scid=ed190100-58a8-4dd8-8019-8e8323a144b4
Yeah i dont know why but sometime maw eat 2 at the same time
There was no devour involved; just skull damage
All kinds of mawlarchy in that vid!
1 Like
Nope. Another Dimetraxia⌠at 100% frequency
Enemies with Daemonic Pact have been summoning at 100% since the last update.
Iâve seen it 47 times in a row now.
Pc had that team going with pre-Nerf sheggas for ages 2. Ah good times, lol.
@Theicla how many at a time do you open? Was that VIP?
Well Iâve been saying all along⌠Pulls at 50, 10, and 1 at a time donât seem to make a difference. I spent 1500 gems on event chests for Maw without even getting many kingdom troops before resorting to pulling VIPs at first 10 at once, then 1 at a time.
Now have 13 Twisted Heros
8 Dimetraxia
2 Herald of Chaos
3 Venbarak
Scores of URâs
If youâre asking whether Iâm attempting 50 at a time, well I canât. I keep gems for new kingdom Events and when it takes 2500+ just for ONE copy of a legendary previously, somethingâs not working right.
To answer your question, I have not, at any point since Iâve started, been able to stockpile anywhere near the 5,500 to 6,750 gems that youâre asking me to use on this chest.
Since the events (chest opening) are independent (result of one doesnât depend on the result of another), opening 50 chests at once wonât be any different than opening one at a time in terms of yield. In terms of cost efficiency, 50 chests at once is more efficient for all gem-currency chests, as the game gives you a discount.
The developers said this? Because I have data that shows groups of Keys are one event, not 10 or 50 individual events
No, they havenât stated it either way, though any simple algorithm would be as independent as the pRNG behind it.
Note that when I say âindependent eventâ I am not referring to the server API (which is definitely batched for a 50-key open) but rather the per-key roll done server-side. We only have observational, black-box information about how the event outcome is determined.
Your explanation leaves me intrigued. Assuming you are describing the actual process, does the server API always have a 50-key batch queued and ready to use or does it make a request each time you make an open command?
ââŚblack-box information about how the event outcome is determinedâ
I finally got something different this time from a single VIP pullâŚ
x1 Arcane Stoic
x1 Arcane Spirit
@Lyya You say that Arcanes are dropped at 2% which is the same as the quoted stats for Legendaries. So whenever Iâm getting hard-to-get traitstones instead of troops, does the server consider itâs just gifted me the equivalent of a legendary and figure âHey, jobâs done,â so to speak? Does getting an Arcane keep resetting the payout=due counter? Would that explain why I only get actual Legendary cards at a frequency of about 1 a month?
Iâm not exactly swimming in rare traitstones either though⌠
Thereâs no way to know the answer to that, since the observable result would be the same in either case.
Consider as a thought exercise an electronic game of, say, craps. The game itself is very simple; once per round, the dice are rolled, and the outcome of any betting that was made is determined by the dice rolls. There are two ways this could be implemented.
In option A, the game would roll the dice exactly as needed by the game engine. What that means is, at the point of the dice roll, each die is assigned a random number from 1-6 exactly then (via the pRNGâs rand() function); no advance list is involved. Outcomes are decided based on those rolls. On the next throw of the dice, new numbers are assigned.
In option B, the game, at startup time, or every so often, generates a list of die rolls in sequential order by calling rand() over and over again and storing the results in a buffer. For example, the list might be initialized in one instance as â3,4,2,2,5,2,6,6,3âŚâ Thereafter, whenever a throw of the dice is made, the next two numbers are taken off the list (which would make the first pair of dice 3 and 4, in this example).
Which of these methods is employed by the engine is immaterial. To the end user, the result is the same, regardless of whether or not the rolls were deferred or immediate. The odds of winning do not change in any event.
For that matter, when discussing pRNG (pseudorandom numbers), really each number in sequence is a complex but deterministic value based on the seed of the pRNG from the previous call. In essence, every number âpulledâ off the list from a rand() call is actually just the next in sequence, and therefore buffering RNG values serves no purpose whatsoever.
That being said, by far the simplest implementation of random server calls is to have the server access (and possibly seed) the random number generator per API call. Overseeding the RNG can actually result in less stochastic results from the pRNG, so itâs often best to just trust the sequence of repeated rand() calls is sufficiently random after having established a sufficiently entropic seed value.
2 Likes
Assuming that a good payout somehow resets a counter, or that a bad streak means you are âdueâ for some good luck, is an example of the gamblerâs fallacy. In reality, the probability of a given outcome is static per event, which means that after a thousand Legendary âmisses,â your chances to get one are still exactly what they were before you started âmissing.â Likewise, if you âdingâ and get a Legendary, the next pull still has exactly the same possibilty of getting another Legendary that the previous one did. Streakiness and what âshould happen nextâ are a fabrication of the human mind.
2 Likes
Iâve said this before, that basically with a large enough sample size, you get the stated drop rates.
You just canât insert drop rates and tell a computer to be 100% random. Thereâs always a hidden sequence.
But VLTs are programed to have a ratio of earnings and payouts.
The REAL fallacy is that gamberâs think itâs them on a hot/cold streak. Itâs the machines.
Yes, this is true, but itâs not a problem specific to computers. Any observable event requires a sufficient sample size to predict with any accuracy. Itâs very, very common to come to conclusions based on single-observer bias or other small-sampling biases. Hereâs a down-to-earth explanation of inaccuracy due to small sample sizes: How Sample Size Affects the Margin of Error - dummies
2 Likes