Babbage finally blogs about script limits

....You get a "More Predictable Experience". (tm)

there are reasonable limits to hardware upgrades, and diminishing returns as you move up.... it sensible and cost effective to impose limits. however it's likely that it will reshape the way the platform is used, and plenty of people will not be happy. c'est la vie.

Right, but it's not partitioned: any one region can swamp the whole server with script memory requirements.

All scripts. If you turn off a script and then turn it back on, it's state is restored (unless it's been take to inventory, or the sim has reset -- which makes this useless). Yes, LSL scripts just use 16K.

I believe that when LL did the numbers, it wasn't that bad, but was significan; a much bigger chunk of the memory than they wanted. Even then, it wasn't causing thrashing on most systems, but was seriously thrashing some.

Only if it's not boxed. In any case, sellers will have to report the numbers.

I answered this already; please see my post above.

It may not be the biggest contributor to typical lag, but it's the
cause of the most serious cases, where a server is brought to its knees, down to just a couple FPS or worse. It's also one that can be addressed.

The issue here is "the tragedy of the commons". Since it's a 'free' resource, it gets used as though there were no consequences. Which causes the consequences.

The limits are intended to avoid the catastrophic cases. Hopefully that won't mean a dramatic change to the way we live, work, and play in SL. And it poses the possibility of a better SL experience.

Not for boxed content. In theory, right-click and edit could give you the scipt memory count too. Wouldn't that be ideal? Right next to the prim count.

It's a static number; it doesn't change based on what the scripts are doing at a given moment.

You will when limits kick in and customers realize that it's an issue.

We'll have to disagree on that, then. I'd rather we have the power than LL make some kind of judgement call. I can't imagine how they'd possibly make the call of what's too much memory for a given purpose. Far better for us to decide where we want to allocate our resources. Each property owner gets to choose for his property. And you have a limit for your avatar; you get to decide whether those 200 resize scripts on the hair you like is more important than your mystitool (or whatever).

The scripts inside it sure do make a huge difference in sim performance. Better to make that visible than to keep it obscured.

If the average resident doesn't buy the stuff, then the average creator will get the message.

No, they're a long way from implementing it.

I suspected that they did roll out one subtle change in how memory is handled, a change which is a precursor to being able to provide limits. They warned us well in advance that they'd be doing this, but it happened without notice on a particular server rollout. I mentioned it in the forums, but nobody saw what I had, and I guessed that I must have been mistaken somehow. That was a month or two ago.

Boo hisss
Script limits by memory AND execution time (when they can work out how to measure it) will be necessary in any environment with finite resources.
And yet ...
Mono moves forward ...
And we get the new llGetLink..() and llSetLink...() ...
And then Babbage says in Office Hours we aren't getting the tools to specify script size.

Want to know how much memory a script uses? 64k, if it's Mono.
Doesn't matter if it's written well or badly. Each Mono script is 'reserved' 64k. End of script-efficiency tools.
Oh - you might think that makes LSO-compiled scripts (16k) look even nicer. LL thought of that too - so they may apply a 'multiplier' to make them look worse, even though they're not.

So owners/customers will see (64k * number of Mono scripts) + ((say) 80k * number of LSO scripts).

At some later date we'll be able to dictate the memory a script uses, maybe

Ah well, at least it's one step in the right direction

Yeah, I found that pretty disappointing, too. It wouldn't be so bad if they could "fix" Mono so it behaved itself on sim crossings and TPs. As it is, though, it's almost always irresponsible to sell attachments or vehicles using Mono-compiled scripts--which means scripting to the actual 16K LSO limit, requiring more scripts, each with artificially inflated memory accounting.

A necessary change in grid management (memory limits) really should not be conflated with a phony incentive to reduce LL's maintenance efforts (LSO retirement).

The result will then be LL ignoring everyone while continuing the plan, maybe with a slight modification (their MO is to ask for more than they really want, then bargain down to what they want). People will move to emerald so they have built-in AOs, LL will completely fail to see why a third party browser is more popular with non-noobs than their own.

Lear, I can confirm something like this; it was a change in memory accounting around the October time frame. Bit me during a product roll out. It was a small change, enforcing the existing limit during a list transformation rather than just on the before and after states, but it pushed a script close to the edge over into stack/heap collision territory.

And that is different than their normal mode of operation how?

Thanks much, Lear, I've learned a lot. Yeah, my scenario was pretty extreme; but even if it were only 4GB per server, that's a big chunk of memory just for that one type of data, and one would expect to see the occasional server thrash. HOWEVER, it isn't so extreme that one couldn't throw RAM at it. Frankly, given the list of projects that LL should be working on, (even just in the scripting realm), if I were them I'd opt for some very high per-avatar limits (just to trim the REALLY absurd creators/customers), schedule RAM upgrades (which would improve performance overall), and leave it at that. LL is not cash-limited, but they are developer-limited.This would be insane. They could and should engineer their way through a transition away from the LSL compiler by providing better memory management for Mono. Is the only way to protest this "idea" to attend a Babbage office hour AT 4AM slt???

