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.
- 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:
- It gives an incorrect impression that Mono is actually more resource-hungry than LSL
- 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.