Difference between revisions of "LSL 101/Using Variables"

From Second Life Wiki
Jump to navigation Jump to search
m (pesky links)
m (<lsl> tag to <source>)
 
(5 intermediate revisions by 3 users not shown)
Line 1: Line 1:
[[Category:LSL 101]]
[[Category:LSL 101]]
{{NavNextPrev|prev=Variables|next=Global vs Local Variables}}
{{NavNextPrev|prev=Integers|next=Global vs Local Variables}}
{{LSL Wikibook Index}}
{{LSL Wikibook Index}}


Line 7: Line 7:
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 example snippets:
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 example snippets:


<lsl>
<source lang="lsl2">
string myName;
string myName;
myName = "An Avatar";
myName = "An Avatar";
Line 14: Line 14:


string myName = "An Avatar";
string myName = "An Avatar";
</lsl>
</source>


Both work perfectly well.  You can define the variable either within the script ("local variable") or above the default which is called a "global variable" because it can be accessed by all regions of the script.   
Both work perfectly well.  You can define the variable either within the script ("local variable") or above the default which is called a "global variable" because it can be accessed by all regions of the script.   
Line 22: Line 22:
This script asks for the sim's name.  When the script initializes, it stores the name in a variable we have named ''RegionName'', and uses that as the source for the name each time it is needed, instead of asking the server for the same data over and over.   
This script asks for the sim's name.  When the script initializes, it stores the name in a variable we have named ''RegionName'', and uses that as the source for the name each time it is needed, instead of asking the server for the same data over and over.   


<lsl>string RegionName;
<source lang="lsl2">
string RegionName;


default
default
Line 33: Line 34:
     touch_start( integer num_detected )
     touch_start( integer num_detected )
     {
     {
           llSay( "Welcome to " + RegionName  + "." );// welcome someone to the sim
           llSay(0, "Welcome to " + RegionName  + "." );// welcome someone to the sim
     }
     }
}</lsl>
}</source>


The line  
The line  


<lsl> string RegionName;</lsl>
<source lang="lsl2"> string RegionName;</source>


is called a '''variable declaration'''.  When this script is executed, the sim server sees the declaration and interprets it as a command to set aside a small chunk of this script's available memory capable of holding a string.  It then names that chunk of memory ''RegionName''.  Henceforth, any time it sees the name ''RegionName'' in this script, it will know it is referring to this specific chunk of memory.
is called a '''variable declaration'''.  When this script is executed, the sim server sees the declaration and interprets it as a command to set aside a small chunk of this script's available memory capable of holding a string.  It then names that chunk of memory ''RegionName''.  Henceforth, any time it sees the name ''RegionName'' in this script, it will know it is referring to this specific chunk of memory.
Line 45: Line 46:
Next, the state_entry event handler will be executed, resulting in the execution of the line
Next, the state_entry event handler will be executed, resulting in the execution of the line


<lsl> RegionName = llGetRegionName();</lsl>
<source lang="lsl2"> RegionName = llGetRegionName();</source>


