Moving towards script limits

Well, it took longer than originally planned, but server 1.38(.1) has rolled out onto the grid. With it comes new LSL extensions and (for those using Viewer 2.0 and its derivatives) the initial script management tools.

The latter take two forms: a breakdown of scripts running on a region (sim), and an Avatar’s personal script load; the former will only be visible to those “owning” land, or who are members of a group with land “ownership” (and then only on the land they “own”), while the latter should be available to anyone wherever they are in the grid.

Currently, both are limited in their meaning, because a) we don’t actually know what the overall limits are going to be for either in-world scripts or for the “pool” of resources to be allocated per server / sim to avatars; and b) the tools don’t accurately reflect Mono script usage – Mono scripts can utilise any amount of memory up to 64Kb (with the average apparently being around 9Kb), but only the 64Kb reserved for a Mono script (whether or not it is using less) is reported. Thus, Mono scripts currently appear to be hogging resources, when this may not be the case.

A further problem with the current tools is that, when looking at in-world script usage, they are simply too broad-based. Details can only be displayed for the entire region rather than for individual parcels. Hopefully, this will become more granular in the future, but for now it does possibly invite the kind of knee-jerk reaction the promotion of Avatar Rendering Costs created (albeit on a far smaller scale, given the limited access to script information), with people with access to the information screaming blue murder at the sim owner because a) the sim is laggy, and b) their neighbour is running XX “gigantic” scripts, and so must be responsible for the lag.

Access to the in-world script list is obtained by going to ABOUT LAND and then clicking on the SCRIPT INFO button in the GENERAL tab of the About Land pop-up.

Script Info - Land (note avatar names purposefully hidden to preserve individuals' privacy)

The list can be sorted in a number of ways – by script size or via avatars names (alphabetically ordered by first name, etc).

There are three buttons on the list – REFRESH – self-explanatory; HIGHLIGHT – which allows an object to be “red beamed”  after selecting it on the list, thus allowing its physical location to be confirmed) and RETURN – which allows an object highlighted in the list to be returned to the named owner’s inventory. In the case of this last item, I sincerely hope the functionality is restricted to SIM owners / Estate Managers, for obvious reasons.

At the top of the list is a small information area entitled “Parcel Script Memory” – possibly indicative that the display will be further refined to parcel level, rather than listing the contents of an entire sim. This section also gives a practical indication that script limits have not been set, as it will report that the sim is using XXXXXXXKb out of 0Kb.

For those who are not land “owners”, their personal script info can still be accessed through one of two ways: either via the SCRIPT INFO button in the GENERAL tab of ABOUT LAND, or via the SCRIPT INFO button that is displayed in the APPEARANCE editing window. Clicking on the MY AVATAR tab at the top of the script listing pop-up will then display the relevant information in both cases.

Avatar Script Info Display

At the moment, both displays are purely informational, and will have no real meaning until final limits for scripts are set by Linden Lab.  But the process has now started, and it is going to be interesting to see how things develop and whether LL stick to their promise of being open and communicative as further elements of this new policy are rolled out.

Scripts limits announced

Jack Linden – possibly as a part of his new role as Executive Director, Consumer Products today blogs about the upcoming server-side scripting limits.

These have been the source of much hype, debate, guesswork and outright misinformation (not, I hasten to add, from Linden Lab) for a while now; while it is still somewhat early days, Jack’s post is welcome as it does much to set out LL’s table on the matter, and start the flow of information very positively – allowing for the fact that much still appears to be in a state of flux.

Of course, there are concerns with the approach. While scripting limits are perfectly acceptable and may well help improve sim performance on overworked servers (allowing for the virtual nature of sims themselves), the planned roll-out of the new controls does lend itself to a lot of potential misunderstandings and confusion. In this respect, I certainly hope that Jack and the team keep Phase 1 of the project – Information – uppermost in their minds.

In summary:

• Linden Lab will be rolling out the project in three broad phases: Information – and Jack’s post can in some ways be seen as the first post in this effort, even though there have been earlier general postings on the subject by the likes of Babbage Linden; Tools – see below; and Enforcement
• Server 1.38, due out in April will start the ball rolling with the release of script monitoring tools
• Said tools will allow script usage to be monitored on a per parcel basis but the parcel “owner” / renter; additional tools will be provided to the sim owner / estate managers which will enable the return of objects that are taxing the sim in terms of script loads
• Script “space” in memory will be assigned to sims in a similar manner to prims: there will be a total limit for the sim as a whole, which can then be allocated to parcels as the land is divided up.
• Additional script space will be allocated per avatar, with an overall “pool” of resources per sim to handle avatars
• While Jack’s post does not make this entirely clear, it appears that if the script limit for a parcel / sim is reached, additional scripted items will not work; similarly, if all resources for avatars is used, additional avatars entering the parcel / sim will find attachments do not work.

Many have debated the pros and cons of capping scripts, but the fact remains, whether we like it or not, the servers supporting Second Life all have finite resources, and scripts have never really been monitored, and have become one of the causes of server-side lag, simply because of their overwhelming prevalence.

That said, Jack’s post does leave some cause for concern over potential angst / misunderstandings / over-zealousness down the road:

• Currently, LSL scripts are capped at 16Kb, while  Mono scripts can use up to 64Kb (but can in theory be a lot smaller than this – the average being around 9Kb according to Jack)
• However, the new tools will initially only report on the maximum amount of memory a script can use. So, if you have four LSL scripts running, they’ll be reported as taking up 64Kb of memory. But…if you have 4 Mono scripts running, they’ll be recorded as taking up 256Kb of memory – even though the scripts may be a lot leaner than this
• The monitoring tools will be tweaked later in the year so that Mono scripts will be able to report their actual memory usage – but initially, only the maximum 64Kb per mono script will be reported
• The upshot of this is twofold:
  1. It gives an incorrect impression that Mono is actually more resource-hungry than LSL
  2. It runs the risk of having people single out Mono users unfairly on the basis that (whether or not parcel / sim script limits are being affected)  ”they are hogging resources” because their “script usage” is “higher” – much as we witnessed people getting all het up and shouting about ARC and lag…
• A third possible outcome of this is that when shopping (and assuming memory usage becomes a “feature” of vendors, people will opt for LSL-scripted items because they appear more memory-efficient

There are other concerns that have been raised – such as scripters being able to use the land tools to test the efficiency of their scripts (given than not all scripts own / rent land, but work in places like sandboxes where the tools – to be included on the About Land window – will not be available to them. However, it is probably this issue of actual versus perceived script efficiency that is liable to cause the greatest upset with this change, unless LL work very hard to fully and properly communicate this change to the community as a whole.

And while script limits may well be a good thing for SL overall (I’m hoping they will have the desired outcome as far as is reasonably possible) – we’ve been shown time and again that when it comes to proactive communications with residents, Linden Lab’s efforts seem to repeatedly fall far wide of the mark.