Drooped2 wrote: » This complaint doesnt check out with math. Right now you have a .89 chance per champ ish Splitting it although removes some chamois from it ups your chances of pulling each. Ie 24 per crystal is 4 percent
Drooped2 wrote: » V1PER1987 wrote: » Drooped2 wrote: » This complaint doesnt check out with math. Right now you have a .89 chance per champ ish Splitting it although removes some chamois from it ups your chances of pulling each. Ie 24 per crystal is 4 percent Why doesn’t that check out with math? He wants to stop pulling the same champs by increasing the odds of doing so.. .89 isnt high (neither is 4) but last I checked 4 was higher then .89
V1PER1987 wrote: » Drooped2 wrote: » This complaint doesnt check out with math. Right now you have a .89 chance per champ ish Splitting it although removes some chamois from it ups your chances of pulling each. Ie 24 per crystal is 4 percent Why doesn’t that check out with math?
Spurgeo14 wrote: » As more and more champions keep getting added to the crystals, is there any hope of the regular crystals being split up or something? I'm tired of getting the same 4*s over and over...does this bother anyone else?
Zuko_ILC wrote: » Spurgeo14 wrote: » As more and more champions keep getting added to the crystals, is there any hope of the regular crystals being split up or something? I'm tired of getting the same 4*s over and over...does this bother anyone else? Would be nice if they split the crystals by years 2015, 2016, 2017, 2018 or at least combined 2 years
mostlyharmlessn wrote: » Spurgeo14 wrote: » As more and more champions keep getting added to the crystals, is there any hope of the regular crystals being split up or something? I'm tired of getting the same 4*s over and over...does this bother anyone else? It is very annoying, but it's the result of pRNG algorythm which Kabam uses. Low quality pRNG algorithms produce the kind of "Batchy" results we tend to see. Linear congruential generator (LCG), the one that Java uses by default, which while fast, has been known for decades to be pretty poor quality and produce the kind of results we see. (I do not know if this is the actual algorithm used, but it sure does feel like it.
Scottryan wrote: » "The pool is getting so big that i keep pulling the same champ over and over"...what?
Worknprogress wrote: » Why would they split stuff into classes? It wouldn't make any sense to even give random AG and rank up gems as rewards at that point. Then anyone could just target a specific class for whatever rewards they got.
MaatMan wrote: » Worknprogress wrote: » Why would they split stuff into classes? It wouldn't make any sense to even give random AG and rank up gems as rewards at that point. Then anyone could just target a specific class for whatever rewards they got. well they really should be split in some way or another. i was merely offering a suggestion. and a good one for us TBH. u got a better one?
DNA3000 wrote: » mostlyharmlessn wrote: » Spurgeo14 wrote: » As more and more champions keep getting added to the crystals, is there any hope of the regular crystals being split up or something? I'm tired of getting the same 4*s over and over...does this bother anyone else? It is very annoying, but it's the result of pRNG algorythm which Kabam uses. Low quality pRNG algorithms produce the kind of "Batchy" results we tend to see. Linear congruential generator (LCG), the one that Java uses by default, which while fast, has been known for decades to be pretty poor quality and produce the kind of results we see. (I do not know if this is the actual algorithm used, but it sure does feel like it. No pRNG in general use by any modern language has sufficiently bad sequential correlation that a human being could detect it with their eyeballs. I'm not familiar with Java's specific choice of parameters, but as there are very good ones with minimal correlation it would seem illogical they would go out of their way to pick a bad set. But again, even *horrible* pRNGs are unlikely to generate sequences humans can see. Especially in a multiplayer game where literally millions of people are doing things that require random numbers generated. Based on the literature I"ve read, Java's current choice for parameters suffers from tupling bins, aka the problem of "sets falling in planes" but it is otherwise reasonably random. This means it does not suffer from the correlation problem you describe: it is not "batchy." Instead, it doesn't distribute short sequences of random numbers randomly. To put it another way, to catch this implementation in the act of doing something non-random, you would have to be able to tell that the sequence Cyclops/X-23/MODOK occurs less often than MODOK/Wolverine/MsMarvel. No one does that analysis. This is separate from the fact that the Java implementation is not generally used in server-side applications. The generators you'd use from something like the Microsoft or GNU libraries are much stronger.