LSL 101/Event Handler Parameters

Category:LSL 101
 
== Events ==
Understanding events and event handlers is crucial from the very start even if you have prior programming experience, because unlike a traditional computer program, events occurring outside of your script determine when the various parts of your script get executed. (If none of that made sense and you've never had a computer class don't worry, start on the next line!)
When something happens that the script needs to know about, we say an event has happened. LSL knows about many kinds of events and can respond to them depending on what kind of event happened.
Events include things such as when a scripted object
* is touched ( touch events)
* hears something on a channel it is listening to (listen events)
* detects something nearby ( sensor events)
* collides with something or someone (collision events)
* is changed in some way, e.g. position, size, color, inventory, owner (change events)
* receives money ( money) ... and others. 
There are also events which are caused by the script itself without outside intervention. For example, the timer event is used to invoke some action after a predetermined time, or to repeat actions on a regular basis. See Events for full list of events. 
Many events receive information from the server, such as who interacted with the object, the channel on which something was heard, and many other interesting things. 
Events in a script happen in "FIFO" order (First In First Out), however *state_entry* comes first. 
Event handlers (often simply called events) consist of a *block* of code within two curly brackets.
When you change states in a script, all queued events, and any open listens are removed and the state_entry (if any) of the new state will execute. We saw that in the previous example of two states. 
If a scripted object is taken to inventory during the execution of a script and there is no provision for resetting the script when it comes back out, it will return to world running as it was when it was taken. The scripter is free to choose how he wants the script to behave on re-rezzing, via actions in the on_rez event.
=== The State Entry Event===
The *state_entry* event occurs when the script first starts running either
* when a script from your inventory is added to the prim's inventory or 
* when you save > reset your changes after editing a script that is in a prim's inventory. 
When a script first starts, or restarts, it executes any commands (and only those commands) that occur between the { and } of the state_event handler block.
Please note that state_entry is NOT automatically executed when an object is rezzed, nor when a SIM restarts.
The state_entry event handler is not obligatory and may be omitted from your script if no specific action is needed on first execution. 
=== The On Rez Event ===
The on_rez event can provide a convenient way to reset a script without having to manually do this each time you rez your project.
Here's the format for resetting scripts when an object returns to world from inventory. 
default 
{
 on_rez(integer param)
 {
 llResetScript();
 }
 state_entry()
 {
 llOwnerSay("I have been started or restarted.");
 }
// other events go here... 
}
One caution: Never code llResetScript() inside a *state_entry* event - this will produce an endless loop. Use llResetScript() inside some other event such as _rez event to reset the script back it's initial condition, (including the resetting of all global variables) and to invoke the state_entry event of the default state.
Please continue this tutorial with The touch start Event.