Creating A Die

Greetings, everyone.

I did some searching in the forums, but I don't think I have a solid answer (or at least a solid understanding) regarding the topic of random number generation in SL.

I'm interested in creating a die object (which I later hope to use in coding games). When I investigated random number generators in the LSL wiki, it stated that LLFrand is not a source of entropy.

Ideally, I'd like to find, code or otherwise acquire a random number generator that will make a die that is significantly random, something that will not be easy prey for hackers and/or other ne'er-do-wells.

I found one code snippet by Ardith Mifflin:

// Written by Ardith Mifflin

integer rand(integer n) 
{ 
    list seed_list = llParseString2List((string)llGetTime(), ["."], [" "]); 
    integer seed = (integer)(llList2String(seed_list, 0) + llList2String(seed_list, 1)); 
    integer result = (seed % n) + 1; 
    return result; 
} 

Can anyone else provide suggestions on how/where to code, acquire, buy, etc. a good random number generator in SL?

Maybe you could try a web-based solution, using HTTPRequest to get at least a random seed? This was the first search return from google on the subject: http://www.random.org/.

you could also do some clever tricks.

take the time of day, the position of the die in the sim, the numbers in the key of the avatar touching it, their age in days, a "random" number, and blend.

Now.. make six different calculations based on these variables. Then use llFrand to select ONE of those 6 calculations. Use the result of the calculation as your seed for another random number.

it's not truly random.. but it will be nearly impossible to ever get the same result twice.

the surgestion above is great, exept for one problem....getting AV's age takes a lot of script (look in library folder, I worte an age detector script).....the least amount of space wpuld be finding the average of 3 to 6 llFrands

or shorter way

lol Shippou.
Caldeyon didn't mean "die" as in kill the object, i think Cal meant "die" as in the singular form of dice
=)
aint english grand, lol

I saw this reference and am puzzled as to why someone made the claim "not a source of entropy" without explanation.

Years ago, I generated a sample of 20,000 calls to llFrand and ran them through a pseudo-random number generator test suite (the name of which I forget). My conclusion at the time was that although I had insufficient data to prove cryptographic strength randomness, it was certainly adequately random for gaming purposes.

I just took a look at the client code and it appears that the client does seed its own PNRG (but I'm confused why there is a client implementation of llFrand as that should run on the sim server).

I think you may be overreaching in trying to get game quality randomness and could just stick with raw llFrand(). I'd love it if someone could show me where I am mistaken. A good challenge would be to generate 110 die rolls, post 100 of them, and see if someone with the series in hand and the algorithm from the source can tell you the next 10 rolls. I would be surprised if they could. Failing that, it seems unlikely that a game player could crack the sequence in real-time.

The most common test for the quality of a RNG is the chi-square test. It is one in a suite of tests called DIEHARD from George Marsaglia of Florida State University.

I tend to agree, though; unless you are doing serious cryptography (highly unlikely in LSL), llFrand is a significant enough source of randomness (entropy) for the purposes of games. It's not a cheesy PRNG.

I just liked my idea beacuse it was unbeleivably convoluted way of using two llFrand calls to generate a number used as a seed for the third "actual" call.

That, and it was cool to look like I knew what I was doing.

The basis of the idea though, I think, is still reasonably sound. if you use at least one number generated based on WHO is doing the touching.. no two people can predictably get precisely the same results. Add into that, the time of day.. and the same person has to be doing the same thing at the same time, just to HOPE to get the same result. Now we add in a random number.

Then we take all the numbers we have.. and do math.

Pseudocode follows:

seedA()
{ seed = random number + time based number - key based number }

seedB()
{ seed = time based number + key based number / random number )

seedC()
{ seed = time based number / random number * key based number }

then, here's the dirty trick.. we do another random call... and based on that number (in this case, 1-3) we choose the calculation method. We then run it, and generate a new "perfect" seed. Which we use to seed a final llFrand call

IN this way, you can reproduce the time, and even the key.. and possibly even the original seed for the random call. But you have another level of unpredictability when you choose the way in which those three numbers are put together. To then have THAT used as the seed for yet another random call.. I think would be so amazingly unpredictable as to be nearly impossible to predict.

Of course.. it's effect on script execution time.. well I won't take any responsibility for that.

Or.. you could just listen to the other posters in this thread.because I really know nothing about randomness.. and a simple llFrand" call is good enough for anything I'd ever do (at least it's better than the random number algorythm on the Commodore 64.. we were able to get idetical results from EVERY c64 in the lab.

Thank you, everyone, for your feedback.

For the time being, I'll stick with llFrand. Even in the worst-case scenario, it will at least allow me to test the logic of the other components. But from what I've heard, llFrand should suffice nicely.