Difference between revisions of "Category:LSL Events"

From Second Life Wiki
Jump to navigation Jump to search
(What events are and how they work?)
m (typo, clarification)
 
(12 intermediate revisions by 5 users not shown)
Line 1: Line 1:
{{LSL Header}}
{{LSL Header|ml=*}}


Within states LSL works on events, such as the scripted object starting to move ([[Moving_start]]), colliding with things ([[Collision_start]]) or timer events ([[Timer]]).
Within [[state]]s LSL works on events, such as the scripted object starting to move ([[moving_start]]), colliding with things ([[collision_start]]) or a recurring timer ([[timer]]).


Apparently at least the [[State_exit]] and [[State_entry]] events are local to the state. It is said that a timer set by [[LlSetTimerEvent]] is not automatically reset by state changes, but not whether or not the timer still invokes the [[Timer]] event from the original state or the current state. Also, as events should not interrupt each other, but instead they are said to be enqueued, it is unclear, whether or not a [[Timer]] event placed on the queue is replaced with the equivalent of the current state, if events in the queue before the timer event change the state.
Events do not interrupt each other, but instead are queued {{HoverText|FIFO|First In, First Out}}, though the [[state_entry]] event can jump the queue. If more that 64 events are waiting, new events are discarded until free slots become available. If the script is paused, such as when an object is taken to inventory, pending events are preserved and handled the next time the object is rezzed.
On state change the event queue is cleared and any open listens are [[llListenRemove|removed]] automatically. Reoccurring sensor events ([[sensor]]) are set not to reoccur in the new state and must be manually re-enabled (via [[llSensor]] or [[llSensorRepeat]]), but timer events (from [[llSetTimerEvent]]) ''do'' reoccur. Please refer to the [[State]] article for further details.
 
For legacy LSL - the events are registered as bit flags in an unsigned-64 bit integer, meaning there can only ever be 64 events.
 
 
{{KBtrivia|<b><code>event</code></b> is a reserved word in LSL, but it is not used. If you try to use it as a function or variable name, it will cause a syntax error.}}
 
{{LSLC|Keywords}}
{{LSLC|}}

Latest revision as of 08:29, 13 May 2014

Within states LSL works on events, such as the scripted object starting to move (moving_start), colliding with things (collision_start) or a recurring timer (timer).

Events do not interrupt each other, but instead are queued FIFO, though the state_entry event can jump the queue. If more that 64 events are waiting, new events are discarded until free slots become available. If the script is paused, such as when an object is taken to inventory, pending events are preserved and handled the next time the object is rezzed. On state change the event queue is cleared and any open listens are removed automatically. Reoccurring sensor events (sensor) are set not to reoccur in the new state and must be manually re-enabled (via llSensor or llSensorRepeat), but timer events (from llSetTimerEvent) do reoccur. Please refer to the State article for further details.

For legacy LSL - the events are registered as bit flags in an unsigned-64 bit integer, meaning there can only ever be 64 events.


KBtrivia.png Trivia: event is a reserved word in LSL, but it is not used. If you try to use it as a function or variable name, it will cause a syntax error.