Jump to content

Multiple Timers


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 post
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 post
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 post
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 post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...