Blogs - Newcomer Friendly

The first post in this series described how to create a script in Second Life. In this post, we'll show you how to place the script into an object in-world and get it running.

Deploying a Script

In order for a script to run it must be in an object; scripts can't run when they're in your inventory -- or when the object they're in is in your inventory, either, for that matter. So the first thing you need is an object to put your script into. Make sure you are somewhere where you have permission to create objects (you can use a sandbox if you don't own land). Then go into Build mode and rez a simple cube on the ground. In the build window you should see a tab named "Content"; click to select it. (You may have to click the button labeled "More..." first, to see the Content tab.) This shows the object inventory. Your personal inventory shows things you own; object inventory shows things the object contains.

Since it's a new object its inventory is empty, so there's nothing listed. To get your script running, just drag it from your inventory to the Contents folder in object inventory. That's it: your script is now running! In fact, when you do this, you should see a message in local chat something like, "Object: Hello Avatar!" That's the result of your script running.

While we're here, you should also notice, above the object inventory listing, a button labeled "New Script". If you click this, a new script will be created directly in the object's inventory (try it now if you like!) The advantage of creating scripts in your personal inventory first is ease of re-use: you can drag them into any object directly.

Script Anatomy

OK, so you've created a script and, now, got it running. You can see that it's running, because it made your object say hello. But how did it do that? What does all that stuff in the script edit window mean? Let's examine the basics.

Scripts are made up of various elements: variables and functions, states and event handlers, statements and expressions... These form the "syntax" of the LSL scripting language. We'll concentrate on the elements that are present in this script for now.

A state is a container for one or more event handlers. A script keeps track of what state it is currently in, and uses only the event handlers defined in that state. For example, if you were writing a script to control a door, you might have one state to describe how the door behaves when it's open, and another to describe how it behaves when closed. This script contains a single state, named "default", which must be present in every script. The state contains two event handlers, named "state_entry" and "touch_start".

An "event" is something that occurs in-world that a script can react to, and an event handler is the description of how to react when that event occurs. For example, when someone 'touches' the object this script is in, a touch_start event is generated. Second Life sees that the script has a touch_start event handler. and calls it. The code in the event handler tells Second Life how this script wants to react to that event (in this case, by chatting the message "Touched.")

There are a large number of different types of events that a script can react to. Some, like the touch_start event, occur as a result of things people do in-world. Some occur as a result of things the script itself does -- for example, a script can ask to be told after a certain amount of time has passed, in which case it will get a "timer" event, and react to it using a "timer" event handler. Some events can only be triggered by another script, and some can be triggered by both scripts and avatars. Finally, some events are triggered directly by Second Life as it runs a script. The other event handler in this script, named "state_entry", falls into this category. It's called when the default state is entered, which happens when the script starts running for the first time or is reset, or if the script explicitly switches itself to the default state from some other state.

A Pause For Breath

Phew! That's a lot of new concepts. You may be feeling a bit lost at this point, especially since we haven't even talked about how to make the script do what *you* want it to do yet... Don't worry, if you didn't understand the Script Anatomy section, don't worry about it for now. You can come back and review it at a later time if you need to. The next article will start providing some practical instruction, and we'll revisit states and events later as we need to make further use of them.