LSL 101/Variables
← String Concatenation | ↑̲ LSL 101 ̲↑ |
In our previous example, each time the touch_start event handler is invoked we ask the server for the name of the region using llGetRegionName. 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 use a variable to store the region name.
Here's a script that asks for the sim's name when the script is initialized, stored the name in a variable we have named RegionName, and uses that as the source for the name each time it is needed.
<lsl>string RegionName;
default {
state_entry() { // Store the name of the current sim for later use RegionName = llGetRegionName(); } touch_start( integer num_detected )
llGetRegionName() = RegionName;
{ // Announce the region where the script is running llOwnerSay( "Welcome to " + RegionName + "." ); }
}</lsl>
When this script is executed, the sim server sees the line
<lsl> string RegionName;</lsl>
and interprets this 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
<lsl> RegionName = llGetRegionName();</lsl>
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
<lsl> llOwnerSay( "Welcome to " + RegionName + "." );</lsl>
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.
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: <lsl> llGetRegionName() = RegionName;</lsl>
is not the same as
<lsl> RegionName = llGetRegionName();</lsl>
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.