Scripting - making the world interactive

Although many pontificate about what makes Second Life™ compelling, one of the elements that certainly helps is that there is a potentially huge degree of interaction with the environment. Although there are limited ways to interact with the environment without scripting (you can sit on an unscripted prim for example) the ability to add scripts and control the interactions helps keep interest and engage and immerse the users.

The scripting environment is currently changing: Mono has just been rolled out server side and the soon-to-released Release Candidate for the new viewer will contain the ability to compile under both the current virtual machine or Mono as well as adding a couple of new functions to the library that will revolutionise making buttons and interfaces. How long it will be before that becomes the mainstream viewer is uncertain: the 1.20 client that is the main client now was released and tested as the RC for about six months but prior to this many have been tested and distributed within weeks.

It is thought that Mono will, eventually, allow scripting in a variety of languages, but for the moment it is only the Linden Scripting Language lsl that is available.

LSL is an event driven language. It lacks a number of features that depending on your programming background will affect you to a lesser or greater degree. These lacks include:

These limits affect your programming no doubt, but despite these limits a huge range of things can be done in LSL. As with so many things the ingenuity of the programmer is the main limit. There are, under the current model, two more serious limitations:

  1. No multithreading - this makes sense when you realise that the sim multithreads all of the scripts currently active in it, allowing each script to multithread would enormously increase the load. You can work around this with multiple scripts and link messages.
  2. Limited memory space per script. Under the current regime there is a 16kB limit to memory. This is increasing to 64kB under Mono, but the Mono processing takes about 4X the memory capacity so this is probably only of marginal benefit.

How a script works

This is not going to be a hugely technical discussion in terms of clock-cycles and the like: it is intended to explain to the non-specialist a bit about how the scripts, sims and avatars interact which can provide a tool for the scripters to tackle their problems, and some ideas for those asking for scripts about how they might be asked to describe their needs and why.

Each active script runs on the server for the sim it is in. If you are in the sim "Io" it runs on that server, if you are in the sim "University of Nottingham" it runs on that server. It doesn't matter whether it is in an attachment (i.e. worn on an avatar) or in a rezzed prim in world. In order for a script to be working it MUST be in a prim and it must be rezzed in world. Attachments, and vehicles, in the process of crossing between sims go through a hand-over procedure. This is of variable smoothness, although it has been better recently, but it is part of the reason why vehicles are not hugely popular in Second Life.

What the sim does, in very anthropomorphic terms, is maintain a list of scripted objects and their active events (events can be made inactive by changing state or stopping a script running). When something happens to trigger an event on the list, the code within the event is run, top to bottom, and then the script goes back to waiting for a trigger to be received and processed. The situation is a little more complex: if whilst processing one event the trigger for another event is received the triggers enters a queue. This queue is normally 64 items long, but certain events (collision* events for example) have shorter queues (8 items).

Each event may have 0, 1 or more pieces of information associated with it. You, as a scripter, have no control over what these pieces of information are, you must provide the tools for the event to assign all of them to variables in the event declaration. In many circumstances you will not use all of the variables provided, but they must still be assigned. Whilst their types and order is fixed, you can, of course, use any legal variable names you like for the variables. These variables are all local to the scope of the event.

Scripting and lag

Historically scripting was one of the biggest sources of lag in Second Life. About three years ago the processes were all changed internally and now script cycles are throttled to minimise the impact of scripts on lag. However, there is still a debt associated with scripts in terms of sim time so efficient scripting helps everyone.

There are no absolute red letter functions when it comes to scripting. However, there are a number where you should consider not using them if it can be avoided. These include:

It should be said I have scripts that use all of these functions in various different ways - sometimes there really is no option but to use them, but you should bear in mind that their use, particularly their excessive use, can cause problems with the sim running more slowly.

Lag and scripting

Lag in Second Life can (some would say often) result in messages arriving in a different order to the order in which they were sent. If the order is critical, it is worth coding numerical order indicators into the messages.

Particles

The particle system in Second Life creates sprites. These can cause client-side lag and may be turned off by the user.

Particles are used in a variety of ways - for example creating rain and weather effects, creating signs that always face the reader, creating haloes, creating things which chase the avatar or an object, or similar. There is, for example, a family of yachts in Second Life that use a particle streamer as a pennant (following wind direction is easy with particles) and a particle wake. They are also used in fountains to make sprays of water, to make fireworks and many more things.

Particles are not prims and have no effect on the prim limits on an island.

Particle code is an enormous list of flags and limits and although the coding is quite simple there is definitely an artistic element to getting the particles to do what you want. There is a freely available tutorial for particles including some scripts.

Avoiding the hair-pulling

The biggest, and on-going, pair of complaints about scripting in Second Life are lack of memory space and no ability to create and write notecards (which would reduce the impact of lack of memory).

The obvious solution is to make use of out-of-world storage. I prefer PHP and MySQL databases but any out-of-world process can be used. The llHTTPRequest system can send a well-formed message to a page of code and receive information back into Second Life. This can be used to send or receive data between Second Life and the outside world. At the moment this can only be initiated in-world. Both emails and XMLRPC can be initiated from outside SL and sent in-world at the moment. Neither service is entirely reliable, nor satisfactory. As part of the changes mentioned above, Linden Lab are discussing ways to implement HTTP requests to in-world objects. As always they have not released a timetable for this to be implemented, but it will come along soon and increase integration markedly.

Events don't always work as you might expect if you are used to other languages. For example in php the line:

$result = mysql_query( "SELECT * FROM table1");

will (assuming everything else is OK) return all the values from table1 in a database. The nearest equivalent in LSL:

result=llGetNotecardLine("notecard", 0);

will only get one line, and will return it via the dataserver event rather than assigning it to the variable result (which is actually the key of the query allowing you to sort queries if necessary).

Bear in mind as a scripter in Second Life, you will almost certainly have to have some level of skill with building and texturing too - because scripts only work in rezzed objects in world and can affect shape, texture, colour etc. of those shapes, you will end up learning enough about these areas to cope with that if not more. There are also things such as work-arounds for the lack of arbitary rotation axes that come from the building tricks repertorie. There are few or no scripters who make a living selling only their scripting experience and very few times where scripts are sold without an object in which they are used.

Each time you rez an object (or the sim is rebooted) the object will get a new key. If you are using the key as a target for llEmail or for security measures you need to be aware of this and determine some way to work around it.


I am not in any way affiliated with Linden Lab. This site advertises my work within their virtual environment. Valid CSS!

Valid XHTML 1.0 Transitional The terms Second Life, Linden Lab and SL are trademarks belonging to Linden Lab. No infringement of their trademark is intended. Usage here is nominative.

Home
Partnerships
Products
Projects
Resources


Index
Learner's Materials
1 Walking (etc.)
2 Talking (etc.)
3 Shopping (etc.)
4 Interacting
5 Searching
Teacher's Materials
1 Conduct
2 Good approaches
3 Poor approaches
4 Changes in approach
5 Assessment in SL
6 Assessing a project
7 Assessing learning
Specific Tutorials
1 Building
2 Int. Building
3 Camera Controls
4 Groups
5 Land
6 Limits of SL
7 Scripting
8 Textures


Join Second Life
Read my blog