Difference between revisions of "Talk:LlSetTimerEvent"
Tali Rosca (talk | contribs) |
Omei Qunhua (talk | contribs) (Reason for revision) |
||
(3 intermediate revisions by 2 users not shown) | |||
Line 16: | Line 16: | ||
-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. | -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 | The behaviour is easy to observe with a script like<lsl>default | ||
{ | { | ||
state_entry() | state_entry() | ||
Line 43: | Line 41: | ||
state one; | state one; | ||
} | } | ||
} | }</lsl>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. | ||
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) | [[User:Tali Rosca|Tali Rosca]] 21:23, 15 November 2009 (UTC) | ||
---- | ---- | ||
'''IMPORTANT?? notes''' | |||
The llSetTimer() page had a plethora of "IMPORTANT" notes. However one was already covered in other notes, one referred to personal style preference, and the third relates more to understanding of llFrand() than llSetTimer. I have taken the liberty of removing them while fixing the example script which was in a non-compilable condition. |
Latest revision as of 13:22, 30 December 2012
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<lsl>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; } }</lsl>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)
IMPORTANT?? notes The llSetTimer() page had a plethora of "IMPORTANT" notes. However one was already covered in other notes, one referred to personal style preference, and the third relates more to understanding of llFrand() than llSetTimer. I have taken the liberty of removing them while fixing the example script which was in a non-compilable condition.