While function question

I am trying to understand how to have a act initiated when a specific linked message is received and repeat until another message is receive. The "while" or "do - while" function looked like the right way to go but once intiated it does not stop when a new linked message is received. I have it set up along the lines of

if(str=="x"
{
status = TRUE;
}
else
{
status = FALSE;
}
while(status)
{
do stuff
}

I have tried a number of variation, but the result is that once the "while" action starts, it does not stop when another message comes in.

Your script only gets to deal with new event(s) after it's done with handling the event it was busy with, at the time new event(s) occur.

So, basically you have eternal loop in your link_message handler:

while ( TRUE ) { // stuff; }

this causes the handler never leave the link_message, and because of this, it never gets to handle any later messages that could perhaps modify the status variable.

Not sure if the above just said this but

You are setting true or false BEFORE going into the loop - Ie if you set TRUE, and do not adjust the value inside the loop it will always be TRUE - as said above infinite loop

do {
   if(str=="x")
   {
      status = TRUE;
      do stuff -presumably something with str
   }
   else
   {
      status = FALSE;
   }
} ( while status );

( I prefer the while at the end - a me thing )

Interesting issue, at least from my point of view being a new LSL coder.

Here's one way to accomplish it, that may work for you depending on the kind of work you want to do in the loop...

When you receive the first "start" message, set your status on, and then send yourself a "continue" message".

In your "continue" message handler code:
- check the status flag
- if off return, otherwise...
- do one unit of work, ie. whatever you would do in one cycle of the loop.
- send yourself another "continue" message

the "stop" message handler will just have to set the status to off

Use the message queue as your loop driver, instead of "while".

This will most likely be a very slow loop driver, but it can accomplish the job.

You can vary the performance, by doing more than one unit of work for each message.

I knew it had to be faulty logic on my part, just did not know where I was going wrong. I will try these suggestions out.

Another way to achieve this would be to use a timer, assuming the action that's to be repeated doesn't need to be repeated *really* fast. To do this, move your "do stuff" code into the timer event. When you receive the "start" message, start a timer (of whatever frequency you need). As each timer event fires, the "do stuff" code gets executed, but it executes once, and returns. This leaves the overall script in a "ready" state, where it can receive new events, as opposed to a while loop which locks yoru script up. So now all you need to do when you receive the "stop" message is to turn off the timer, and maybe perform any cleanup actions that might be needed.

This is the same thing as what Ken suggested, just that you're using a timer to receive these "tick" events, instead of sending yourself a new message each time. The timer will probably be lighter on the sim. But you need to be judicious in how fast you make your timer, or you'll slow your script down, and maybe even miss "stop" events if your event queue is always full of timer events. Also, there's no point in having a timer that's running faster than the time it takes you to do what you're trying to do. For instance, let's say your "do stuff" code includes an llSetPos call. That has a built-in delay of 0.2s, so you cannot call it faster than 5 times a second, SL won't allow it. So if you use a timer, there's no speed to be gained by using a timer faster than 0.2s. All you'll do is fill up your event queue, which will eventually hurt your script.

I hope that made some sense

I tried the earlier suggestions, and though it was probably due to my misinterpretaton, they did not work. The loop continued. Your suggestion makes sense to me ( that probably means you need a vacation). So I will give it a try.

Seems like to me the best way to accomplish this would be to use STATES.

... receive message (go to) state "somestate_on" - do whatever kind of loop in this state.

... receive another message (go to) state default.

I have a random particle system that uses this for an on/off switch.

states do not address the problem though


it is simple

If you are in an infinite loop, you will NEVER receive any event or message of any form.

You have to finish an event handler in order to allow the next queued event to be processed.

The only way to do this is some kind of timer, there simply isn't a way for external input to interrupt a running loop in a script, short of an llResetOtherScript call.... hey, now that could work *grin*

The "continue" message technique, avoids the timer messages filling up the queue if your work takes too long.

If the sending of a message is slower than your work, then do more work for each message. Do 2 units of work, or 10, etc. You may have to test to optimize the number.

That's good advice.