This article, planned as the first in a series of articles, provides the vocabulary and background for the environment in which scripts are created and are run in Second Life™. This is essentially the context of scripts within the sim (simulator) software. The language in which Second Life scripts are written is called Linden Scripting Language, or LSL for short.
Scripts are a large part of what makes Second Life a dynamic, interactive environment. As examples, scripts can change an object’s properties, move objects, communicate with avatars or other scripts, sense objects or avatars, play sounds, collect information, play animations, and rez or give objects within the same object’s inventory to an avatar.
Scripting is not creating avatar animations or building/creating objects. Those are separate endeavors, often done in coordination with scripts to make them useful.
Part of the difficulties people have learning scripting are that scripting requires: attention to details, patience, and willingness to look at documentation and examples. Yet, taken in small steps that build upon each other, the skills to create useful scripts can be mastered. Many things in life do not require the level of preciseness that scripting requires, which is why programmers are notable both for their coffee consumption and for annoying others in general life by being “overly precise”.
You can create scripts within objects, within your personal inventory, or in an off-world editor. Scripts are run within objects that are either rezzed (created inworld) or worn as attachments to an avatar, the latter including heads-up displays (HUDs). You can create and save scripts within your own inventory, but you can’t run them from there. There is a default folder for storing scripts within your personal inventory, but you can store scripts under any appropriate folder.
To create scripts in personal inventory, right-click on a folder and selects ‘New Script’. To create a script in an object’s inventory, edit the object, go to the contents tab, and click on the ‘New Script’ button. The default script that is created can be gutted and replaced, either with a script typed in or cut and pasted in. Scripts can also be dragged and dropped between personal inventory and object inventories.
One caveat is that the check-boxes Running and Mono do not appear in the script editor for a script in your inventory. They have to be set when a script is edited while in an object’s inventory, and appear under the script itself. A script will retain its Running and Mono settings when dragged from an object into your inventory and dragged back into another object. Mono is a software platform for portable program development underlying the latest LSL implementation.
While humans can understand imprecision in how things are stated, scripting languages generally require precise syntax, syntax being how things are laid out and punctuated. If the syntax is correct, the script will save and run, but what it does may or may not be what is desired. Errors in scripts are referred to as bugs and going from the initial script to one that runs correctly, is known as debugging. The terminology stretches back to an actual bug found stuck in a computer relay in 1947.
There are a number of inworld scripting groups with people that can help you solve scripting problems.In seeking debugging help from such groups, you may be tempted to cut and paste scripts into group chat.Please don’t do that. It annoys people, which is not a good way to get their help.
Instead, cut and paste your script into Pastebin (or a similar service)
and share the link you are given in chat. Others can then view your script on the web. They can even give you a link with a corrected script.
Multiple scripts can be running within an object or linkset. They do not share memory, but can communicate with each other by sending messages. Linking joins two or more “prims” (primitive objects) together to form a single object. It is a single-level grouping; linksets cannot be nested; there are only a root prim and a set of child prims. Any linkset linked into a larger set loses its integrity.
Although LSL scripts run from within Second Life objects, LSL is not what is known as an object-oriented programming language. That’s a concept about how the handling of data is structured that is not part of LSL. LSL is an event-based. procedural language.
Being event-based means that the script is divided into separate sections that run when corresponding events occur.The separate sections are, unsurprisingly, called event-handlers. A script responds only to events for which it has an event-handler (in the current state). If no such events are occurring, a script is effectively idle, hanging out on a street corner hassling passers-by while waiting for something interesting to occur. Examples of events include: an object is rezzed, someone touches the object, an avatar or other object comes near or collides with the script’s object, the script “hears” a specific message, or a timer mark is reached.
Being procedural means that code is structured around calling functions, many of which are built into LSL, while others can be defined by the user. A list of the built-in functions can be found on the LSL portal, a primary reference document for scripting.
A script has to finish (i.e. return from) one event-handler before it can handle the next event in the event queue maintained by the sim. You can’t write a loop in an event-handler that waits for another event to happen. It will never occur. You have to return from the first event for the next event-handler to be invoked.
That covers the basics of the scripting environment in Second Life. The next article in this series will cover variables and the overall structure of scripts in Second Life. Thank you for your attention.
Caledon Oxbridge also has an inworld Basic Scripting class, Mondays at noon SLT in our main lecture hall. Please see our schedule page.
2 comments for “The Environment of LSL Scripting”