Mastering Linden Scripting Language
LSL Script Anatomy
The Brain in the Box
Unlike a Python or C++ program that runs from a main function and then exits, a Linden Scripting Language (LSL) script is a persistent component living inside a 3D object. Think of it as a small, specialized brain embedded within a box, a chair, or a spaceship. This object, called a , is the script's entire world. The script doesn't execute from top to bottom; instead, it waits for things to happen.
This event-driven model is the core of LSL. The script is dormant until the virtual world—or a user—does something to its host object. A user clicking the prim, another object bumping into it, or a timer going off are all events. The script's job is to define handlers that react to these specific triggers.
The Default State
Every LSL script must contain at least one state block, and the entry point is always the default state. All execution begins here. A state is a self-contained collection of event handlers. When an event occurs, the simulator checks if the script's current state has a handler for that event. If it does, the code inside that handler runs.
// Global variables are declared here, outside any state.
integer click_count = 0;
default
{
// This event runs once when the script starts or is reset.
state_entry()
{
llSay(0, "Ready!");
}
// This event runs whenever a user clicks the object.
touch_start(integer total_number)
{
click_count++; // Increment the global variable
llSay(0, "I have been touched " + (string)click_count + " times.");
}
}
In this example, click_count is a global variable, accessible from any event handler within any state in the script. The default block defines the script's initial behavior. It contains two event handlers: state_entry() and touch_start().
The [{<state_entry>}] event is special. It fires exactly once when the script first enters that state, making it the perfect place for initialization code, like setting up variables or sending a greeting.
Similarly, a state_exit() event exists, which runs its code just before the script transitions to a new state. This is useful for cleanup tasks. You can define multiple states using the state keyword, allowing an object to have completely different behaviors depending on its current mode. For instance, a door might have open and closed states, each with different responses to being touched.
Preprocessing and Placement
Before your LSL code is compiled, it runs through the LSL Preprocessor. This is a simple tool that handles find-and-replace operations. It's not as sophisticated as a C preprocessor, as it doesn't handle macros or conditional compilation, but it's useful for defining constants.
#define GREETING "Hello, world!"
#define OWNER_KEY "your-uuid-here"
default
{
state_entry()
{
llSay(0, GREETING);
}
touch_start(integer num_detected)
{
if (llDetectedKey(0) == (key)OWNER_KEY)
{
llSay(0, "Welcome, owner!");
}
}
}
To get a script working, you place it inside an object's inventory. You create an object, edit it, and drag a new script from your personal inventory into the object's Contents tab. The moment the script is saved inside the prim, its default state is entered, and the state_entry() event fires. The script is now alive and waiting for events.
What is the fundamental execution model of a Linden Scripting Language (LSL) script?
Every LSL script must contain at least one state block. What is the name of the mandatory entry-point state?