The Linden Scripting Language (LSL) lets you add behaviors and interactivity to objects inside Second Life. Scripting is just another word for programming, so in learning about LSL you will end up learning about programming as well. Do not be afraid, though -- between this article and the many resources available both online and in-world, you'll be up and scripting in no time. You do not need to write scripts to have fun in Second Life, but scripting drives the magic, from vehicles and guns to vendors and HTTP requests.
This article walks you through creating your first script and covers the LSL syntax and more advanced language features. It also teaches you how LSL scripts can sense and communicate with the rest of SL, and how LSL can apply physical forces and move scripted objects onto your screen as heads-up display (HUD) attachments. Finally, it covers the many resources available for when you want to learn more.
The Origins of LSL
So, where did LSL come from? When Second Life was still called LindenWorld and had small space ships and eyeballs flying around instead of avatars, it did not have a scripting language. Instead, anything created in-world was built via static creations and physics. Thanks to rigid body dynamics, objects in Second Life act more or less like real-world objects, colliding with each other, falling under the effect of gravity, etc. This enabled a wide variety of creations, but many types were missing.
Take airplanes, for example. In a few more years (thanks to Moore's Law) we will be able to simulate a wing in real time, solving the many complex equations needed to properly model the interactions of the wing, turbulence, fluid flow, Bernoulli's Principle, etc. However, computers are not yet powerful enough to do that. So full simulation is not the answer. Instead, LSL allows residents to create content that can't be simulated currently within SL's physics system.
Technically, the scripting language that you will be playing with is LSL2, as the language added to LindenWorld in August of 2002 was LSL. However, since only a few early alpha users ever had to build using the original LSL, the current language is simply referred to as LSL. The current language is far more powerful and easier to use than the original, so be glad that you never had to play with the first one!
Your First Script
OK, so you are ready to take the first step. Great! Fire up Second Life and go somewhere you can build, such as a sandbox or land you own. Create a box on the ground and select it. Select the Content tab of the Build window and click on the New Script button. The Script Editing window will pop open with the default "Hello, Avatar!" script (Figure 8.1). We'll break down the script in a moment, but for now click the Save button on the lower right of the window. Two lines will appear in the bottom of the window -- first "Compile successful, saving..." and then "Save complete." The box then chats "Hello, Avatar!" at you. If you close the Build window and right-click on the box, the script will respond with "Touched."
Congratulations! You have created your first script within Second Life! So, what have you done? Let's break down the script. Right-click the box to pull up the pie menu and select Edit. Again, click on the Content tab. The box will now contain one item, called New Script. Double-clicking on New Script will reopen the Script Editing window. Now we can look at the script:
default
{
state_entry()
{
llSay(0, "Hello, Avatar!");
}
touch_start(integer total_number)
{
llSay(0, "Touched.");
}
}
Even if you've programmed before, few of the keywords will be familiar you to you, so let's break them down one at a time.
The keyword default indicates which state the LSL program will begin executing in. You will learn what states are and that LSL programs can have multiple states later in this article, but for now you need only know that every LSL program must have at least one state and that it is labeled default.
The curly braces, { and }, that follow default encapsulate the event handlers within that state -- in this case state_entry and touch_start. The state_entry event is triggered whenever execution enters that state, so in our example as soon as you clicked Save to upload the script to the simulator and attach it to the object the LSL program began to execute and entered the default state. This triggered the state_entry event, meaning that any code sitting within the state_entry was run.
In our example, the only code was the library function llSay. llSay allows a script to chat text, much like an avatar, onto a channel of its choosing. Channel 0 is the channel that all avatars chat onto and listen to, so by saying "Hello, Avatar!" onto channel 0, the script ensures that any avatars nearby can hear it. What llSay does is controlled by the arguments within the parenthesis that follow llSay, in this case the integer 0 and the string Hello, Avatar. We'll talk about arguments more later.
Of course, what if you forget what the arguments for llSay are? One option is to visit the LSL Wiki (http://lslwiki.com/lslwiki/wakka.php?wakka=HomePage) or search "llSay" on Google. Fortunately, there is an even easier way, which is to hover your cursor over the word "llSay" in the Script Editor window. This will pop up the following tooltip and remind you what llSay does and is looking for:
llSay(integer channel, string msg) Say msg on channel
The second event handler is touch_start. Recall that when we clicked on the box, it chatted "Touched." in response? This is what the touch_start event handler does. It is triggered when an avatar begins clicking on the object. Again, the only code that exists within the event handler is the llSay library function, which we covered a moment ago.
Now let's start making this script our own. If you don't have the Script Editor up, open it by selecting the box, going to the Contents tab, and double-clicking on New Script. Clicking anywhere within the window allows you to edit the text of the script, so go ahead and change "Avatar" in "Hello, Avatar!" to your name. For me, that would be, "Hello, Cory!" As soon as you change the text, the Save button lights up to indicate that the script in the text window does not match the script that has been loaded up to your box. Click the Save button to recompile and save the script.
You should see the same sequence of "Compile successful, saving..." and then "Save complete." displayed in the bottom of the editor and then the box should chat your name at you. Well done! But what if you wanted to go back to "Hello, Avatar!"? Fortunately, the text editor supports both undo and redo. Click in the text-editor window and hit Control-Z to undo your change. You'll see your name replaced by the text "Avatar" and the Save button lights up since the script has again changed. If you want to redo the changes, use Control-Y.
Remember that until you hit Save, your changes exist only in the text editor and haven't actually been uploaded into Second Life. When working on really complicated or critical scripts, it is often a good idea to use a text editor outside of SL and then cut and paste the text into SL, since that way you'll always have backups. The LSL Wiki has a list of external editors that have syntax highlighting for LSL (http://lslwiki.com/lslwiki/wakka.php?wakka=AlternativeEditors).
It is also important to realize that once you have added a script to an object, the script will remain on the object, even if you derez and rez the object into and out of your inventory. If you want to remove the script permanently, the best way is to delete it from the object's inventory.
To fully understand the connection between the text you type and what actually runs on Second Life, you need to dig a little deeper into LSL.
