Difference between revisions of "LSL 101/Simple Script Skeleton"

From Second Life Wiki
Jump to navigation Jump to search
m (<lsl> tag to <source>)
 
(24 intermediate revisions by 5 users not shown)
Line 1: Line 1:
{{LSL Wikibook Index}}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:
[[Category:LSL 101]]
{{NavNextPrev|prev=The Structure of a Script|next=Comments, White-space and Formatting}}
{{LSL Wikibook Index}}
Here is an example of 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>
<source lang="lsl2">
default {
default  
     state_entry() {
{
     state_entry()  
    { // state_entry event handler goes here
     }
     }
}
}
</lsl>
</source>


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.
Looking at a script, the first thing you might notice is that the ratio of punctuation to words is quite high.  This is a general characteristic of LSL.  Along with parenthesis and curly braces, there will be lots of semicolons, quotation marks and square brackets, and it all has to be done just right.  Fortunately, the rules for using punctuation are much simpler than for a natural language.  So even though you are likely to struggle a lot with punctuation at the beginning, that phase won't last long.


LSL scripts use a concept called ''states'' and ''events''.
In addition to the punctuation, there are two "names" in this example, "default" and "state_entry".  In LSL, the underscore is not a punctuation mark, but one of the characters that can be used in names.  It's most often used to combine what might be multiple words in English into a single name, because LSL requires every name to be a single word.


'''States'''
Based on this example script snippet, you might guess that there is a recurring pattern of the form
 
<source lang="lsl2">
''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.
heading
 
{
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;
    }
}
}
</source>
in LSL, and you would be absolutely right.  Each one of these is called a <b>block</b>, and a large part of an LSL script is made up of blocks within blocks (within blocks ...).  Since getting the punctuation just right is mandatory, it is a good idea to vertically align opening and closing curly braces with their heading, and indent everything in between.


state hungry {
This is all grammar; what about the <u>meaning</u> of the two blocks?
    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>
 
We will discuss more about events but before we do, and in order to explain the code above, we need to introduce another concept: variables.
 
'''Variables'''
 
We said that the server can pass information about events and in our example above you can see that we refer to the different pieces of information by giving them different names: channel, name, id, message.  Not only are these separate pieces of information, they are different ''types'' of information: channel is a number, name is text, id is a special kind of number called a UUID key, message is text.
 
Variables, then, are declared by giving their type and their name. But variables would not be very useful if they did not also have a ''value''.  When we give a value to a variable it can be said we ''defined'' the variable.
 
Before you use a variable in LSL you ''must'' declare it and usually you will want to define it as well.  These can both be done on separate lines or on the same line of code. Here are two examples:
 
<lsl>
string myName;
myName = "An Avatar";
 
// or
 
string myName = "An Avatar";
</lsl>
 
So what different types of variables does LSL know about?
 
'''integer'''


Integers are numbers, but only a limited set of numbers.  Integers in LSL are any numbers between −2,147,483,648 and +2,147,483,647, so long as they are 'whole' numbers (that is, they don't have a decimal point, like 1.5).
The outermost block, with the heading <b>default</b> denotes something referred to as the <b>default state</b>.  States are a unique aspect of LSL, and we'll cover them later. But it will be easier to understand just how they work when you know more about other aspects of LSL.  So for now, you can regard the outer block to be just a grammatical structure that is required in all scripts.


integers are declared and defined like this
The inner block, headed by <b>state_entry()</b>, is an <b>event handler</b> block.  Unlike states, understanding events and event handlers is crucial from the very start.  In fact, if you happen to have had some prior experience with programming, it's <u>especially</u> important that you grok(understand) events, because unlike a traditional computer program, events occurring outside of your script determine when the various parts of your script get executed.


<lsl>
The state_entry event is a pretty simple one.  It occurs when the script first starts running.  Typically, this will be when you add a new script to a prim's inventory or save 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.
integer myNumber = 42;
</lsl>


'''float'''
'''Click on [[LSL_101/Comments, White-space and Formatting | Comments, White-space and Formatting]] to continue.'''

Latest revision as of 13:45, 24 January 2015

← The Structure of a Script ↑̲  LSL 101  ̲↑ Comments, White-space and Formatting →

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

default 
{
     state_entry() 
     { // state_entry event handler goes here
     }
}

Looking at a script, the first thing you might notice is that the ratio of punctuation to words is quite high. This is a general characteristic of LSL. Along with parenthesis and curly braces, there will be lots of semicolons, quotation marks and square brackets, and it all has to be done just right. Fortunately, the rules for using punctuation are much simpler than for a natural language. So even though you are likely to struggle a lot with punctuation at the beginning, that phase won't last long.

In addition to the punctuation, there are two "names" in this example, "default" and "state_entry". In LSL, the underscore is not a punctuation mark, but one of the characters that can be used in names. It's most often used to combine what might be multiple words in English into a single name, because LSL requires every name to be a single word.

Based on this example script snippet, you might guess that there is a recurring pattern of the form

heading
{
     ...
}

in LSL, and you would be absolutely right. Each one of these is called a block, and a large part of an LSL script is made up of blocks within blocks (within blocks ...). Since getting the punctuation just right is mandatory, it is a good idea to vertically align opening and closing curly braces with their heading, and indent everything in between.

This is all grammar; what about the meaning of the two blocks?

The outermost block, with the heading default denotes something referred to as the default state. States are a unique aspect of LSL, and we'll cover them later. But it will be easier to understand just how they work when you know more about other aspects of LSL. So for now, you can regard the outer block to be just a grammatical structure that is required in all scripts.

The inner block, headed by state_entry(), is an event handler block. Unlike states, understanding events and event handlers is crucial from the very start. In fact, if you happen to have had some prior experience with programming, it's especially important that you grok(understand) events, because unlike a traditional computer program, events occurring outside of your script determine when the various parts of your script get executed.

The state_entry event is a pretty simple one. It occurs when the script first starts running. Typically, this will be when you add a new script to a prim's inventory or save 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.

Click on Comments, White-space and Formatting to continue.