I think it is possible that something is glitched with the use of Trait Disruptors on this particular pet.

https://www.sylestia.com/forums/?thread=24911&page=36#356

I did the probability math based on the number of non-Restricted Sylvorpa trait that exist, and the odd against this happening by chance are 86,975/483,729,408. In decimal form, that's about 0.0001798. Hence my belief that this could be the result of some kind of error.

Incidentally, does Sylestia use a TRNG or a PRNG? I've wondered.

I'm not 100% sure, but from the post you linked, it looks like you used multiple disruptors on the same Sylvorpa and you're saying basically the traits cycled through?

There is nothing at all that carries over from one use to another. The sole database entry that stores a pet's genetics is updated. So there is not a single thing that comes into play that would have anything to do with previous traits a pet had from previous disruptor uses. To the code, it is 100% blind to that information.

And I'm not sure what you mean by TRNG or PRNG. I'm assuming you're referring to some sort of random system?

For disruptors, the code first grabs all valid Traits by letters for what you're disrupting. I believe it will then first random the valid trait slots to find which trait slot to search through. Each slot is placed into an array and I use PHP's built in array_rand to select a random element within that array.

Once a slot is picked, it then does the same thing but to decide which trait letter for that slot. Once that's decided, it then does a dice roll basically to see if a Hidden Carried is triggered. If so, it grabs another random trait. It then re-orders for appropriate Dominant/Recessive display if necessary.

The process is the same for each and every use of a disruptor and at no point does it matter what the pet has as its current traits.

Yes, that's exactly it. The same traits cycled through.

And ahat was kind of my concern--that something had carried over. I know that it is not supposed to.

TRNG is true random number generator. PRNG is pseudo-random number generator. I did a quick search, and it looks like array_rand is a PRNG. Perhaps that explains the pattern repeating?

I've ran a lot of tests - just out of curiosity - over the years with the random algorithms I use and I've never been able to discern any actual bias.

If I simulate a million iterations of a random, all the results are pretty much always within a fraction of a percent of each other.

I mean, is it even possible to have a true random number generator from a computer? With exception to like some crazy supercomputer processing power. At the end of the day, I feel like there is no such thing as "true" random. It all has to be based off of something - whether it be a micro timestamp, CPU thread state, or whatever the source is.

You've got to remember, humans are very good at seeing patterns when there are none there. There is a limited number of traits so there is an x% chance of getting the same trait again. We are more likely to notice if the thing that happens is "significant" but that doesn't change anything, the x% chance doesn't care if that same trait just appeared.

iTunes had this same problem where people didn't think it was true random because it would sometimes play songs that were next in the album when shuffled. Humans struggle with the concept of true random because our minds will cling to any pattern we can devise.


"The problem is that to humans, truly random does not feel random," Mattias Petter Johansson, a Spotify developer

So I took a look at this and found out some interesting stuff.

It seems that array_rand is actually pretty lacking and in a test I did I was able to produce an issue where 1 number out of 100 was pulled significantly less than the other 99. And this repeated for every iteration - the same number.

I also noticed some slight patterns with some of the other numbers, but they were all within a fraction of a percent of each other.

So I then started looking around and found some info that apparently array_rand in PHP 5.X is confirmed to have issues and not be all that random. It apparently relies on an older built in random algorithm rather than utilizing the newer ones. However, it seems that this has been fixed as of PHP 7.1.

At this time, we are still using PHP 5.X but will be updating to the newest version of 7 in the very near future.


With your very small sample size, I highly, highly doubt anything would really affect it. Even a flawed random is random when taken on a small sample size. It only really appears to be flawed when looking at many, many data points.

But I do appreciate the conversation and will try to add in a shuffle to arrays being done on array_rand for future content. This appears to completely fix any possible random bias as it's basically randoming and then randoming again.

However, I do not see myself applying this retroactively. The amount of array_rand in the code is in the hundreds across dozens of files. To find and replace all would be a painstaking nightmare lol.


TLDR: array_rand not so rand, flaws detected. Flaws apparently fixed in PHP 7.1. Flaws can also be bypassed by adding in a shuffle before using array_rand. Will be working towards both solutions in the future.


Edit: To also add, our regular mt_rand seems perfectly randomized. I detected no issues at all with it. It's used for all of the other random determinations in the game.

Thanx for the reply, Krin. I will study it in more detail when I am a bit less worn out, but I must admit all this stuff interests me greatly.