Everything that happens inside your script happens during an “event”. No events, no action.
- Is your script doing something every so often?
It is using a “timer” event. - Is it doing something when someone touches it?
It is using a “touch_start” event, or one of a couple of other touch-related events. - Is it doing something when it hears someone or something speak?
It is using a “listen” event. - Is it doing something when it senses someone or something nearby?
It is using a “sensor” event.
There are more events than these. There are events when things “change”, events to help you read information from notecards or the web, events when the object is in a collision, events when an object gets an email, events when it gets where it’s going, and more. We’ll look at some of these in future articles. Here, we just want to get a little familiarity with the ideas.
In the forthcoming article, States, we’ll talk about another important LSL notion, the state. For now it’s enough to know that your script always has at least one state, the “default” state, and that when your script starts running it will be in the default state, and it will receive an event called “state_entry”. In the state_entry event, you have the chance to initialize your script. (This big word just means that you get to set things up to get started.) Let’s look at some simple examples. First, there is the default script that you get when you press the New Script button in your object’s Contents tab:
default {
state_entry() {
llSay(0, "Hello, Avatar!");
}
touch_start(integer number) {
llSay(0, "Touched!");
}
}
Your default script may look a little different from this. In particular, there will be more whitespace, with the opening curly braces on separate lines. The Rossini Standard is as shown here, because it lets us see more code at a glance — and because we like it. You should format your own scripts to your liking, and it is wise when working with someone else to come to a common agreement on format.
Anyway, what does this script mean? Well, remember that it starts in the default state, in the state_entry event. Inside that event we just see llSay(0, “Hello, Avatar!”);. llSay is the Linden Scripting Language function that speaks. In this case, the object will speak on channel 0 (zero), which is the regular chat channel. Objects can speak on other channels: we’ll talk about that in other articles.
So your object’s script starts out in default / state_entry. It says “Hello, Avatar!”, and that’s all. The event is over. The script is still running but it isn’t doing anything.
However, there is another event there, touch_start(). What about that? Nothing to it. If the state contains a touch_start, and someone touches the object (left clicks it), this event will occur. In this case, the object will say “Touched!” every time someone touches it.
You can test this if you like. Create a cube, edit it, go to the contents tab, and press New Script. The object will immediately say “Hello, Avatar!” and if you click out of the editor and touch the object, it will say “Touched!”. If you edit the object and open the script, you’ll see code much like what’s above.
Experiment, if you wish. Make your object say “Hello, Janet!” by editing that string. Make it say “Ow, that hurt!” when you touch it. To do those things, just edit the text and press the save button.
You may get an error message when you save. Like all programming languages, LSL is very picky about what you say to it. Each string must begin and end with a quote mark, each statement must end with a semicolon, and many other rules. If you get an error message, it can be best to use undo (control Z on a PC) to back your changes out until the script works again. Then make your changes a bit more carefully. (Of course if you see your mistake, as you will as you gain experience, just go ahead and fix it.)
So what we’ve seen here so far is that LSL is based on events, and that when events occur, your bits of script inside the corresponding event handlers will run.
Valkyrie Janet 