Linden Lab gives a heads up to scripters: Be efficient!

Many scripters may miss this news, as its put in with a blog entry dealing with Openspaces….. I don’t own an Openspace, but I have made a habit of glancing over any new Linden news release. Reading this article, I found out there is going to be some script limits put in place soon.

Script Limits: Scary Stuff ?

Nobody likes to hear of imposed limitations….. we already have our Prim Limits & Particle Limits, after all…..

Should we be crying for “Freedom” or “NO LIMITS – EXTREME”?

Jack Linden carefully explains why limits are necessary, and it makes sense, at least from my initial reading. Regardless, without a doubt, you’ll hear somebody or another panicking about this soon, at a sim near you….. Somebody will probably rant & threaten to leave SL forever because of this issue…… (I’d bet you 1 $L, if wagering wasn’t illegal in SL.) However, are script limits a bad thing? In my opinion, I think this is likely to be a good thing. Sensible limits are good. Keeping lag down – makes the Second Life experience more enjoyable for everyone.

Grid-Wide Script Limits?

On one point, I found the language used on the LL blog to be a little unclear:

To maintain the best performance for all our Residents, we recognize that script limits are necessary. This is especially true for those products like Homesteads and Openspaces where there are multiple regions sharing a CPU.

So, are we talking about a wider context here than just the Openspaces? Will all regions have some sort of limit imposed? Reading on, I got curious of other implications. Will the limits be per object or per region? Perhaps, us scripters will get some snazzy new performance monitoring tools? I hope so! Will there be Linden-provided efficiency training for the hopelessly inefficient scripter? Probably not!

I do hope the new limits are not too overly draconian….. Ahem…. Dear Lindens, please do leave the people enough room to have a sensibly-scripted animal, or two, running about here and there….. 😉

This move should be good though, as it will finally force all scripters to learn to write more efficiently & force users everywhere to abandon their horribly laggy scripted items for good.

Less lag everywhere soon….. HOORAY!….. I think….. o_O

So what exactly will Linden Lab do here? As a provider of scripted items, I’ll be paying close attention to this, and as always, look to write the least memory-consumptive scripts possible for my creations. We all have the most fun when we’re not lagging! 🙂


7 responses to “Linden Lab gives a heads up to scripters: Be efficient!

  1. Grid-wide script limits have been in discussion since before the OpenSpace sim debacle started.

    Five options for script controls were originally put forward, of which the least popular with those engaged in the discussions was to limit scripts in much the same way as prims are limited

    For example: each sim will get X scripts, so:

    – if you then parcel the sim in two individual parcels, each parcel will get 50% of X each;

    – if you parcel it into 4 lots, each parcel gets 25% of X

    – if you divide it into 8 parcels, each parcel gets 12.5% of the total script limit, etc.

    Thus, the smaller the parcel, the few prims AND the few scripts you can run.

    This is clearly a massive change to the manner in which people use SL, where the focus has always been on prim limits, not the number of active scripts running within a prim or group of prims.

    Needless to say, this is also the option LL most favour, despite clear concerns raised on the matter.

    Hence Jack’s comments about new tools to monitor script usage. At the moment it is impossible to tell how many scripts are actively running in a object (chair with poseball, sex bed, car, door, whatever), thus without such tools, it is impossible to tell if your next purchase will carry you over your “land limit”…

    For more details on the issue, suggest you visit:


    Here you will find a dump of an open discussion with Babbage on the subject, dated Nov 14th, and additional information on the earlier discussions held with LL, and concerns raised by scriptors, etc.

  2. Thank you very much for that information, Inara….. You are more up on this than me. I didn’t know limits were already mentioned, before this article. Anyone looking for more details, please follow Inara’s link……

  3. Neferon Nevadan

    I just see it as further evidence of Second Life in decline. I’ll handle the same way I handled the openspace/homestead matter – give up my holdings and not replace them. Eventually, I expect this to lead to Second Life quitting on me, rather than me getting mad and quitting Second Life. Not sure i care enough about Second Life to get mad at the Lindens any more – that might be their bigger issue.

  4. i like the idea of scripting limits but how wouldthey be implemented?

    if I am on a sim with 10 other people as land owners, and if neighbor “A” uses 90% of the script resources, what does that mean for us. it should definitely be on a per parcel basis, so that if i own half of a sim, then i get half the script limit

    that would work great for me because on the sims we own (like 10 or so after our OS conversion, ugh) we always have public space.

    what that means is that we always have open land and maybe reserve 2,000 prims for the estate (for butterflies and trees, and maybe even zombies). BUT . . . we don’t have very many scripts in that part which would mean that our sims would run better than others and help our business.

    my 2 cents and thanks for making me think about it 🙂

  5. I like this idea too. Properly implemented, it would be really great, and I see (especially, after reading the feed of Babbage Linden’s convo, kindly supplied by Inara) how its needed. I’d agree with you there…. per parcel limits are probably the best way to avoid resident disputes and abuse!

    Worst Case Scenario: For planning the future, its always good to imagine the worst (realistically) that could happen. In this case, that would be exceedingly aggressive implementation…… Many scripters of necessarily complex objects, would then end up having to take some items off the market (at least temporarily)….. For example, when an item suddenly no longer functions (or maybe can no longer even be rezzed) on a standard 512!

    That would be chaotic, both for the scripters, and for the users of their products.

    Rumor has it that Starax, with his famous magic wand, had to take his wand off the market permanently, once temp-prim limits were introduced. Purportedly, Starax could not see a way his wand could be redesigned (or perhaps didn’t wish to redesign it), after the limit was implemented.

    I imagine some of us scripters might have the (possibly daunting) task ahead of redesigning some of our more demanding items. If so, I am up to the challenge and will think flexibly of all options.

    In my opinion, such a scenario is the very worst that could happen, and that would not be so bad. From Babbage’s convo, I see how setting script limits will (seemingly contradictorily, I know) allow scripters more freedoms in the end, which is cool.

  6. Naked Bunny with a Whip

    They’re going to spend half a year figuring out how to limit script rather than making LSL more efficient? Once again, LL focuses on the wrong end of a problem. Imagine how much less script lag there could be if LL would just implement event-driven hooks for AOs to use, for example.

    Mono was a good start, and script limits aren’t a bad idea in principle, but they’re a bit like trying to cheer up a choking man rather than clearing the blockage.

  7. Pingback: Is that the sound of a shoe dropping…? « Living in the Modem World

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s