Jump to content

Multiple Timers


Tulinz
 Share

Recommended Posts

If you have used Innula's LSL snippet as she wrote it, it will automatically reset the counter value to zero when the script resets.  When a script resets, ALL variables are reset to their default values.  Numerical (integer and float) variables are set to zero. If you have modified the code somehow, the best way to track down your error may be to add a few llOwnerSay statements at strategic places to see what the value of count or other variable is.  You will find that you have accidentally changed the logic somehow, so your diagnostic llOwnerSay statements will help you locate the mistake.

Link to comment
Share on other sites

Actually we have more timers than the one associated with the timer event
llSensorRepeat() has an associated timer
and llGetTime() has one

A script using the latter may look as simple as this:

default{    state_entry()    {        llSetTimerEvent(60.0); //set a timer event every minute.    }    timer()    {        //do stuff to change texture        if ( llGetTime() >=600.0 ) llResetScript();    }}

 :smileysurprised::):smileyvery-happy:

Link to comment
Share on other sites

As Rolig says, my script does reset when the counter hits 10, so something must have changed when you adapted it.

Besides putting in the llOwnerSay calls, I would check that you've not typed if (counter = max) (wrong) rather than if (counter == max) (right).   That's easily done, and will compile but won't work.

Link to comment
Share on other sites


Innula Zenovka wrote:

As Rolig says, my script does reset when the counter hits 10, so something must have changed when you adapted it.

Besides putting in the llOwnerSay calls, I would check that you've not typed
if (counter = max) (wrong)
rather than
if (counter == max) (right)
.   That's easily done, and will compile but won't work.

If Tulinz didn't copy/paste, I think this is the most likely error.

While we're discussing this, I'll bring up a habit I've developed over years of fixing code written by an idiot (me). I am now leery of testing for equality to bound a counter. Doing so doesn't catch errors resulting from interesting ways I might modify the counter, like incrementing by ten to fast forward, etc.  Nor does it catch my failure to initialize the boundary.

At the very least, I'd code the termination test as if(counter >= max) which takes a little additional typing effort and may require additional machine instructions if the processor cannot test the zero and carry flags simultaneously, but does allow creative modification of the counter with less worry of breakage.

If I were particularly conscientious (I'm capable of that under the right circumstances!), I'd code it as if( (counter<0) || (counter>=max) ).

 

 

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...