llRequestTimerEvent and timer_request event
Peter Stindberg
The current implementation of the timer event works great for simple tasks. However, it becomes complicated when working with concurrent timers because you need to set the shortest divider for all of them and work with globals and other mechanisms around the timer to determine which timer triggered the timer() event.
I suggest a parallel structure for timer events that is more consistent with other ways of requesting resources from the simulator.
key llRequestTimerEvent(float sec);
It works exactly like the current
llSetTimerEvent
, except it returns a key that holds the UUID of the specific set timer.timer_request(key queryID)
This would be the associated timer event, extending the existing timer event with a key when triggered. This key corresponds with the key returned by
llRequestTimerEvent
.A request to the simulator returns a query ID, which is then compared to an event trigger to determine which code to execute. This structure is familiar to any scripter beyond beginner level.
This suggestion would make working with timers much more efficient. It would reduce resource usage by eliminating the need for 1-second timer loops for complex timing requirements.
Ultimately, the current timer event/function could be incorporated into the new structure. Behind the scenes, a legacy
llSetTimerEvent
would return a NULL_KEY and trigger both the timer
and timer_request
events, the latter with a NULL_KEY.Log In
WolfGang Senizen
While this doesn't help right now, you may be glad to know that multiple timers is a feature that is in the current proposal for the SLua scripting system. can see the proposal here