Non-LSL scripting


While I’m aware there are people who feel Linden™ Scripting Language (LSL) is the best thing since sliced bread (which, if you have a bread maker, is fairly damn awesome), I would tend to disagree. Given a medium that’s unlikely to come back and haunt me, I may even rant, but lets just say I feel it lacks some core language features such as error handling, complex data types (classes/structs) and library support. The Mono FAQ does reference writing scripts in non-LSL languages (search for “Will I be able to write scripts in languages besides LSL since Mono supports lots of languages?”), but doesn’t give much detail. I’ve been pestering Babbage Linden about this for a while now, and it’s becoming a recurring question at his office hours, so I’m going to wrap up what I know, here.

At the moment, LSL is uploaded to the simulator, where it is translated it into Common Intermediate Language (CIL), an assembly-like language that can be readily compiled into bytecode to run on Mono (or .Net) virtual machines. This is done on the server-side to ensure that dangerous/hostile code is not run by the server. While LSL is a safe language in that it lacks network/disk/etc. features to do real damage, CIL has no such constraints. Allowing CIL or bytecode uploads would theoretically allow a user to tell the server to wipe its own disks, for example. This is what we call a bad thing.

However, there are methods for allowing such code to be run without endangering the host system. Obvious examples include Javascript, Flash, Java and Silverlight (Microsoft’s equivalent of Flash). For the deeply techy, I know I mixed languages and file formats there, please just accept it. Silverlight is of particular interest, as it runs code under a .Net (same as Mono) virtual machine. In fact, the Mono project have their own version of the code needed for Silverlight, called Moonlight.

Moonlight 2.0 is the current major pre-requisite for non-LSL scripting. It’s due out in September 2009, at which point LL can start work on adapting its security controls for use with the SL™ simulators. C# scripting is likely to be first (although I’m hoping we’ll see bytecode upload so the geekier people can upload whatever we like).

So, what does non-LSL scripting mean for the average user? Well, hopefully more stable scripts. Right now, a lot of LSL can fail silently (meaning that the script has no indication of the failure, and in many cases neither does the user). Loading a notecard with a landmark in it, for example, will fail will no indication given to the script as to what’s happened, making it virtually impossible to provide help to the user.

Trying to do anything with complex data types is difficult and error prone. Lets say you wanted to store the name, key (UUID) and age of avatars you’ve seen recently (avatar age/height detector if you were wondering). In LSL, you can either have three lists (one containing keys, one containing names, one of ages) or one very long list containing all three items grouped together. If you have three lists, you need three commands to add data and three to remove. Use one big long list, and every time you access the data you have to remember which order you put them into the list. If you want to change the data later (say, to track inside leg measurement – yes, I’m being silly), you have to go over every bit of code and update it to know that there’s now four pieces of data for each avatar.

In comparison, in a language with complex data types you can put all four items into a class (or structure), and reference them by a meaningful name. Only one thing to add/remove to/from lists, and you can easily add new items because the language will track the details for you. Oh, and if you accidentally remove an item without fixing all the code that references it, the compiler will tell you at compile time. There are numerous other benefits of a more fully featured language, as well, but this is not the time or place for an exhuastive list.

We need your help, though. Firstly, the Moonlight project could do with your help testing their releases. Secondly,  we need to raise awareness that scripting is an issue that affects everyone. As much as the number of scripters may be relatively few, scripts are high impact. When someone clicks a door and it doesn’t open, it is jarring. When they pay a vendor and don’t get a product, it’s a serious deterrant from sticking with SL. Blog, tweet, plurk, and generally try to get the Lindens to understand that scripts are part of the user experience, and need some love too…

Comments are closed.