Difference between revisions of "LSL 101/Event Handler Parameters"

From Second Life Wiki
Jump to navigation Jump to search
m (header fix)
m (<lsl> tag to <source>)
 
(11 intermediate revisions by 3 users not shown)
Line 1: Line 1:
[[Category:LSL 101]]
[[Category:LSL 101]]
{{NavNextPrev|prev=The Structure of a Script|next=Variables}}  
{{NavNextPrev|prev=Comments, White-space and Formatting|next=The touch start Event}}  
{{LSL Wikibook Index}}
{{LSL Wikibook Index}}


Line 6: Line 6:
== [https://wiki.secondlife.com/wiki/Category:LSL_Events Events] ==
== [https://wiki.secondlife.com/wiki/Category:LSL_Events Events] ==


<small>''Understanding events and event handlers is crucial from the very start especially if you have prior experience with programming, 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!)''</small>
<small>''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!)''</small>


When something happens 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.
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 like when an avatar or object
Events include things such as when a scripted object
* types something in chat ([[Listen |listen events]])
* is touched ( [[Touch|touch events]])
* gets close to your prim ([[Sensor| sensor events]])
* hears something on a channel it is listening to ([[Listen |listen events]])
* touches your prim ( [[Touch|touch events]])
* detects something nearby ([[Sensor| sensor events]])
* collides with your prim ([[Collision|collision events]])
* collides with something or someone ([[Collision|collision events]])
* changes the prim's inventory ([[Changed |change events]])
* is changed in some way, e.g. position, size, color, inventory, owner ([[Changed |change events]])
* pays your prim ([[Money| money]]) ... and others.  
* receives money ([[Money| money]]) ... and others.  


There's also events which seem to happen by themselves but are indeed triggered.  For example, the [[Timer|timer event]] is used to move the action along, or to repeat actions on a regular basis. <small><b>See [https://wiki.secondlife.com/wiki/Category:LSL_Events Events] for full list of events.</b></small>  
There are also events which are caused by the script itself without outside intervention.  For example, the [[Timer|timer event]] is used to invoke some action after a predetermined time, or to repeat actions on a regular basis. <small><b>See [https://wiki.secondlife.com/wiki/Category:LSL_Events Events] for full list of events.</b></small>  


Events can also pass information back to the server.  This includes things like the name or UUID of the object or avatar that interacted with it, the channel on which it "hears" things, the speed of objects that hit it, and many other interesting things.   
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.   
Events in a script happen in "FIFO" order (First In First Out), however *state_entry* comes first.   


Events contain a *block* of code within two curly brackets which is called the *event handler* - often the two terms are used interchangeably.
Event handlers (often simply called events) consist of a *block* of code within two curly brackets.


When you change states in a script, all the event handlers, including listen event handler, will be cleared out and the state_entry of the new state will execute.  We saw that in the previous example of two states.  
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 the prim 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.  Either of these routes may be advantageous to the scriptor.
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.
 
===[[State_entry | 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.  


=== [[On_rez | The On Rez Event ]] ===
=== [[On_rez | 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.   
Here's the format for resetting scripts when an object returns to world from inventory.   


<lsl>
<source lang="lsl2">
default  
default  
{
{
Line 44: Line 58:
     state_entry()
     state_entry()
     {
     {
           llOwnerSay("I have been reset.");
           llOwnerSay("I have been started or restarted.");
     }
     }


Line 50: Line 64:


}
}
</lsl>
</source>
 
One caution: Don't reset the script inside *state_entry* event. Always use the syntax above and use the on_rez event to reset the script back to state_entry.
 
And now a few words about some common events.
 
===[[State_entry | 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
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.
* when you save > reset your changes after editing a script that is in a prim's inventory.
 
When the sim server detects the state_entry event, it executes any commands (and only those commands) that occur between the { and } of the state_event handler block.
 
State_entry event is not required in a script; many scripts do just fine without one. 
 
===[[Touch_start | The Touch Start Event]]===
 
Whenever you see *touch_start* in a script it is followed by a parenthesis and a variable named "num_detected" or "num" or even silly things like "gertie". 
 
Here's what it looks like in a script snippet ...
<lsl> touch_start( integer num_detected )</lsl>
 
The words ''integer num_detected'' is (in fancy computer terms) a declaration of a local variable that has been created and initialized by the sim server.  The server initializes it with the number of distinct touches that have occurred since the last time the touch_start handler was called.
 
For the rest of us, that means this box can count the number of touches it has received, save and use that information, and it does it automatically, you don't have to write some code to make the box count how many times it has been touched.
 
 
Consider this script:
 
<lsl>integer TotalTouches = 0;  // we set the initial touch value to zero
// Every time the box it touched, it will count up one round number ("integer")
 
default
{
    touch_start( integer num_detected )
    {
          TotalTouches = TotalTouches + num_detected;
              // Update the total number of touches
 
         
          llOwnerSay( "I have been touched a total of " + (string)TotalTouches + " times." );
              // Announce the current total
    }
}</lsl>


The variable set above default (global variable) called  ''TotalTouches'' counts the total number of times our object is touched.  Each time the touch_start event handler is called, the sim server initializes ''num_detected'' to be the number of times the object was touched since the previous execution of ''touch_start''.  If you test this by yourself, chances are that ''TotalTouches '' will always be incrementing by one.  But if you get a bunch of your friends together and have them all touch the object as rapidly as they can, sometimes you will see ''TotalTouches'' incrementing by more than one.


<small>If you'd like to learn more about *touch_start* before moving on, please click on this [[LSL 101/The touch start Event | sidebar]].</small>


== Summary ==
There are many events (about 38 different ones) and most of them have one or more parameters (that's those things like "integer num_detected" that follow them in the parenthesis).  The details will differ with the event, but the idea is always the same.  Each event handler handles one particular type of event and the parameters in the event handler provide the script with the specific details of the event.


'''Please continue this tutorial with [[LSL_101/Variables |Variables]].'''
'''Please continue this tutorial with [[LSL_101/The touch start Event|The touch start Event]].'''

Latest revision as of 13:41, 24 January 2015

← Comments, White-space and Formatting ↑̲  LSL 101  ̲↑ The touch start Event →


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

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.