Exiting a while loop

Hi, I have an object that when a keyword is said, it moves a peice of the object back and forth by calling llSetPos, within a while loop. (while condition = true).

When the object is set in motion, it calls my loop located within the function do_loop()

The problem I'm having is getting the loop to stop. I have a global variable (condition) which when the user says a keyword, sets the condition to false, but the loop continues to go. I think the problem is that since the script is continuing to loop through my while loop, no other code is being executed (the second listen to exit the loop). Does anyone know a workaround for this?

integer speaker_state = FALSE;

move_out(float distance, integer steps)
{
float step_distance = distance / (float)steps;
vector offset = <0.0,step_distance,0.0>;
vector base_pos = llGetPos();
integer i;

for (i=0;i<= steps;i++)
{
llSetPos(base_pos + i * offset);
}

}

do_loop(){
while (speaker_state == TRUE){
move_out(-0.1,1);
move_out(0.1,1);
}
}

default
{
state_entry()
{
llListen(0,"","","Speakers on";
llListen(0,"","","Speakers off";
}

listen(integer channel, string name, key id, string message)
{
if (message == "Speakers on"{
speaker_state = TRUE;
do_loop();
}
if (message == "Speakers off"{
speaker_state = FALSE;
}
}
}

Use a timer event instead of the loop.

float INTERVAL = 0.5;

move_out(float distance, integer steps) {
	float step_distance = distance / (float)steps;
	vector offset = <0.0,step_distance,0.0>;
	vector base_pos = llGetPos();
	integer i;

	for (i=0;i<= steps;i++) 	{
		llSetPos(base_pos + i * offset);
	}
}


default
{
	state_entry()	{
		llListen(0,"","","Speakers on");
		llListen(0,"","","Speakers off");
	}
	
	listen(integer channel, string name, key id, string message) {
		if (message == "Speakers on") {
			llSetTimerEvent(INTERVAL);
		}
		else if (message == "Speakers off") {
			llSetTimerEvent(0);
		}
	}
	
	timer(){
		move_out(-0.1,1);
		move_out(0.1,1);
	}

}
 

I assume you want to create vibrating speakers. I'm not sure you'll get the speed out of it you expect to make the speakers move realistically.

I haven't checked if this actually runs.

The call to do_loop() is blocking, that is, it will continue to run until it completes. While do_loop() is running, listen events are queued, not executed. Therefore speaker_state will never be false, thus, do_loop() will never end.

Use timers.

Thanks guys, i kind of figured I would be going with the timers route.

If this is true you are far better off with an animated texture!

( Why use timers and cause full updates when you don't need to ? )

/54/53/58769/1.html

Basically an animated texture consists of a grid of the individual frames, it can arranged in almost any order say, 2x2,4x4,8x8, 1x16, 4x2.

see

http://secondlife.com/badgeo/wakka.php?wakka=llSetTextureAnim

If you 're planning of selling your speaker in clubs using animated textures is less laggy for the club, so you're more likey to sell a few.

Thanks, I'll give it a try...I see lots of resources on creating animations for avatars in the forums but nothing on simply creating an animation for an object such as a speaker. Can poser do this as well?

All you need is Photoshop or Gimp or some other image editing software. An animated texture is just a big texture which is a grid of little textures, where each little texture forms a 'frame' of the animation, and the system just steps through the frames. It's not like an avatar animation where you have to move parts of a skeleton.

Wouldn't it be nice to have a "break" function-call like in C#?

Call me an idiot but... Isn't that what the guard is for?

Changing state is often a good way to do this (because it often happens when you need to exhibit different behaviour anyway) - also you could *shudder* goto a label.
Either of these, of course, suffer from the original problem of events being blocked while in the while loop.
It is really, really important to remember that you are scripting for a world in which all the many scripts in a sim must co-operatively multi-task. We don't have the luxury of dedicated processors, or pre-emptive multitasking. Your event handlers should try to do their work as quickly as possible, and then return.

So, for fast or small movement/rotation, timers are probably your best bet.
For larger or slower movement/rotation, take a look at llTarget and llRotTarget.

(P.S. script scheduling probably IS pre-emptive in some way but pretend that it isn't if you want to write friendly, low-lag scripts)