Gillis PRNGs are basically just a (incredibly long) sequence of random looking numbers, given the same internal state asking for 100 numbers will always give you the same 100 numbers. But if you put in an extra request for a number it throws everything off by 1. You would get the values 1-100 instead of 0-99. So if the predictability of the value is important to your game you have to be careful about how you change the order and number of random number requests you make.
Creating an array of random numbers ( referred to as a permutation table ) can help. The coherent noise methods ( classic2d, etc. ) use a permutation table of the values 0 to 255 in a random order (see Fisher-Yates shuffle).
value = table.get(x % 256) + (y % 256)
value = table.get(value % 256) + (z % 256)
value = table.get(value % 256)
return value
For anyone not familiar the % sign is the modulo operator, it keeps the value between 0 and 255 in this situation.
8 % 256 = 8
256 % 256 = 0
300 % 256 = 44
514 % 256 = 2
An alternative is to reset the state of the PRNG to it's initial value before each batch using
AdvancedRandom.SetSeed(AdvancedRandom.Seed)
That is quite slow, so try and not use it on your hotpath. It involves hashing the seed, regenerating the PRNG state and recreating the permutation tables. If enough people need that I would consider adding an action that specifically resets the state, but faster than the above method.