LSL 101/Event Handler Parameters

← Comments, White-space and Formatting

↑̲  LSL 101  ̲↑

The touch start Event →

---

LSL 101: The Wikibook

• A Gentle Introduction
• The Structure of a Script
  • Simple Script Skeleton
  • Comments, White-space and Formatting
• Events & Event Handlers
  • The touch start Event
• Variables
  • Strings and Simple Output
    • String Concatenation
  • Integers
  • Using Variables
    • Global vs Local Variables
    • Variable Initialization
• Functions
  • Functions That Return a Value

The End Game

• Creating a Script
• Compile Time Errors
• Logic
• Conclusion

Events

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!)

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.

Events include things like when an avatar or object

• touches your prim ( touch events)
• types something in chat (listen events)
• gets close to your prim ( sensor events)
• collides with your prim (collision events)
• changes the prim's inventory (change events)
• pays your prim ( money) ... and others.

There's also events which seem to happen by themselves but are indeed triggered. For example, the timer event is used to move the action along, or to repeat actions on a regular basis. See Events for full list of events.

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.

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.

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.

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.

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 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.

The State_entry event is not really required in a script as many scripts do just fine without one.

The On Rez Event

The on_rez event is a convenient way to reset scripts without having to manually do this each time you rezz your project.

Here's the format for resetting scripts when an object returns to world from inventory.

<lsl> default {

    on_rez(integer param)
    {
         llResetScript();
    }

    state_entry()
    {
         llOwnerSay("I have been reset.");
    }

// other events go here...

} </lsl>

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.

Please continue this tutorial with The touch start Event.