Babbage finally blogs about script limits

I found Babbage's comment on the blog post to be very reassuring:

"Thanks for all of your feedback. I understand that the major concern here that your current legitimate usage of Second Life will be affected by script limits, this is very unlikely to be the case.

When we make script usage visible in the viewer I encourage you to use the new facilities to check your current usage against the proposed limits. In nearly all cases you will find that you are comfortably below the proposed limits. If not we will make sure that you have plenty of time to let us know and for us to either change the limits or help you find a way to bring yourself under the limits before they are enforced."

Which sounds like nothing is set in stone and there's going to be a sensible feedback process.

Hopefully the feedback process isn't limited to people on a mailing list (yuck!) or those who can attend Babbages 3AM office hours.

Kind of like the Adult continent changes "nothing set in stone and a sensible feedback process"


Kind of like the revamping of the forums into that new blog thingy "nothing set in stone and a sensible feedback process"


We've been promised that sooooo many times.

The problem with that is that it affects the other sims that are running on the same server.

I'm in favour of script limits as LL has described them. I hope they give us all the correct tools to check each script. If we are unable to see how each script performs it'll be no good.

Sorry, but this would work only if you owned all 4 regions on the same server, because memory is shared. Because of that, I doubt they'll provide the ability. I don't think they have a panel for server-wide control (like estate management, only higher level).

There's another way to look at this: it puts the power in the hands of the people, who will buy good stuff and toss out bad stuff -- just as we count prims today. A creator can make objects as primmy or as low prim as they want, and the market responds accordingly. There's no law against high prim stuff; you either have it in your budget or you don't. There's really no difference.

If LL tried to somehow punish bad scripters, we'd be stuck with their judgement methods and judgement calls. Is that what you'd want to see? o.O !!

No, the real disadvantage is that scripters will find themselves optimizing for low memory rather than low processing, since memory will be more measurable and on everyone's mind. It's always a hard balance to make, and this is likely to push it too far in one direction. Unfortunately, only those with estate management ability can see script time consumption per object. It would be best if parcel owners could see it too, and if there were good guidelines about script time usage per square meter.

Again, sorry, but what LL is doing is to make it possible to write efficient resize scripts.

They'll be implementing llGetLinkParams() (or whatever it's called). This is a very good thing, IMHO, even though I loathe no-mod content. This will be good for things other than resize scripts, too.

Interesting. I guess I have to get more educated. I've always assumed that the problem on sims with lots of scripts was CPU time rather than memory. If that were true, presumably the only sims that would impact other sims if their scripts were out of control would be homesteads/open space, yes? Since regular sims each run on a dedicated core, do they not?

Re: shared memory ... Do you mean that there is a single pool of script memory that is shared among all cores on a server, or are you referring to the complete system memory that is shared among all cores? Wouldn't script memory be a small portion of total shared memory, given that the server code, OS, etc. are all using that same system memory (depending on partitioning schemes)? I guess I've been thinking that thus one could allocate a fairly liberal pool of script memory to be managed for all sims on the server.

And I agree, no users will (or should) see utilization stats for more than individual sims.
.

It's both. However, the CPU time issue is a steady degradation, and doesn't affect physics. When too much script memory is used, it can cause "thrashing", which causes the system to be constantly swapping memory to disk and back. That slows down everything to a crawl. This is the particular problem that spurred these changes.

CPU is per-region; memory is per-system.

Do the math; with 64K per script and tens of thousands of scripts, it adds up.

I'm not exactly thrilled with the idea of a limit, but I'm giving Babbage the benefit of the doubt, because he was more honest with us than many Lindens on that blog have been.

Some things that will need to be addressed is what the limit is going to be and can adding new functions help?

Adding new functions will help a lot. 200-prim hair with one script is far better than with 200 scripts!

However, there will be bummers, like your favorite hair that has resize scripts that can't be removed and they're compiled Mono so it takes 12 MB of memory to no purpose, but there's nothing you can do about it unless the maker is kind enough to upgrade.

Yes but they run either 4 or 16 sims per system so memory per sim should be pretty easy to figure out...

Thanks much! If I may pick your brain a bit more, does the system reserve memory for all existing scripts, or just those which are active? And, 64K is for mono, yes? Don't LSL scripts just use 16K?

Here's a little math, just to avoid writing Christmas cards. I'm making a lot of assumptions, if you have the time I'd love to know which are wrong:

In TPing around and looking at sims a while ago, it seemed to me that 15K was a high number for the number of active scripts on an empty sim. Then add in 40 avatars each running 200 scripts each (yowsa!). Assume all the scripts are mono and unique (multiple instances of single mono scripts in a sim share memory, do they not?).

23K scripts, ~1.5GB memory. 4 such sims on a quadcore server would need 6GB; and presumably LL's populated quadcores with about 20GB, don't you think? Or is that out of line?

Yeah, but I can tell how many prims an item has before I buy it and make the decision as to whether it is worth it to me. I cannot tell how well the script in an item will run before I buy it and attempt to use it. So, I'll waste my money buying crap from hundreds of places before I manage to find the few that actually know wtf they are doing.

There's getting to be too much thinking involved to use SL.

No shit. I do not want to have to spend all my time doing math calcs just to get dressed and/or use objects.

This is good to know. For those applauding this, there's many others like myself who dread it. When your main activity in SL resolves around a very detailed script, entailing endless hours of work and money, and which provides endless hours of entertainment for a large group..Well, to hear any significant change to scripting makes our stomachs drop.

So it sounds like we will retain the ability to use our current script on the private full sims.

Unless of course, things go like with the initiation of Havok, in which the existing scripts simply stopped functioning.........deep breath......(forces the word "rewrite" out of his head...)

