LSL 101/Variable Initialization

2009-06-03T05:15:29Z

Omei Turnbull:

[[Category:LSL 101]]
{{NavNextPrev|prev=Global vs Local Variables|next=Event Handler Parameters}}

When a variable declaration is executed, the variable always gets ''some'' initial value, whether or not our script specifies. This is called '''variable initialization''', and it deserves a little discussion of its own. So far, we have passed over this detail by always executing an assignment statement for the variable prior to using it. But consider this example.

<lsl>string RegionName; // This is a global variable

default
{
state_entry()
{
// Store the name of the current sim for later use
RegionName = llGetRegionName();
}

touch_start( integer num_detected )
{
// Announce the region where the script is running
string WelcomePhrase = "Welcome to " + RegionName + ".";
llOwnerSay( WelcomePhrase );
}
}</lsl>

The only difference between the previous example and this one is that we have replaced the two lines

<lsl> string WelcomePhrase
WelcomePhrase = "Welcome to " + RegionName + ".";</lsl>

with the single line

<lsl> string WelcomePhrase = "Welcome to " + RegionName + ".";</lsl>

The first version allocates the variable and initializes it with the string containing no characters (written as ""). Then, it updates the variable with the string "Welcome to Ganymede.".

The second version both declares the variable and initializes it with the value "Welcome to Ganymede." in the same statement. The syntax for this is easy to remember because it is written as though the declaration and assignment statements were rolled into one. But keep in mind that this is not simply another form of an assignment statement. For example, the following code fragment is '''not''' legal.

<lsl> string WelcomePhrase = "Welcome to " + RegionName;
string WelcomePhrase = WelcomePhrase + ".";</lsl>

It is not legal because the second statement is an attempt to declare a variable that already exists, and isn't allowed.

Any declaration of a local variable can be followed by the assignment symbol and an initialization expression that follows the same form as an assignment statement. As a matter of fact, providing an initial value is generally considered a good practice, and most example you see will probably do that.

However, the rules for initializing a ''global'' variable are different. Global variables can have a initializer, but it can only be a simple value. It can't be the result of a built-in function and can't have any operators. This, we could '''not''' change our global variable declaration to

<lsl>string RegionName = llGetRegionName(); // This is a global variable</lsl>

On the other hand, we could do this:

<lsl>string RegionName = "Region not known"; // This is a global variable</lsl>

Initializing global variables to a unique value like this has an advantage over letting it be compiled with the empty string. When testing your script, if the phrase "Region not known" appears in the output where you expected a region name, you'll immediately know that no assignment to that variable was ever executed. If, on the other hand, the region name was simply missing (i.e. the empty string), it might be less obvious where things went wrong.

Now that we're discussed local variables and initialization, we can explain [[LSL 101/Event Handler Parameters|event handler parameters]], which we put off explaining when they first appeared.

LSL 101/Variable Initialization

2009-06-03T04:57:19Z

Omei Turnbull:

2009-06-01T18:43:16Z

Omei Turnbull:

[[Category:LSL 101]]
{{NavNextPrev|prev=Variables|next=Variable Initialization}}

A variables whose declaration occurs before the word '''default''' is called a '''global''' variable. Global variables are accessible to all event handlers in the script. But consider this example

<lsl>string RegionName; // This is a global variable

default
{
state_entry()
{
// Store the name of the current sim for later use
RegionName = llGetRegionName();
}

touch_start( integer num_detected )
{
// Announce the region where the script is running
string WelcomePhrase;
WelcomePhrase = "Welcome to " + RegionName + ".";
llOwnerSay( WelcomePhrase );
}
}</lsl>

The only difference between this and the previous example is that we replaced the one line

<lsl> llOwnerSay( "Welcome to " + RegionName + ".");</lsl>

with the three lines

<lsl> string WelcomePhrase;
WelcomePhrase = "Welcome to " + RegionName + ".";
llOwnerSay( WelcomePhrase );</lsl>

This change doesn't change the result of the script. But it does break up the one slightly complex line into smaller pieces. In this case, the one line wasn't complex enough to cause a problem, but scripts that involve more computation can be much easier to read when the computation is broken up into smaller pieces. To do this, variables with meaningful names can be used to hold the intermediate results.

Let's walk through the execution of the touch_start handler. The first executable statement is the variable declaration

<lsl> string WelcomePhrase;</lsl>

This is called a '''local''' variable because its use is going to be restricted to this event handler. Just like the global variable ''RegionName'', the declaration causes the sim server to reserve a chunk of memory capable of storing a string and to give that chunk of memory the name ''WelcomePhrase''. What is different is that this declaration is executed each time the touch_start handler is executed, whereas the global declaration is only executed once.

The next line

<lsl> WelcomePhrase = "Welcome to " + RegionName + ".";</lsl>

is straighforward. It creates the string just as before, and then assigns the whole string to the variable ''WelcomePhrase''. The third line

<lsl> llOwnerSay( WelcomePhrase );</lsl>

retrieves the value stored in the variable ''WelcomePhrase'' and passes it to ''llOwnerSay''.

Note that if we really wanted to, we could break things up into even smaller pieces. Consider the following fragment.

<lsl> string WelcomePhrase;
WelcomePhrase = "Welcome to " + RegionName;
WelcomePhrase = WelcomePhrase + ".";
llOwnerSay( WelcomePhrase );</lsl>

This version breaks up the two string concatenations into two separate commands. The first assignment statement

<lsl> WelcomePhrase = "Welcome to " + RegionName;</lsl>

results in the variable ''WelcomePhrase'' holding the string "Welcome to Ganymede" (assuming that we're executing the script in Ganymede).

The second assignment statement

<lsl> WelcomePhrase = WelcomePhrase + ".";</lsl>

takes the current value of ''WelcomePhrase'', concatenates the "." and stores the new result back in the the variable ''WelcomePhrase''. This process of replacing the current value of a variable with a new one is called '''updating''' the variable.

Remember we said that memory was set aside for ''WelcomePhrase'' each time the touch_start handler is executed. You might think that this would slowly use up the memory that is available to the script. But this doesn't happen because at the end of the touch_start event handler, the sim "un-reserves" the memory, allowing it to be used again when it is needed for some other purpose.

It is preferable to use local variables instead of global variables any time a value doesn't need to be retained once the event handler completes. (The reserving and un-reserving of local variables happens so efficiently that it is not a significant contribution to the work the sim server has to perform.)

There are other variations on local variables that we will discuss as the need arises. But now is a good time to talk about [[Event Handler Parameters|event handler parameters]], which are another form of local variables.