LSL 101/Strings and Simple Output

← Comments, White-space and Formatting

↑̲  LSL 101  ̲↑

The touch_start Event →

---

Here's our sample program, with a line added so that the script actually does something.

<lsl> default {

    state_entry()
    {
         // Let the object's owner know the script is working
         llOwnerSay( "Congratulations! Your script has started to execute." );
    }

} </lsl>

The line that starts with llOwnerSay is a statement that instructs the object containing the script to chat a text message that will only be seen by the object's owner. Since you will usually be scripting objects you own, this will generally be you. This is a convenient way to get information about what your script is doing, without spamming text chat to everyone around you. But if you have an occasion (and permission) to script someone else's object, you would want to use one of the other communication statements, which we'll discuss in due time.

Take a look at the punctuation in this line. Every statement in LSL must end with a semicolon. This is probably the easiest punctuation mark to overlook, but if it isn't there, your script isn't acceptable. Furthermore, the error message you get will probably puzzle you, because it will tell you the error is on the line following the missing semicolon, and it won't tell you that it is a semicolon that is missing. So work especially hard at remembering your semicolons.

The next set of punctuation marks to observe is the pair of double quote marks surrounding the text "Congratulations! Your script has started to execute.". Double quote marks always come in pairs, and they, together with whatever characters come between them, are called a string. Strings can contain any printable characters (although a few require a special trick). The most important use of strings is to display text in SL. The actual content of a string does not have any effect on how your script runs, unless you specifically write code to examine the string and take different actions depending on what the content is.

The final set of punctuation, the parentheses, are associated with the name llOwnerSay. llOwnerSay is our first example of a built-in function. Built-in functions always start with the lower case "ll" (for Linden Labs). A built-in function will typically tell the Second Life server to do something (like display text or change the position of a prim) or make a query about the SL world (such as what avatars are nearby). There are hundreds of different built-in functions. Once you get the basics of scripting down, most of your learning time will be spent finding out which built-in functions do what you want to do, along with the nitty-gritty of how they work. Fortunately, most scripts need only a handful of different functions, so you won't need to learn hundreds, or even tens, of built-in functions before you can write simple scripts.

The general pattern for using a built-in function is

   llXXX( parameter1, paramter2, ... )

where llXXX refers to any built-in function and the number of parameters is different for different built-in functions. For example, llOwnerSay always takes one parameter, and that parameter has to be a string. Commas separate parameters, so if there is only one parameter, no comma is needed (or allowed).

Now that we know how to make something visible happen in SL, let's add a second event handler.