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

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 you to some terms that will probably be new to you.

LSL scripts use a concept called states and events.

States

State is actually a very good name for what states do in LSL. If you think of a car, it can either be moving or stopped. We can say its state is moving (when it is moving) and its state is stopped (when it is stopped). Another example is your own state of being: you can be awake, asleep, active, sitting, standing, hungry, bored, confused, etc.

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 with two states:

<lsl> default {

    state_entry() {
        llOwnerSay("Switching to the hungry state...");
        state hungry;
    }

}

state hungry {

   state_entry() {
       llOwnerSay("I am very hungry! Does anyone have any spam?");
   }

} </lsl>

The first thing to notice is that the hungry state needs the word state, so that the script knows this describes a state rather than something else. The default state does not need to be proceeded by the word state.

Next, notice the curly braces '{' and '}'. These tell the script which lines are part of the default state, which are part of the hungry state, and which belong to the state_entry() event handler, which we describe next.

Events

When something happens we can say an event has happened. LSL knows about many kinds of events and can respond to them depending on what kind of event happened.

LSL scripts don't run on your PC, they run on the server where the sim you are in is running. The server takes care of seeing when something changes - an avatar moves, you click something, the clock ticks, someone types something in text chat, you create an object, save a notecard, give someone a landmark, etc. - and it passes on information about those changes to the viewer running on your PC, which then displays those changes or shows a dialog or whatever is needed. The server also passes those events on to any scripts that have asked to know about that particular kind of event.

Your script can tell the server to inform it of events by including an event handler. In the example above we have added event handlers called state_entry(), which requires the server to tell it when the script enters that particular state. When the script receives the state_entry() event it runs the instructions inside the curly braces belonging to the state_entry() event handler.

Some events also pass information from the server; for instance the listen() event receives a channel number (to indicate which channel the chat was heard on), the name of the avatar or object that sent the chat, their (or its) UUID key, and the text of the message that was typed or sent. The listen() event handler is declared like this:

<lsl> listen(integer channel, string name, key id, string message) {

   // some actions to take when something is heard in text chat

} </lsl>