Simple dice script?

I'm looking for a script that can be placed into a single prim to be rezzed and used as a very simple dice for roleplaying. When the prim is touched by any avatar, the script would detect the avatar's name and return a random number from 1-50, thus:

Avatar A touches the prim. Response: "Avatar A rolls 36"

Avatar B touches the prim. Response: "Avatar B rolls 16"

I'm probably asking for the most simple script ever, but I'm a complete newbie when it comes to scripting, so any help would be greatly appreciated. I know there are plenty of dice available out there, with all the typical variants that tabletop gamers are used to, but I'd like to put this in a free beginner's roleplaying kit, thus the simpler the better.

Many thanks in advance, if you can help!

*cough* One die; two dice.

Anyway.

default
{
   touch_start(integer n)
   {
      llSay(0, llDetectedName(0) + " rolls " + (string)llCeil(llFrand(50.0)));
   }
}

You might want to use '1+llFloor(llFrand(N))' rather than llCeil(). Most of the time it won't make a difference, but the range is technically closed at zero and open at N, so it's possible (though quite unlikely) the llCeil() will return zero.

Well it's not that low. Surely it's a 1:51 chance. That seems high enough to worry about it to me.

No, it's not THAT bad. It has more to do with the internals of the (pseudo-)random number generator. If the random number is 0.00000001 it will still round to 1.0, but zero is technically included. If the main bit of the internal algorithm generates integers between 0 and 32767, for example, then the chance of getting a zero would only be 1/32767.

No. You're basing this on the final value after the conversion to integer. But Frand(50.0) doesn't return results from a space of 50 or 51 possibilities, it returns from the space of all floating point values in [0.0, 50.0), ignoring the limits of the algorithm. So there's actually a huge number of possible results, only one of which - 0.0 - will trigger the problem.

But programming is about getting the details right, not just usually right. So the 1 + llFloor approach is the one to use. I'm sure we can all think of bugs in SL that got out the door because something was rare enough that the developers didn't detected it earlier.

Casting to integer should be faster then the simulator processing llFloor:

(string)(integer)(llFrand(50.0)+ 1)

True. I actually do it that way when I am coding, so I'm not sure why I suggested the other. Probably the initial use of math functions and a higher intuitive tie between them and well-specified, precise behavior.

All for the good anyways. Threads like this are real gems for the new scripters, furthering thier understanding of the different functions.

[edit] made an invalid assumption.. Deleted message to avoid looking like an idiot

No, you are quite right. Using 1 + llFloor instead of llCeil here is the appropriate thing to do. The fact that the possibility of it returning an inappropriate result is miniscule (I have never encountered it, and I have generated an awful lot of random numbers) is not the point; working from the logic is not only less likely to return something inappropriate but also more elegant and ethically sound.

Thanks for all the replies! I'll try that out this weekend. Out of the two suggestions, which would be better: llFloor or casting to integer? (Says he, making out like he knows what the HELL he's saying...)

Also, yeah, I knew someone would call me on dice/die *g* I blame the lateness of the hour of my posting...

It doesn't really matter. Casting to an integer is probably slightly faster. llFloor() is more explicit and is thus possibly a little bit more readable/maintainable. In this case they should always have the same semantics. For negative numbers they would be different as casting truncates (rounds toward zero).