Linden Scripting Language – First impressions

After using Second Life for some time, I decided to take a look at the glue that makes things happen. By glue, I mean the scripting language, or more completely the Linden Scripting Language that allows your objects to interact with each other, yourself and other avatars/agents. Without the ability to script entities, SL would be a boring place indeed. Every time you touch an item, you are likely interacting with an automated piece of programming code that is designed to assist you (and sometimes not assist you depending on the author’s intentions) in doing things.

I have have quite a bit of experience in writing code; especially scripting using languages such as Perl, but also lower level languages such as Java and C. So I figured this couldn’t be too hard to learn. In fact it wasn’t too bad, however LSL does have some quirks about it, which I will discuss in this post.

Let’s first take a look at LSL syntactically. LSL has been described as a Java/C like language (Linden Scripting Language Guide). An example of a script is given below, reproduced from the Linden Scripting Language Guide.

default{    state_entry()

{

llSay(0, "Hello, Avatar!");

}    touch_start(integer total_number)

{

llSay(0, "Touched.");

}

}

LSL uses an interesting combination of Finite State Machine (FSM) and Event Driven programming paradigms. What are they you say? Well, take a look at the Linden Scripting Language Guide which explains the basics of these two concepts very well in the context of LSL.

Scripts are assigned to objects. An object can be a door, a house, a car, any physical (and sometimes non-physical) entity in Second Life. When the scripts are assigned to an object, they immediately commence execution. Often, but not always, there will be some initialisation code that set’s up the environment for the script (and object). The name of the function that is called when initialising an object is called state_entry as illustrated in the example. If not specified in the initialisation function, the object is said to be in the default state. Code and variables are lexically scoped within this state (using the language syntax). So there can be like named functions defined in more than one state. Only the version that is defined in the current state may be invoked. When changing to an alternate state, those functions may only be invoked. This allows your objects to behave differently, depending on the state they are in.

The language is compiled into a byte-code and interpreted/executed on the linden lab servers, not locally by the client. Given that a particular simulator can contain hundreds if not thousands of objects, each having their own scripts, things can get a little overloaded. Scripts have a limit of 16kB of memory, and there is no backing store. What I mean by this is that the current state and values of variables within a script remain in memory and is not saved back to disc. So if the simulator or script crashes, the data is lost. There are ways around this. For example, scripts can email data to their owners, or can write data to notecards. In fact, LSL can not write to notecards. Refer to slconceptual’s comments on this article. A notecard is basically a text file that is stored within an object. However, like the scripts, notecards too are limited in size. Unfortunately, the execution speed of scripts can be quite slow.

Another point worthy of mention is how the scripts/objects communicate with each other, or in computer science terms, how inter-process communication is conducted. Funnily, scripts/objects communicate with one another (and avatars for that matter too) via chat. What I mean to say is that the channels that are used by avatars to speak to a finite area of avatars (and objects) can be used by the scripts too. Although often, scripts will use different channels to those used by avatars. So what is a channel? You can think of a channel like a radio frequency as used by walkie-talkies (or whatever you call hand-held bi-directional radios in your country). You just have to tune in to a frequency to hear the conversation taking place and participate yourself if you wish. Channel 0 is like the public broadcasting channel that by default, all messages from avatars send on, and is readable by all within the vacinity. Ever gone to a club in SL, and had copious amounts of text sprayed at you asking for tips and so on. These are scripts assigned to objects that are communicating using channel 0. Have you also bought some object like a light-sabre that you issue commands to? You wear the light-sabre and then type “/ls on” to make it work (no I don’t have one – a friend showed me his :). Well your avatar is sending the text “/ls on” on channel 0, and the light-sabre which is in immediate vacinity is reading this. The script in the light-sabre will have a finite list of commands it will respond to, and only commands issued by its owner. Otherwise, a passer-by could instruct your light-sabre to give you or someone else a good wallop (hit, strike, upper-cut whatever the colloquial for your corner of the globe).

Objects however, will often use a higher numbered channel that is agreed upon by all objects that wish to communicate together. This approach is certainly insecure, as scripts can be written to scan all the channels listening for communication. But scripts can also decide who to take notice of and who not to (like the light-sabre). So, theoretically, it is not possible for someone to spoof their identity. In practice however, I wouldn’t bank on it. There is also support for rudimentary encryption in communication. Still mickey-mouse in terms of reliability/security.

There are other interesting aspects to this scripting language, but sadly (or perhaps for you gladly) I have run out of time. Might save further comments for another post.

In my next post, I hope to share some thoughts on how LSL and SL can be leveraged to improve/supplement Learning and Teaching. Watch this space.

Catch-ya later.