Need a lil help.

Not a scripter but I do fiddle around with existing scripts. What I need I think is simple so I hope someone here can help me out.

I'm working on something that when touched will give a random responce from preloaded phrases. There will only be about 10 phrases but I don't know how to script this...any help would be greatly appreciated.

list glMessageList = ["message one", "message two", "etc..."] ;	// Put your list of messages here

integer giListLength ;

default
{
	state_entry()
	{
		giListLength = llGetListLength( glMessageList ) ;     // How long is my list of messages?
	}

	touch_start( integer num )
	{
		integer random = (integer)llFrand( giListLength - 1 ) ;     // Generate a random number between 0 and giListLength

		llWhisper( 0, llList2String( glMessageList, random ) ;
	}
}

I'm sure someone's gonna post another response in a few minutes, with a much better solution than the one I just provided. It never fails.

nope thats the best solution i can think of for the situation.

Why am I always wrong???

Well, just to prove you right afterall, the random line should be

// Generate a random number between 0 and giListLength - 1
integer random = (integer)llFrand( giListLength) ;

"Why?" I hear you cry aloud? Because as the comment states, we want a random number between 0 and giListLength -1.

Casting a float to an integer doesn't round the integer, it floors it, which is to say, the decimal part is simply chopped off.

So, numbers between 0 and 0.9999.... will become 0, 1.0 to 1.9999.... become 1 and so on.

Say you had a list of length 10. The indicies of this list are 0 to 9. llFrand(10) will give you numbers from 0 to 9.999999.... and if you cast that result to an integer, it should give you an even distribution of integers between 0 and 9 (if llFrand works right) which is what we want.

the only problem with that is it's possible to actualy go past the end of the list if you actualy hit the upper bound.

and i believe it doesn't floor it. i believe what it does is (the mathematical equivalent to the code below but it's allot simpilar then depicted.)...

float ft;
integer it;
if(a>0)
    it=llFloor(ft);
else
    it=llCeil(ft);

3 = (integer)3.5
-3= (integer)-3.5


(the actual act of converting a float to an integer just requires copying a set of bits from the mantissa to the integer given the shift based off the exponent, then correcting for overflow and coping the sign over)

I will claim that since we are dealing with list lengths and therefore only positive numbers, I was correct for the scope of the discussion

(Are you 100% sure about the behaviour of llFloor with negative numbers? I've never tested it, but I suspect that it always moves the number closer to 0)

not to break the concentration of this thread... but why do some threads like this one get so wide on the screen?

Does anyone else see this too?

It's because text in code blocks doesn't get line wrapped
and there are some long lines of code above.

i don't play much with llFrand but integers i do play with (and pride my self on exactly knowing the effects of operators and typecasts)

ever wanted to know how to add or subtract one to/from an integer without using +,-,&,|,^,<<,>>?

integer a=5;
(~0)*(~a)==6
~((~0)*a)==4

not very useful but it will get you where you need to go. Nor is it efficient (will only work for signed integers but will work with any number of bits).

hehe, how 'bout we skip one extra variable and condense it to death

list MyStringList = [ "blah blah blah", "some more blah", "and I'll stop babbling..." ];

llWhisper(0, llList2String( MyStringList, llFloor(llFrand(llGetListLength(MyStringList) - .1 )));

ehhh but then your checking the list length each time which will slow down the script.

Because
1) This doesn't gain anything from a optimization perspective, you're still executing the same function calls. And as Strife pointed out, this is actually slightly lossier

2) It's harder to read and maintain.


10 minutes with a pen and paper later: *head explodes*

Oh jeez, the nitpick begins... I do agree with point A, but B is a bit much.



Woops, yeah forgot, LSL is a meta language. Memory versus CPU, memory doesn't really count at all anyways (as memory allocation is kinda wierd in LSL)... After a quick test, the speed loss is very negligable, and if running on a fast sim, is entirely unnoticable, both in TTC and Sim FPS. As for slower sims, true true. Gotta quit thinking like I'm writing in C and have a whole CPU thats rather idle



Well, I feel thats up to one's eye and a matter of opinion. Notice the spacing used on it. Very easily readable by my eye. Infact, by condensing it, there's allot less hunting and dodging around the source versus reading across one line. In my own opinion, give me single line than break it out into 5 lines. Yes simpler to read for many indivduals, but a well formated single line often can allow for allot neater, and tidy code.

Example A:

x += (4 * y / z) * TWO_PI;

Example B:

float I = 4 * y;
float H = I / z;
float K = H * TWO_PI;
x = x + K;

Which one can you understand easier, example A or B? Right away, my eye can read, and understand A much faster. As I had mentioned, matter of eye. B for me takes way too long to read, and understand, plus, takes up valuable source space.

Well, clearly this is a style choice, and as with any style choice, we'll just have to agree to... I AM RIGHT AND YOU ARE WRONG!!! WRONG WRONG WRONG!!!

lmao, oh you're right again Wednesday... Oh I'm so sorry! Please don't punish me!