Difference between revisions of "LSL 101/The Structure of a Script"

From Second Life Wiki
Jump to navigation Jump to search
m (editing)
Line 17: Line 17:
In order to explain even this short piece of code we need to introduce a few terms.
In order to explain even this short piece of code we need to introduce a few terms.


LSL scripts use ''states'' and ''events''.  We'll use them first, with this example and go into details just below.
LSL scripts use ''states'', ''events'', ''functions'' and ''variables''.  We'll use this example to show how they work together and go into details 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:
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:
Line 39: Line 39:
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.
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.


==States==
==[[State |States]]== [https://wiki.secondlife.com/wiki/State State]


''State'' is a very descriptive name for this part of the script. For example, cars can either be moving or stopped. When a car is moving we can say it is in *state moving* and when it's at rest it is in *state stopped*.  There may be other states (*state stolen, *state wrecked, *state repaired) but *state moving* and *state stopped* are probably the most common states for a car!   
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.
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.
Line 48: Line 48:


<lsl>
<lsl>
default  
default     // here's the default state
{
{
     touch_start(integer num)
     touch_start(integer num) // touch it to make it work
     {
     {
         llOwnerSay("I am in state default and switching now to state happy.");
         llOwnerSay("I am in state default and switching now to state happy.");
         state happy;   
// function llOwnerSay tells the owner the message and then
         state happy;  // switches the script to state happy
     }
     }
}
}


state happy  
state happy   // here's where state happy starts
{
{
     touch_start(integer num)
     touch_start(integer num) // touch again !!
     {
     {
         llOwnerSay("I was really in a happy state, but returning now to default.");
         llOwnerSay("I was really in a happy state, but returning now to default.");
// another message to the owner
         state default;  // this returns the script to the default state
         state default;  // this returns the script to the default state
     }
     }
Line 68: Line 70:
</lsl>
</lsl>


The first thing to notice is that 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 state created by the user and if you don't put it, the server will not know your intent.   
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 belong to the touch_start(integer) event handler, which is another common *event*.
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}.


==Events==
The tutorial continues with 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 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 require 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 other 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)
{
    // Can take action based on channel, name, id or message -- or all four!
}
</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).
 
integers are declared and defined like this
 
<lsl>
integer myNumber = 42;
</lsl>
 
You are used to using the decimal number system (called ''base 10''), where numbers are counted using the digits 0 to 9, but you should also know there are other number systems that can be used with LSL, such as hexadecimal (''base 16''), which uses digits 0 to 9 and letters A to F.  You don't need to know about the hexadecimal system to write scripts but you may well come across hexadecimal numbers if you are modifying scripts someone else has written and you may later find that there are some places where it makes sense to use hexadecimal numbers instead of decimals.
 
Hexadecimal numbers are written as in this example (which does exactly the same as the example above):
 
<lsl>
integer myNumber = 0x2a;
</lsl>
 
''2a in hexidecimal = 42 [(2 * 16) + 10 is the same as (4 * 10) + 2]''
 
A note to those who have used other programming languages before: LSL does not have a binary variable type.  TRUE and FALSE are stored using integers with TRUE having a value of 1 and FALSE having a value of 0. We will discuss this in more detail later.
 
===Float===
 
*See discussion page !!

Revision as of 16:45, 7 July 2012

← In the Beginning ↑̲  LSL 101  ̲↑ Simple Script Skeleton →

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

==States== State

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

<lsl> default // here's the default state { 

    touch_start(integer num)  // touch it to make it work
    {
        llOwnerSay("I am in state default and switching now to state happy.");

// function llOwnerSay tells the owner the message and then 

        state happy;  // switches the script to state happy
    }

}

state happy // here's where state happy starts { 

    touch_start(integer num) // touch again !!
    {
        llOwnerSay("I was really in a happy state, but returning now to default.");

// another message to the owner 

        state default;  // this returns the script to the default state
    }

} </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 Events.

Retrieved from "https://wiki.secondlife.com/w/index.php?title=LSL_101/The_Structure_of_a_Script&oldid=1170251"