Difference between revisions of "Talk:LlSetTimerEvent"
(New page: 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.) |
Omei Qunhua (talk | contribs) (Reason for revision) |
||
(5 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
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. | 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. | |||
[[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.