From the Wyverns nest

Buildings Tools - LSL Editor

June 26th, 2008 Posted in Purple Wyvern Designs

Most of what I do involves scripting (aside from the odd animation or texture). There are many annoyances to a scripter, most of them in-world. In no sort of order these are:

1. Asset failed to compile/save (generally when the asset database is throwing a hissy fit)
2. SL ate the script
3. Finding scripts reverted in objects
4. Silly errors in scripts!
5. Script stopped running

Some of these just come down to doing things correctly and having patience (#3 is often down to taking an object back into inventory after modifying a contained script, before it has compiled and saved). However, trying to develop and debug scripts in-world can often be very time consuming. When SL is being laggy, often it takes some seconds for a script to compile, save and reset ready for testing.

One of the alternatives is to use an offline script development system. The one I use is LSLEditor which is an open source tool created by Alphons van der Heijden.

LSL Editor performs a number of functions, it has code completion and code tips (useful for if you can’t remember all the arguments to a function, or the exact name). It can check if your LSL is semantically correct and it has a debugger function. There is also a “Solution Explorer” which allows you to build a virtual object and test the interactions between multiple scripts.

Using LSL Editor

The easiest way to use LSL Editor is to just open it up and type your script directly in, check the syntax and transfer the script in-world. This does not use all the abilities of the tool, but this can still be a timesaver when SL is down and you still need to work on scripts. One point here, it’s important to maintain synchronisation between your in-world and out-world script library. There is nothing worse than not having the latest and greatest to hand when you want to do some development.

Debug It!

The debugger is probably the most useful feature of the tool. The ability to write some code and throw it into a debugger to work through your use cases and verify it behaves as expected. There are some limitations. The LSL Editor only provides scope to define a fairly simple object environment, if you need a complex scenario you have to test in-world. There is also no scope to view prim options such as colour or movement, you can however read these options being performed in the debug window.

In the basic debugger (not the Solution Explorer), there is also limited ability to interface with inventory. You can’t check inventory contents or read a notecard.  However, if you configure an object in the solution explorer, you can perform these options plus you can have multiple scripts in multiple objects.

The debugger is a pretty powerful tool and some basic tests can save a lot of time in-world. One of the nice features is that it does not constrain you in what you do to your script, for example you can send LSL events in any order (such as a detach before the attach) and watch the results.

It’s not Perfect!

LSL Editor does have areas where it differs from the in-world LSL compiler. The effect of this is that in some cases a script will behave differently from in-world.

One example is if you want to do a Switch statement. LSL does not support Switch, therefore you have to do it by:

// switching integer n
if (n == 0) {
    llOwnerSay("You typed zero.\n");
    jump break;
}
if (n ==3 || n == 5 || n ==7) {
    llOwnerSay("n is a prime number\n");
    jump break;
}
if (n == 2 || n == 4 || n == 6 || n == 8 ) {
    llOwnerSay("n is an even number\n");
    jump break;
}
if (n == 1 || n == 9 ) {
    llOwnerSay("n is a perfect square\n");
    jump break;
}
@break;

This will compile and debug in LSL Editor, but it will not work in-world. This is due to a bug in LSL in which you must have one jump target for every jump source (so you end up having break1, break2, break3, etc). This is a bug in LSL Editor because it does not contain the bugs that SL does!

LSLEditor also lets you do some silly things that the SL compiler seems much more strict on, such as integer number = (integer)(string) keyValue or for (integer n = 0; n < 10; n++). This can be a bad thing since only the really experienced instinctively avoid writing silly things into scripts.

There are a number of other issues with LSLEditor posted on the SecondLife Wiki, however it is always a good idea to check the details of the function you are using just in case there are any known quirks or bugs.

Other Options

There are other editors available, mostly those that provide code highlighting and tooltips, some provide semantic checkers as well. The full list can be found on the list of alternate editors on the LSL wiki. LSLEditor is unfortunately only available for MS Windows.

There was one other development tool which did catch my interest. I noticed there was a plug-in for the Eclipse framework called LSL-Plus. I’ve used Eclipse for C/C++ development and it is a very good tool. It still seems to be in Alpha development, so at some point I’ll give it a try and post some thoughts.

The Scores on the Doors are…

So, given my original list of annoyances:

1. Asset failed to compile/save (generally when asset database is throwing a hissy fit)
2. SL ate the script
3. Finding scripts reverted in objects
4. Silly errors in scripts!
5. Script stopped running

LSLEditor helps with (1) in that the server being slow doesn’t slow down development, and keeping a copy out of SL solves (2) as well. Going through a debug process will help keep down the number of bugs (4), but not completely prevent them due to the limitations of the tool.

Strange SL defects like finding a script has stopped or that it has reverted can’t be solved by the tool. Well 3 out of 5 ain’t bad.