Difference between revisions of "Talk:LlSetTimerEvent"

From Second Life Wiki
Jump to navigation Jump to search
Line 5: Line 5:


* If there are multiple states with timer events in the same script, always use a conditional to determine which code should be executed in the timer event.
* If there are multiple states with timer events in the same script, always use a conditional to determine which code should be executed in the timer event.
----
There is a somewhat quirky behaviour across state changes:
Say you run a timer at 10-second interval, and it fires at time 0, 10, 20 etc...
If you switch into a state without a timer event handler, the timer still "ticks", but of course, nothing is triggered.
If you return to the state with a timer event after less than 10 seconds, the next event will fire "on schedule" at 30, 40 etc...
But if you stay in the second state longer than a timer cycle (say, 15 seconds), the timer event *will immediately fire* upon return, and then pick up a 10-second interval *after that*, i.e. 35, 45, 55 etc.
-In fact, it tends to return to a schedule looking like 35, 44, 54, 04, i.e. the first interval being a little shorter, but that is likely just lost precision due to the processing during a state change.
The behaviour is easy to observe with a script like
default
{
    state_entry()
    {
        llSetTimerEvent(10.0);
        state one;
    } 
}
state one
{
    touch_start(integer total_number)
    {
        state two;
    }   
    timer()
    {
        llOwnerSay((string)llGetUnixTime());
    }
}
state two
{
    touch_start(integer total_number)
    {
        state one;
    }
}
Touch it to go into state two, wait for 15 seconds, and touch it again. Compare to what happens if you only wait 5 seconds.
[[User:Tali Rosca|Tali Rosca]] 21:23, 15 November 2009 (UTC)
----

Revision as of 14:23, 15 November 2009

It would be really great if this Wiki contained information that lots of other scripting wikis contained such as whether a timer, once set, persists across state changes.

(Ramana Sweetwater 2009/01) LlSetTimerEvent will trigger timer events in all states within the same script where the request was made.

  • If there are multiple states with timer events in the same script, always use a conditional to determine which code should be executed in the timer event.



There is a somewhat quirky behaviour across state changes: Say you run a timer at 10-second interval, and it fires at time 0, 10, 20 etc... If you switch into a state without a timer event handler, the timer still "ticks", but of course, nothing is triggered. If you return to the state with a timer event after less than 10 seconds, the next event will fire "on schedule" at 30, 40 etc... But if you stay in the second state longer than a timer cycle (say, 15 seconds), the timer event *will immediately fire* upon return, and then pick up a 10-second interval *after that*, i.e. 35, 45, 55 etc. -In fact, it tends to return to a schedule looking like 35, 44, 54, 04, i.e. the first interval being a little shorter, but that is likely just lost precision due to the processing during a state change.

The behaviour is easy to observe with a script like

default
{
    state_entry()
    {
        llSetTimerEvent(10.0);
        state one;
    }   
} 
state one
{
    touch_start(integer total_number)
    {
        state two;
    }    
    timer()
    {
        llOwnerSay((string)llGetUnixTime());
    }
}
state two
{
   touch_start(integer total_number)
    {
        state one;
    }
}

Touch it to go into state two, wait for 15 seconds, and touch it again. Compare to what happens if you only wait 5 seconds.

Tali Rosca 21:23, 15 November 2009 (UTC)