Scripting | Ooze𓁟

Second Life provides a limited range of interactivity with objects by default, such as the ability to; pay, buy, open, move, and sit on them, as well as to have them play media. In order to produce more substantial interactivity in one’s objects they must be scripted. To this end Second Life includes a state oriented, event driven programming language known as Linden Scripting Language (LSL) which was created by Cory Ondrejka¹.

Scripting is something that most residents find daunting, and it is much easier to get started if you have some prior programming experience in a language such as C, Java or JavaScript. While there are freely available online resources that document LSL, these are inscrutable for those with no prior coding experience as they presume an understanding of basic programming concepts, such as functions, variables and loops.

LSL is syntactically similar to the C programming language, but unlike C programs, which have a defined point at which execution always commences when the program starts, LSL scripts consist of one or more states, each of which defines what the script will do when one or more events occur. There are thirty five possible events for different occurrences, e.g. when; an avatar touches an object, an object moves or collides with something, a timer elapses, or an avatar (or object) says something via Second Life’s chat system².

In the C programming language the ubiquitous Hello World program (the canonical most simple program that can produce some output, which is traditionally used as a first lesson in programming in any language, as it shows the basic syntax of the language) is:

#include <stdio.h>

int main()
{
  printf("Hello, World\n");
  return 0;
}

Each time the above program is run, it outputs the text ‘Hello, World’ to the screen. By comparison, the traditional ‘Hello Avatar’ script in LSL is:

default
{
  state_entry()
  {
    llSay(0, "Hello, Avatar!");
  }

  touch_start(integer total_number)
  {
    llSay(0, "Touched.");
  }
}

When this script is first saved or initialised, it will print the text ‘Hello, Avatar!’ in local chat, where any avatar within a twenty metre radius of the object to which this script is attached will see this message. Further, if any avatar touches the object to which this script is attached, it will print ‘Touched’ in local chat. The difference between the LSL example and the C example is that once the C program is run it immediately prints the text and then ends, while in the LSL example once the script is added to an object it sits in its default state waiting for an interaction to be initiated by an avatar before the output will occur. After this the script does not end, but rather returns to its default state waiting for another interaction.

LSL scripts are capable of a wide range of functionality. They can be used to manipulate the objects to which they are attached, e.g. changing the rotation angle, position, size or texture. Texture animation is possible, and scripts can also be used to create particle emitters, which are used for effects such as smoke or rain. The sending of messages to other objects, or to avatars, or speaking via the local chat channel is widely used, often in the form of greeters. These give messages to avatars, usually a welcome or an explanation of rules. Scripts can even send email messages and make requests to web servers outside of Second Life.

The detection of when an avatar sits on an object facilitates teleport functionality, as well as avatar animation. This latter feature is used in Second Life for the creation of poseballs or danceballs, small spheres that an avatar can sit on, or click, which animate the avatar. Another application is vehicles. LSL includes functions for making objects behave like various types of vehicle (car, plane, boat, etc.) so that when an avatar sits on a vehicle object, the arrow keys that usually control the avatar instead pilot the vehicle.

It is also possible to write LSL scripts that create self-replicating objects. For example Bourke³ used LSL to build 3D fractals, by writing a script that would rezz many spheres in a fractal pattern. This can be a powerful educational tool, but it has also seen abuse in the past, in the form of so called “grey goo” attacks⁴, where self-replicating objects overrun the landscape.

In the above mentioned Hello Avatar script, there is one state, named default. When in the default state, this script will respond to the state_entry and touch_start events. However, it is possible to define multiple states, with different event handlers. This is useful for scripting things like doors, where the states in the script naturally reflect the states of the inworld object. In the case of a door, these states would be defined as default (closed) and open, or perhaps; default (closed), opening, open and closing, for a slow-moving door. Cox and Crowther “are doubtful that the added complexity of state based processing is worth the effort”⁵, but the present author disagrees. States in LSL are used where one might be forced to use global variables and ‘if’ statements in other programming languages. This state-based syntax makes interactive scripts easier for the programmer to understand and debug, e.g. If my door is open, I can easily see it responds to these events.

Leave a Reply Cancel reply