Difference between revisions of "Talk:LlSetTimerEvent"
Tali Rosca (talk | contribs) |
|||
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)