Crosstalk - Random Dialog Channel

This is the last issue I will burden the board with today. Sorry for the second post.

I have read in several places ways to get a random channel between say -1000000 and -2000000 but I cant find a good single line of code using, I assume the llFrand function that will supply a number between those two parameters.

Any help, thoughts or links is appreciated!! TIA!!

An example would be:

integer CommChannel = (0 - llFloor(llFrand(20000)));

See /54/7a/223531/1.html for an example of the full implementation

To get the number in the specific range, do a random number less than the difference, then add the lower, and subtract it from 0 . . .

as in:

integer random = 0 - (llFloor(llFrand(1000000)) + 1000000);

I apologize, but my brain is having a hard time understanding all that is going on in that line and the logic employeed. If I understand you guys, then the way to create a negative random dialog channel is to create a positive random number then convert it to negative? Sorry.. I need coffee, but if anyone can expand the concept, maybe a play by play on what that line of code is doing as it does it.. COFFEE!!!!!


OK.. Thanks, I got it working amazingly, but still dont know why... hehe.. Again.. This forum ROCKS!!

so in this line (and correct me if I'm wrong) you are creating a whole number (integer) called CommChannel.

llFrand(20000) creates a random float (number with decimal places) between 0 and 2000.

llFloor rounds the float (number with decimal places) generated by llFrand down to the nearest whole number (integer).

The rest of the sum says start with 0 then work out our number and take it away from 0

so you get 0 - random integer

i.e you end up with between 0 and minus 20000


does the same thing but gives you a whole number (integer) between 0 and 1000000 and calls it random. Although i think you would get the same results from

integer random = (llFloor(llFrand(1000000));

Hope that helps

And if I'm wrong /me goes back to school

or to get a negative channel between -1 and -2147483648 (MIN INT) just use:

vIntChannel1 = (integer) llFrand(-2147483647.0) - 1;

Well done Monica a suitably elegant way round things. Is it just me or were the two examples abit more complicated than necessary?

Yep, nice Monica, thanks

Thanks for the input everyone.. I better understand the last example.. But I am well coffied.. hehe...

Again, rare to have such a great support forum of fellow users!! I hope someday I have something to contribute besides noob questions..

Just fantastic!! TY ALL!!

Not sure if it is fixed now, but at one point, llFrand would not accept a negative integer as an argument. So subtracting a positive random from 0 was necessary. I just got so used to doing that, I never noticed if it got fixed.

My line of code does this . . . (follow the parentheses)

llFrand(1000000) . . . find a random float between 0 and 1000000
llFloor() . . . and get the integer "rounded" down (could also typecast as integer)
+ 1000000 . . . make the number be between 1000000 and 2000000 (as the original poster specified
0 - . . . and subtract it from 0 to get a negative integer.

Hope that helps understand it a bit better

Wow, so much more complicated then it needs to be:

integer CommChannel = (integer)llGetGMTClock() * -2;

takes the current number of seconds from 12:00am multiplies that by -2.

You get a negative number that unless someone uses the item EXACTLY at the same time, you will not have any chatter. Easier on the client, easier to code.

Random numbers, in the computer world, are extremely unnatural. The computer would actually use some process timer or number and do a calculation against the range that you have selected. This, though very small, can slow a system down, mainly server side, Linden can thank me later.

Only as complicated as it needs to be to get what the OP asked for; a number between 1000000 and 2000000

i use time polling for *random* chat numbers too, like a random seed, but only on public objects that are in a situation to be hit heavily

just a quick way to totally avoid dupe channels

Since I don't sell my scripts and most are one of's, 90% of the time I just type a minus sign, close my eyes and hit a bunch of numbers in the num pad.

Using a random channel is, I've always thought, a rather poor way of avoiding crosstalk anyway.

Far better to use llGetOwnerKey to check that the talking item is one of your own, and to use a distinctive message format so that your items can recognise their own...

A random channel might be useful if you want to make eavesdropping harder, but that's about all..

All right.. this is going to sound tottally noobish.. Thank me later for the warning...

I previously wrote my script to use the dialog channel based from a global variable, that made it easy to access where ever I needed a dialog menu, I even hid some in seperate functions... I bet you see where this is headed... So now I try to implement the random channel scenerio and realize that my variable can no longer be global.. and the result for me is a broken script... the first time through the dialogs, it sees and hears fine, but then, upon using an outside function, the script seems to forget the random channel previously attained.. I have tried passing the variable in the call to the outside function in the call header with no luck.. If you have read this and it sort of makes sense, please point me in a direction or strategy that 'simulates' creating the dialog channel to seem like it is a global yet still be dynamic?

What if you have two of the same item?

Yes, I think I get it now!! And you are right on point, I did specify the higher range specifically, though logically, now I realize it is unecesary.

A random channel is also good to help avoid unnecessary processing. Even if you insure that it is from the correct owner or in the correct format, the script will be receiving less potential crosstalk messages on a large random channel that aren't it's own, and so will need to do less processing to filter through them.

Though, admittedly, the potential for crosstalk messages on a large negative random number channel is pretty slim anyway.

To avoid eavesdropping for important communications, use encryption too.