Originally Posted by lolix

I agree. Doors have some rotations. For example i noticed 3 common patterns when doing the pero gambit. At 50-50% chances , i noticed that the next patterns apear more often then others :

1. Top left , middle bot , top rights are Os
2. Top left , top middle , bot middle Os
3. Bot left , top middle , bot right are Os.

This 3 are what i've noticed apear from time to time , with higher frequency then others at 50-50% (probably because they are simetric paterns , so it was easier to notice ). That's why i usually pressed the top left and top middle usually , since those have the highest chance if we consider the 3 patterns. Obviously , there might be other patterns , or it might be actually random as **** and it was a simple coincidence in my case. Regardless , would be cool if anyone else could test and confirm this with me

Saw that also quite often, it's rly the best to always go top left or mid, same goes for chances, most of the time, at least for me it's mid top or bot.

There isn't actually any rotation. And most definitely not any predetermined pattern.
What you're all seeing is pure unadulterated coincidence, caused by a lot of internal/backend stuff intersecting at the right time.

Anybody that's ever even bothered to try (or learn) doing something random in a program will tell you that there's actually a loooooooooooooooong mathematical calculation done, with initial data gathered from some supposedly random place in your operative system, which is used to return the pseudo-random values you asked for.

These values are usualy decimal numbers that go from 0 to 1 (e.g.: 0.947104038462357230439), which then is multiplied by your target range to get a random integer.
Other implementations just grab random bytes (up to the amount needed for the value type you requested) and perform binary shifting and operations on the bytes to get you the pseudo-random.

The thing is that, sometimes, this results in very similar data being used for consequent fetches (well, consequent for you, as the server has probably done some few hundred thousands of RNG fetches, both for other players and for internal functionalities, between your two clicks), which results in very close values.
It doesn't help that a typical RNG fetch for this game is only in the (1,6) range, or (1,6)->(1,100) for gachas/chances, as that means that out of 4k billion random number you can get from the RNG (that's the posible values of an Integer in Java), they all get smushed up into 100 possible results at best (1 for each % in the rarity chance table). Bottom line? Your RNG could have gotten anything from 0 to 42,949,673 and still count as "lowest 1%" (a.k.a. "Definitely a N-Rarity Card")

I understand. Due to low quantity of objets to permute (6 on PPS), that random system can place answers in common positions. The only what is possible to calculate with current data is the frequency of some results on certain timelapse. And it isn't ensure that the next answer will be the correct.

We can't know how PPS is managing this (i saw your demo decompiling main program), if is pure random or has a pattern (or mix both to make the shape that has a pattern, fooling the player as you guess). Results are the only data available to work and may be different for each player.

I'll try to see pos of gachas later. I was seeing this many times, but i never wrote this to a text file.

Originally Posted by chillinfar

I understand. Due to low quantity of objets to permute (6 on PPS), that random system can place answers in common positions. The only what is possible to calculate with current data is the frequency of some results on certain timelapse. And it isn't ensure that the next answer will be the correct.

We can't know how PPS is managing this (i saw your demo decompiling main program), if is pure random or has a pattern (or mix both to make the shape that has a pattern, fooling the player as you guess). Results are the only data available to work and may be different for each player.

I'll try to see pos of gachas later. I was seeing this many times, but i never wrote this to a text file.

I agree we can't accurately know how they do this. However, we can put more weight in the more logical or common solutions for a game such as this.
The main point to remember is that the server behind this isn't made to handle your game, but a couple million JP players, sending service requests at least every couple of seconds.

That means the server needs to be able to balance a load of possibly hundreds of thousands (or even millions) of requests per second.
In such kind of architecture, you tend to try and minimize any superfluous bit of logic that is pretty much useless to you...

As such, why add some weird rotating pattern to your code, when just randomizing crap works the same?
Applying a pattern requires keeping the pattern stored somewhere (either hardcoded or in database), fetching it, mapping the input data into something that can be put through the pattern, applying the pattern, mapping the results to the required response, and only then returning the value.

Just to make a comparisson:

The simple randomizer works like this:
[LIST = 1][*]Fetch six RND decimals between 0% and 100%.[*]Apply step-ups.[*]Map the 6 results to the "Rarity Table".[*]Fetch a new RND decimal for each mapped range.[*]Fetch data from the IDed cards.[*]Build and return JSON object.[/LIST]

Against a pattern:
[LIST = 1][*]Fetch the pattern list.[*]Fetch a RND decimal to choose pattern.[*]Fetch the chosen pattern.[*]Fetch six RND decimals based on the pattern.[*]Map the 6 results to the "Reward Patterns Table".[*]Fetch a new RND decimal for each mapped range.[*]Fetch data from the IDed cards.[*]Build and return JSON object.[/LIST]

As you can see, patterning is a more complex process.
Also, all fetches and mapings that aren't for RND values imply a call to a database, which can take up to 10k times more to process that a logical process. That's 2 for RND vs 4 for Patterns. So, not only is it more complex (meaning more processing times, more RAM needed, more caching calculated, etc) it actually has twice the delay times corresponding to DB accesses.

All that for something that just having a good randomizer will do equally as good? For no apparent reason besides we wanted a pattern in there?
That's just no good for implementation times, manteinance costs, server costs, etc.

Outside from that discussion i found something interesting: Trends ("tendencias"), and something in statistics named in spanish as "moda" (the most common elements from gathered data). I apologize to don't explain this correctly and confuse it with patterns.

In gacha as example, one R/SR card can't take the same position more than 3 times on consecutive turns. This happens even when other R cards are available, try it.

Extra stage from gambit event showed an opposing example, i never found a 2;6 entries as correct ones, but i saw 2;4, 2;5, 1;4, 3;6, 1;2, 1;6... and even 2;4 (mirror of the "missing" element). Post a screenshot if you see one.

This is not related with the random system, this time i'm discussing it's results. However, seeing that behavior can help on some situations.

Originally Posted by chillinfar

Outside from that discussion i found something interesting: Trends ("tendencias"), and something in statistics named in spanish as "moda" (the most common elements from gathered data). I apologize to don't explain this correctly and confuse it with patterns.

In gacha as example, one R/SR card can't take the same position more than 3 times on consecutive turns. This happens even when other R cards are available, try it.

Extra stage from gambit event showed an opposing example, i never found a 2;6 entries as correct ones, but i saw 2;4, 2;5, 1;4, 3;6, 1;2, 1;6... and even 2;4 (mirror of the "missing" element). Post a screenshot if you see one.

This is not related with the random system, this time i'm discussing it's results. However, seeing that behavior can help on some situations.

Ahh, good old math for probabilities
Be careful... when I said there are no patterns, I meant there are no programmed patterns.
Do something in a computer enough times, and a statistical pattern will emerge.
Sadly, such a thing won't be found by us checking a couple of accounts a couple of times. We're talking about compiling enough data that we could more or less find a pattern in the RNG generator

Those measures aren't detected on 1 day but weeks (except pero gambit, but thanks to stamina i was seeing a lot of results on last and extra stages). It still be a small part of data to detect a potential "pattern", so i prefer to use the other (and realistic) term, trends.

And trends can change over time. However, in Gacha if we simplify the elements to type of cards we got a nice scheme to find a good chance hunting R cards. Remember that N gacha always have (at least) 1 R card, we are lucky to see this condition, which is not present in GHQ or stages.

EDIT: Finally a 2;6 in event.