LSL 101/The Structure of a Script

← A Gentle Introduction

↑̲  LSL 101  ̲↑

Simple Script Skeleton →

---

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

The Structure of a Script

Here is the simplest possible valid LSL script. It doesn't actually ask the computer to do anything but all scripts have, at minimum, this structure:

<lsl> default {

    state_entry() 
    {
    }

} </lsl>

In order to explain even this short piece of code we need to introduce a few terms.

LSL scripts use states, events, functions and variables. We'll use this example to show how they work together and go into detail below.

We'll use comments (two forward // slashes) to talk inside the script. Anything on a line after // will not execute so you can leave yourself notes like this:

<lsl> default // this is the only *state* in this script { // opening bracket for default state

    state_entry()                      //  this is the only *event* in this script

    {                                  //  opening bracket for this *event*

      llOwnerSay("Hello, creator!");   //  this is the only *function* inside the event

    }                                  //  closing bracket for this *event*

} // closing bracket for default state </lsl>

Always formatting like this makes it a lot easier to read and debug your code later. There is no "right" or "wrong" in the actual arrangement of white space on the page, in fact, some scripters prefer a more compact style.

For more information on this section, please see

• Simple Script Skeleton
• Comments, White-space and Formatting

States

A State in LSL contains events which relate to each other. For example, cars can either be moving or stopped. When the car is in *state moving* it's going forward and when it's at rest it is in *state stopped*. There may be other states (*state reverse, *state stolen, *state wrecked, *state repaired) but *state moving* and *state stopped* are probably the most common states for a car!

All LSL scripts have at least one state: the default state. This is the state when no other states are active. You can see in the code above the word default is used to tell the script about what happens in the default state.

Here is an example of a script with two states:

<lsl> /* state */ default { // state_entry() // { // llOwnerSay("Entering state 'default'."); // }

   touch_start(integer num_detected)
   {
       llOwnerSay("Switching to 'state happy'.");

       state happy;
   }

// state_exit() // { // llOwnerSay("Leaving state 'default'."); // } }

state happy { // state_entry() // { // llOwnerSay("Entering 'state happy'."); // }

   touch_start(integer num_detected)
   {
       llOwnerSay("Switching to state 'default'.");

       state default;
   }

// state_exit() // { // llOwnerSay("Leaving 'state happy'."); // } } </lsl>

Notice the happy state needs the word state, so that the script knows this describes a state rather than something else. The default state does not need the word state in front of it because it is built into lsl and is required in every script. The reason you need the word state before happy is because this is a user-created state and you have to be specific or the server will not know your intent.

Next, notice the curly braces '{' and '}'. These tell the script which lines are part of the default state, which are part of the happy state, and which lines belong to the touch_start {event handlers}.

The tutorial continues with Simple Script Skeleton.