Thanks, nice to finally get some confirmation on that. I'm surprised I didn't hear an uproar; I would have expected it to break more content.

In my case, someone suggested a change for MLPV2 that allowed it to hold lots more poses. Pre Mono, I'd instituted using 4 lists rather than one to hold positions, simply to reduce the penalty for list appension (needing space for double the list size).

When Mono first came out, I tested the 4-list solution against a simpler single-list one and didn't see much difference, so I didn't change the code. I must have been mistaken, because later someone pointed out that it could hold far more poses using a single list. So, I tried it again, confirmed the report, and posted an update. The very next day, the update I'd posted no longer worked with existing configs (including my products, which I'd updated)! Thank goodness the interval was so short, so there weren't many problems caused. I reverted back and all was well.

I posted about it on these forums, but got very little feedback.

I was kind of annoyed that they'd roll out an important change without notifying us. But evidently (which mystifies me) it didn't affect much content.

Your non technical side is really showing through. SL was not designed to handle hair with 200 resize scripts in them. There are limitations, both hardware and software, that the system can handle. People complain that their avatar freezes for 20 seconds when they TP into a sim or cross a sim boarder. This is because computers are only so fast, and only have so much memory (beyond that, scripts must be cached to disk which greatly slows things down).

There are two things that need to be done.

1. More LSL functions to enable more efficient scripting.

For example, llGetLinkPrimitiveParams() is an upcoming function that will allow scripters to code multiple prim objects without having to drop a control script into every prim that has function. For example, I have a flip display board that has to have 11 scripts. With llGetLinkPrimitiveParams() I could reduce that count to 1. Also, hair resize scripts have to have a script in each prim so that a main script can tell each hair piece when and how much to scale. lLGetLinkPrimitiveParams() would allow all the resizing to happen within one script. The more link functions we get, the less scripts we need in other prims to do pretty basic stuff. Each LSL2 VM script requires 16k, and each mono script requires 8k minimum, up to 64k. Let's say someone has a 200 prim hair with 200 scripts in it, and let's assume it's compiled into mono. 8K x 200 = 1600k, or 1.6 megabytes of memory allocated for someone's hair. Alot of people are too stupid to delete those scripts after adjusting the size, so they walk around SL eating up 1.6 megabytes of memory in the simulator they're in for absolutely nothing. Multiply that by 20 or 30 avatars in a sim and you wind up eating ALOT of memory. And that along with other scripts in the sim can really lag down a sim. It has nothing to do with LL being too cheap to upgrade their hardware.

2. Smarter scripting

Alot of 'scripters', and I use that term loosely, aren't really scripters at all. They take various scripts that do one tiny little function, and drop them into a prim to build functionality by simply dropping in more scripts. For example, shoes with bling and a walking sound. Some builders who are not scripters will drop in a bling script, and then drop in a walking sound script. Both of those functions are extremely small, and would both fit well within the 8k minimum of a mono script, but, when you drop in two scripts, you're up to 16k, and two shoes, now 32k. On top of that some other 'real' scripters have no consideration for system resources. When it's YOUR memory and YOUR limitations, scripters will script more efficiently because they have to. With SL, there's never been any script limits so many scripters don't pay any attention to script efficiency.

Script limits will solve these problems. Content creators will, for the first time, have to pay attention to script efficiency, and will begin to code (or recode) their items to be more efficient. You'll begin to see things advertised as low cost (script-wise), so buyers can search and compare. Say you're looking for hair. Are you going to buy the 1 script resize hair, or are you going to buy the hair with 200 scripts in it when you (the non techy shopper) are forced to comply with script limitations.

In conclusion, script limits are a good thing, it will improve SL while at the same time, no one will have to 'give up' anything. Over time, items will be scripted efficiently, and SL will be a better place because of it. I think everyone's all scared because they fear these limitations will limit what they can do. That's entirely not the case. Babbage has made it clear that not breaking current functionality is high on the list, but at the same time, the line must be drawn in the sand somewhere, sometime.

Things to expect:

Since the move to mono, SL's been supporting LSL2 VM, and mono. They wanted re-compile all LSL2 VM scripts to mono, but that's not possible. What does that mean for the non-techy? Well, if you have an older item, and the creator is not around to recompile it to mono, and/or, they no longer have the source code, then ultimately (probably within a year), that item is going to break. Support for two VM's is not going to be sustainable, so LSL VM 2's days are numbered, and all that stuff is going to ultimately break unless it's (possible) to re-compile it to mono.

Aside from that, for the non-techy, there won't be much difference. Content creators will be forced to go back and recompile, recode, and update their wares, and over time, SL scripts will become more efficient (partially thanks to new functions that will enable that), and no one will 'feel' any pain due to script limitations.

A huge part of the problem is there is no real tool that you can use currently to test your script's efficiency.

Sure, estate managers (but not us lowly not-EM coders) have access to top scripts and there are general guidelines you can follow (on-touch is MUCH better than listening on 0 for example). There just is no hard-and-fast measure of 'is this script more laggy than this other script?'.