This will cause the string returned by ''llGetRegionName'' to be stored in that chunk of memory we have named ''RegionName''.  (This is actually an oversimplification of what really happens, but conceptually, it's an appropriate description.)   
This will cause the string returned by ''llGetRegionName'' to be stored in that chunk of memory we have named ''RegionName''.  (This is actually an oversimplification of what really happens, but conceptually, it's an appropriate description.)   
Line 53: Line 54:
Having stored the region name in memory, each execution of the line
Having stored the region name in memory, each execution of the line


<lsl> llOwnerSay( "Welcome to " + RegionName  + "." );</lsl>
<source lang="lsl2"> llOwnerSay( "Welcome to " + RegionName  + "." );</source>


will retrieve the region name from the script's memory instead of asking the sim each time.  Since reading from memory is faster than calling a built-in function, the script will use fewer server resources.
will retrieve the region name from the script's memory instead of asking the sim each time.  Since reading from memory is faster than calling a built-in function, the script will use fewer server resources.
Line 64: Line 65:


Example:
Example:
<lsl> llGetRegionName() = RegionName;</lsl>
<source lang="lsl2"> llGetRegionName() = RegionName;</source>


is not the same as
is not the same as


<lsl> RegionName = llGetRegionName();</lsl>
<source lang="lsl2"> RegionName = llGetRegionName();</source>


The first of these is not even a grammatical LSL statement.  Even if it were grammatical, it wouldn't make any sense.  The second statement is meaningful, and replaces whatever value is currently stored in ''RegionName'' with the string returned by ''llGetRegionName''
The first of these is not even a grammatical LSL statement.  Even if it were grammatical, it wouldn't make any sense.  The second statement is meaningful, and replaces whatever value is currently stored in ''RegionName'' with the string returned by ''llGetRegionName''


There ''is'' an equality operator in LSL, but it is written as == instead of =.  We'll talk about it in more depth later.
There ''is'' an equality operator in LSL, but it is written as == instead of = .  We'll talk about it in more depth later.


The variable ''RegionName'' in this example is called a '''global''' variable.  Global variables are are accessible to all event handlers in the script.  But not all variables are global.  
The variable ''RegionName'' in this example is called a '''global''' variable.  Global variables are are accessible to all event handlers in the script.  But not all variables are global.  


Please continue this tutorial with [[Global vs Local Variables]] or return to [[Variables]].
'''Please continue this tutorial with [[LSL 101/Global vs Local Variables |Global vs Local Variables]] or return to [[LSL 101/Integers|Integers]].'''

Latest revision as of 12:48, 24 January 2015

← Integers ↑̲  LSL 101  ̲↑ Global vs Local Variables →

Variables are declared by giving their type and a 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 example snippets:

string myName;
myName = "An Avatar";

// or

string myName = "An Avatar";

Both work perfectly well. You can define the variable either within the script ("local variable") or above the default which is called a "global variable" because it can be accessed by all regions of the script.

In the next example we use llGetRegionName() to find out where the object is located. If we know the object with the script isn't going to be moving between regions, we might like to get the region name from the server just once, and then reuse the name each time the object is clicked on. To do that, we need to declare a variable to store the region name.

This script asks for the sim's name. When the script initializes, it stores the name in a variable we have named RegionName, and uses that as the source for the name each time it is needed, instead of asking the server for the same data over and over.

string RegionName;

default
{
     state_entry()
     {
          RegionName = llGetRegionName();  // get and store the sim name
     }
 
     touch_start( integer num_detected )
     {
          llSay(0, "Welcome to " + RegionName  + "." );// welcome someone to the sim
     }
}

The line

 string RegionName;

is called a variable declaration. When this script is executed, the sim server sees the declaration and interprets it as a command to set aside a small chunk of this script's available memory capable of holding a string. It then names that chunk of memory RegionName. Henceforth, any time it sees the name RegionName in this script, it will know it is referring to this specific chunk of memory.

Next, the state_entry event handler will be executed, resulting in the execution of the line

 RegionName = llGetRegionName();

This will cause the string returned by llGetRegionName to be stored in that chunk of memory we have named RegionName. (This is actually an oversimplification of what really happens, but conceptually, it's an appropriate description.)

The = sign is called the assignment operator, and the statement as a whole is called an assignment statement. If you have need to say this line in English, you would say "RegionName is assigned the value returned by llGetRegionName" or "RegionName gets the value returned by llGetRegionName".

Having stored the region name in memory, each execution of the line

 llOwnerSay( "Welcome to " + RegionName  + "." );

will retrieve the region name from the script's memory instead of asking the sim each time. Since reading from memory is faster than calling a built-in function, the script will use fewer server resources.

It's worth mentioning that variables in LSL (and other programming languages) are different than the variables you learn about in high school algebra. In the context of an algebra problem, a variable represents a specific value, but what value is not known at the start of a problem. You solve the problem in order to determine what the value is. But even though it is called a variable, the value doesn't actually vary during the course of the problem. Instead it's called a variable because you can change the value of it, it is not fixed or constant.

In LSL, we can easily determine what value is stored in a variable, but that value may vary during the execution of the script. Each time an assignment statement for a variable is executed, the old value of the variable is replaced by the new value. (Of course, if the old value and the new value are identical, no net change will have occurred.)

Also, the assignment operator = doesn't mean the same thing as equals in algebra. Equality is symmetric. That is, if a = b, then b = a. But in LSL, the left and right hand side of the assignment play different roles. The right hand side can be any value, but the left hand side of the assignment has to be a variable, and refers to chunk of memory, not the value that is currently stored there. (The current value is irrelevant , since it overwritten by the assignment.)

Example:

 llGetRegionName() = RegionName;

is not the same as

 RegionName = llGetRegionName();

The first of these is not even a grammatical LSL statement. Even if it were grammatical, it wouldn't make any sense. The second statement is meaningful, and replaces whatever value is currently stored in RegionName with the string returned by llGetRegionName

There is an equality operator in LSL, but it is written as == instead of = . We'll talk about it in more depth later.

The variable RegionName in this example is called a global variable. Global variables are are accessible to all event handlers in the script. But not all variables are global.

Please continue this tutorial with Global vs Local Variables or return to Integers.