i allways thought script cpu time is responsible for slow/laggy sims

if LL would code an AO into the client, most lag problems would be solved after the majority replaced their old lag generator ao

same goes for radar stuff

and it would be soo easy! (copy/paste from emerald)

aos are evil!


i am no expert btw ^^
i just know that i stopped working on 2 projects i spent month with when they announced the limits last year, because i am sure they will break my work.
may have been the same time when i decided sl is not a platform for (my) busines, not sure, could have been the open sim fun, or adult continent joke too.

anyway, back to my half naked, heavily scripted, open sim loving, freebie fan alter ego, while i can

If this were true, when I'm logged in with Emerald, using the built-in AO, all those empty sims I visit shouldn't have any lag at all -- and that is definitely not the case.

maybe because those empty sims run on the same machine that hosts 15 packed os sims, each with 10-20 aos/scanners?

i know a bunch of sims that run with 45fps and 0.99 - 1.00 time dilation even with up to 40 (unscripted) avatars.

as i said i am not an expert, i just know that most aos poll every 0.2 seconds (some faster, some slower) what animation they need to play, and i´d call that a waste of cpu time

edit: i can write 5 line scripts that bring the sim to crawl, while i have 200 prim avatars with much over 500 scripts that do not slow the sim at all (talking about empty sims here, since it´s impossible in crowded places to find the source of slowdowns).

so i don´t really see a point in the proposed limits, maybe because i dont know too many laggy places

i just dont like that a load of prim animations made with stuff like puppeteer will be dead after that ...

edit 2:

dont get me wrong, i´d love to do some stuff, like prim animations in a single script, it just doesnt work atm (first set prim size for prim number 1, then rotation, then position ect, each with a delay, then go to prim number 2) i guess thats the problem with resize scripts everyone is talkin about now too.

i can´t say anything about that, i just hear "rumors" including stuff like "the server doesnt unload unused mono scripts until restart" which would solve a load of problems too

Everyone is talking as if scripts are THE CAUSE of lag............I don't think so. One of many contributors to the problem but not, by any stretch, the biggest cause. Any effort to get lag under control will entail much more than script limits. Things like textures containing alpha channels or simply to large.........going to limit that too? Too many prims in a build......how do you limit that? How about too many avatars in a single region? Mainland already has that set at 40..........going to reduce it further?

The lag problem will be with us for a long long time..........possibly for as long as SL exists. Limiting scripts or anything else only serves to throw feel good rules and policies at the problem...........and place the residents in a box that limits their abilities more than easing lag. The software running SL needs fixing along with more powerful hardware.......most of which has not been invented yet. This recent idea of Babbage's will do nothing for lag......but does give the perception that LL is doing something.

This will go the way of ARC. A source for disputes among the residents........arguments, spats, bannings, the whole nine yards.

Right-click and "Edit" will show you the prim count easily enough though.

If it's up to the seller to provide the information then they're only going to do that if it's in their best interest (and even then the numbers are likely to be the most optimistic, ie a resizer scripts when it's sitting there being idle rather than actually resizing) and I don't exactly see jewelry or hair vendors all rush to provide it either.

Residents as a group can't be trusted to use their best judgement so I would prefer to see LL force the creator to deliver better performing scripts as opposed to the "buy it and if it's no good then you can delete it" method.

For things like the mystitool that are primarily script driven you can have competition but if there's a hair with texture changing scripts in it then it doesn't really matter if another store uses a more performant script because it's the prim design that really matters in this case, not the scripts inside of it.

And by all means do force people to think about what scripted attachments they really need to be wearing but it misses addressing part of the problem because the overuse of scripts isn't entirely Average Resident's fault since a lot of the blame is with Average Creator as well.

Agreed and we're not going to notice much difference at all on the back of this move without hardware improvements, hardware improvements would be beneficial to all and we'd notice it, for a while at least. Script limits will not significantly improve the Second Life experience, however if done correctly they can be part of an improved experience, on their own they will not appear to do a fat lot.

actually it's not as dire as it sounds, except for those who can expect to lose the most from it. the rest of the grid will chug along, with a little less in it, and never notice the difference.


undoubtedly, some will. and some will give it up as the reward isn't worth the effort. I'm not suggesting that it'll wipe everyone of the board, just that it'll limit the field... in some instances that's a good thing for overall grid health... just not so much for creative critical mass.


no, but they ARE major sources of a specific kind of lag, causing unnecessary swap file usage which slows down all actions.

TBH I expect that Physics and Communications are actually the top lag producers in the sense of cpu time. and coms are more than just chat and IM's, it's also fetching assets and serving them out to avs on the region. so yeah, texture bloat and object figure into that to. do I think it'll be as useless as ARC? maybe, if they do as poor a job of calculating it as they did ARC. but I think there will be overall benefits too.

I assume they started doing this already as lately on my HS and other places as I get script alerts set to chat I have been seeing multipal errors, mostly from HUDS...

When our huds stop working ad we just standing around looking like a noob.... there will be an outcry of public feedback LL might not expect.

everything you do with interaction is controled by a script.. When you start taking away the ability to be interactive aND self expression.. welll

Sounds like LL needs to do more technical fixes to the server and the hardware ALONG with implementing some REASONABLE limits on excessive scripts (i.e. hundreds of scripts). If it is true that scripts are not being unloaded properly, or they aren't using techniques to reduce the memory used by "empty" scripts (smalls scripts; i.e. using compression techniques), then LL needs to get on the ball to optimize the server ends as well as maybe consider increasing the memory on servers in the future rather than relying on swap all the time.