RNG implementation in a multi-thread setting

[Janick]

Hi all,

I currently play on a server where the rate for achieving a socket via met spam at Artisan Wind is set at a base rate of 0.1% + (Number of Met Spammed)/3000. With lucky time, the base rate increases to 0.3%. However, the number of sockets being created seems to be very low throughout the server. I've personally spammed around 3,000 and a couple with around 5,000 before they got one. It may be down to bad luck, but this feels a bit off.

(For those with maths background, assuming a binomial distribution with the probability of success at 0.1%, the probability of achieving at least one socket in 3000 mets is 95%. Given that the rate is supposed to increase the more mets you spam, it follows that over 3,000 mets, the probability of success must be even higher.)

I don't have access to the code but from my interaction with the developer, the code that does the socketing works something like this:

  if ((Role.Core.PercentSuccess(client.Player.BlessTime > 0 ? (GLOBAL.LUCKY_TIME_SOCKET_RATE + spamRate) : (Global.SOCKET_RATE+ spamRate))) 
 { 
 	// Add socket to equipment 
 } 

  public static bool PercentSuccess(double _chance) 
 {
return Program.GetRandom.NextDouble() * 100 < _chance;
 }

 if (clock > Program.ResetRandom) 
 {
Program.GetRandom = new FastRandom(Convert.ToInt32(randomDate.Ticks.ToString().Remove(randomDate.Ticks.ToString().Length / 2));
       Program.ResetRandom = Time32.Now.AddMinutes(30);
 }

        public FastRandom(int seed)
       {
           SyncRoot = new object();
           Reinitialize(seed);
       }

       public void Reinitialize(int seed)
       {
           lock (SyncRoot)
           {
               x = (uint)seed;
               y = Y;
               z = Z;
               w = W;
           }
       }

       public double NextDouble()
       {
           lock (SyncRoot)
           {
               uint t = (x ^ (x << 11));
               x = y; y = z; z = w;

               return (REAL_UNIT_INT * (int)(0x7FFFFFFF & (w = (w ^ (w >> 19)) ^ (t ^ (t >> 8)))));
           }
       }

The implementation seems similar to the Redux Source (see https://github.com/luckymouse0/Redux-Conquer-Online-Server/blob/master/Redux/Network/GameServer.cs and https://github.com/luckymouse0/Redux-Conquer-Online-Server/blob/master/Redux/Common.cs), except Redux uses a customised ThreadSafeRandom. But without access to the code and not having much knowledge about multithreading/CO servers, I'm a bit stuck with further questions to ask/consider.

I've done some testing by creating my own FastRandom class and running a for-loop to spam mets. I ran 100 trials spamming 3000 mets with a base rate of 0.1% each time and I've always created a socket. With lucky time boosting the base rate to 0.3%, I would be reasonably confident to get a socket. So the area of suspicion for me is how the FastRandom was implemented/works. I'm wondering whether it's possible for the NextDouble to return the same number when called in succession?

[Rezlind]

With all due respect, without access to the actual code so you can definitively see rates there is no way for you to confirm what is happening. With numbers like 3000 meteors for a higher probability to get a socket you won't be able to realistically emulate your tests in-game. I don't think there is necessarily anything wrong with the implementation. Your sample size from actual meteor upgrades in-game will be significantly smaller than how many automated tests you run.

So far you stated you spammed about 1 sample size worth of the expected number of meteors in-game. It's not guaranteed, it's just likely you will make the socket within 3000 meteors.

If this is a concern perhaps the owner can create a test server and lower the numbers so you can run a larger sample.

[Janick]

Thanks, I will suggest that.

I understand it's not guaranteed, it's just the math suggests that I must be really unlucky, or something's gone wrong somewhere. It's more for my own sanity more than anything!

[Rezlind]

Thanks, I will suggest that.

I understand it's not guaranteed, it's just the math suggests that I must be really unlucky, or something's gone wrong somewhere. It's more for my own sanity more than anything!

Yeah, it's easy to feel like you're really unlucky in these situations but it's so difficult to test unless the owner adds unit tests to the socketing code. That's also another suggestioin for the owner to verify things are working as intended.

[Tachyon]

Hi, If it follows the formula you wrote, then the math indeed shows there is something wrong with the code. I ran quick experiments and it seems the expected number of trials to get a socket is actually around 450 with standard deviation around 320. Thus the probability of using more than 5000 meteors is less than 0.005. Twice is (0.005)^2 = 0.00002. Once more or twice and it seems like 0.

[Janick]

Hi, If it follows the formula you wrote, then the math indeed shows there is something wrong with the code. I ran quick experiments and it seems the expected number of trials to get a socket is actually around 450 with standard deviation around 320. Thus the probability of using more than 5000 meteors is less than 0.005. Twice is (0.005)^2 = 0.00002. Once more or twice and it seems like 0.

Yes, that's what I would expect.

It seems the owner screwed up the rates so it was lower and I did eventually get a socket after another 500 (at which point, the rate would've been around 1.4-1.5%) . I'm now at about 800 with no luck, but somebody got one with < 100 the other day.

But the reality is that without access to the code, it's unlikely I'll spot anything.