As a general practice, I just follow rules of good programming (and turn my nose up at workarounds that do things like add a child prim with it's own script). I tend to be one of those programmers who do things like shaving off 4 bits by jumping into the middle of an assembly language instruction though.

I disagree slightly, whereas there is a need for education on scripts and preventing one person from hogging all the resources of a sim on their parcel, hardware upgrades would improve the user experience, there's no getting away from this.

If that weren't the case the people who said the 640K memory limit of DOS wasn't an issue and said that there was no issue with a 32MB partition because people would never fill 32MB of disk space would have been proven right, but they weren't right.

The way forward is hardware improvements and education on shared resources. Script limits alone will not make a noticeable difference to users and are only delaying the inevitable need for improved hardware.

However just improving the hardware won't deal with the shared resources issue, so this needs to be a two pronged issue.

Time to brush up on my scripting skills. Bet I could bake a lot of $L making scripts more memory efficient

When we see creators advertising their products as "Scripted by Screwtape Foulsbane for guaranteed efficiency and reliability" we'll know you've made it

unfortunately the average user isn't going to know a difference... many of the tricks to reduce memory are actually removals of the tricks to make things work faster. some of the new functions will help, but expect slowdowns in the movement of object that physically change. (eventually I will be vindicated in using micro optimizations everywhere.)

I will work for L$ to help people script more efficiently

Alot of content creators mistakingly believe that "no mod" is able to stop copying and put in sizing scripts to try and compensate for not selling their things "mod".

Script limits do nothing to change that, that problem is still going to exist after they're introduced. The situation will be better than it was before but it's still a script that's only there due to ignorance or mis/disinformation (if it's mod *and* uses a resize scripts for people who can't use Edit then that's different).

Once again script limits won't stop this from happening because the impact will be too small to make any difference for just that item.

If people end up wearing a dozen of those attachments at the same time then they might run into difficult but then one who'll get blamed is LL because it works just fine with different combinations.

People will buy the hair that looks best to them. If that's the 200 scripts hair then that's what they'll buy and once again it'll be LL that gets the blame from the average person when it can't be worn with anything else (or hardly anything else).

---

Farfetched example but you don't get lower emission cars just because manufacturers suddenly saw the light and repented but because they're either forced to themselves, or because consumers are either steered towards low emission (with a tax advantage or subsidy) or punished for higher emission (higher taxes).

You're expecting everyone who sells scripted attachments to suddenly see the light when you already concede that a lot of those people barely even know what they're doing. They're not going to change their ways because LL isn't forcing them to at all if they're not *too* awful.

If - as a random example - someone can wear 9 scripted attachments all with a similar "load" but a 10th puts them over the top do you really expect the average resident to be able to know which item or items actually doesn't need the scripts inside of it or needs a script but wasn't put together efficiently?

There will be some change in marketing of scripted items that raises consciousness about script memory use. Savvy creators will hype the low memory consumption of their products. Customers will start to pay attention when they can see the memory statistics and determine on their own what's causing problems.

There will be sleaze, too. There are still scripts sold for their miraculous "no lag" property--after all, there are still people who've convinced themselves that they've invented perpetual motion--so it's inevitable that some script merchants will hype magical memory-reduction scripts, too, and newbies will buy them.

And yes, a lot of consumers will just ignore the whole thing. Most of them will be fine. Problems will only arise when they invest hundreds or thousands of L$s in a collar and shoes and hair that aren't scripted with attention to the limits. Most of the time they'll encounter the problem when they try to use the offending item, and they'll complain to the creator that their stuff doesn't work. The problem will arise when that memory hog just fits in the limit and then they add the little one-script attachment that puts them over the line. Creators can expect some pretty confusing support situations.

Has it been mentioned what the script limits will be - will they be the number of scripts, or the memory used by scripts? From this thread, I could guess that's it'll be the number of scripts. Would I be correct?

hell I already do that for free... (and I'm not alone)

Every system has to have hard limits to ensure it performs as expected even in worst case scenario, currently simulators allocate 20ms of time to script execution, i saw peoples that eat as much as HALF of it simply by being "there".

I feel these limitations will hit avatars harder than land simply because most of the landless peoples have compensated for years by walking around in outrageously complex avatars. Plus there is only so much you can do to eat script time on land (minus game systems).

There are a lot of way to optimize script use, the main one is to use less prims and more sculpts, if your scripted dog has it's head made of one prim instead of ten, making it move will only take one script, hell it might even have few enough prims to be animated from the main script using llSetLink..

Not sure if anyone has made this connection, although after seeing the above post ...my head went straight toooo putting Script limits and the NEW Linden Premier members estates...
https://blogs.secondlife.com/community/land/blog/2009/12/16/linden-home-beta-is-now-open
.. together, or is it just my paranoia kicking In.. I am Australain and .. well you's heard whats coming down the pipe line for US.. *chuckles softly*..

Enjoy the day .. Watchmakers of Industry

Oh and I love your creations .. man -O-man do I love your work..

Cheers and Beers Seath

Well I do it for free too, but it would be nice to make some money every once in awhile too.