Long-delayed Second Life script-limitations back in the public eye

It's now just over one year since Linden Lab announced that they would be implementing a some manner of script limitations over and above those which are presently a part of Second Life as it stands today. It is just over eleven months since those limitations were rescheduled to go ahead in Q3 2009 – which time has definitely long passed.

Nevertheless, the script limitations system is alive and well and coming up, apparently in 2010. This constitutes good news, very good news and not so good news (in roughly that order).

Let's start with the good news.

At present, a Second Life simulator has a single-threaded object instantiation model. That is, when a new object is introduced to a simulator (by being rezzed from inventory, moved across a simulator border or brought in piggybacked on an avatar as an attachment) the entire simulator stops until the object loading is completed.

Of course, loading a bunch of prims is generally on the order of a few microseconds of work. Scripts, on the other hand, tend to add up.

Scripts under the LSL runtime engine are allowed up to 16K of code and data, while scripts under the Mono runtime engine are allowed up to 64K. Loading a script takes a lot longer than loading primwork, and is a task accomplished in milliseconds, not microseconds.

Did the whole sim just freeze for a second? Or two? Or three? Someone probably turned up with a prim wig with a bunch of resize scripts that required loading more than a megabyte of scripts all in one go. That can be more than one and a half megabytes of scripts and data that have to be loaded, handed to the runtime engine, their runtime states restored, and everything delicately handled so that they don't crash during the transition. All before the object load can be completed, and the simulator can go back to its normal work.

The very good news is that this has finally focused the Lab on a number of long-languishing feature requests for functions that render a lot of that scripting bloat unnecessary. Some scripts are certainly very poorly written and a significant amount of bloat comes from poor coding practices or knowledge. It seems that a rather larger portion has become simulator bloat simply because the language doesn't provide facilities to perform certain common tasks in any more efficient way.

The Lab's profiling has identified at least a few such functions, all of which seem to have been hanging around in feature-requests for months and years, and it looks like those will finally be making it into Second Life in the coming months. That will definitely make a lot of scripters happy.

The not so good news is that, after an indeterminate trial period where users will be able to see if their objects will break future limitations, objects that don't pass muster will be returned from the grid (or detached from avatars) and sent back to inventory automatically. Which is a reasonable method of handling things – assuming the creator of a non-compliant object is still around and willing to create and furnish you with an improved replacement model.

There's still quite a lot of unknowns about script limitations, including the suggestion that they may be grid-wide, rather than applying just to Openspaces/Homestead simulators; quite where the boundaries and limits will be; and really just how much content that it will affect – it could be a lot, or it might be hardly any.

This week has brought on intense speculation about the whole matter among Second Life users, and we're likely to see that continue until more information becomes available or something very distracting crops up.

	Are you a part of the most widely-known collaborative virtual environment or keeping a close eye on it? Massively's Second Life coverage keeps you in the loop.