Babbage finally blogs about script limits

Collars don't generally seem to be too bad (10-20 scripts), but the average cuffs set seems to be around 100-200 scripts .

---

At the same time LL has been slacking in doing (little) things that would have relieved common script load as well:
- flight assist: people might still wear it for the boost but for the most part you need one to not plunge down if you end up in the air above 200m
- AO: can be integrated into the viewer but ideally it would be implemented on the sim since half of the anims are played sim side
- some changes to the Edit window to make resizing easier
- viewer<->script communication for attachments
- viewer plugin architecture
etc

If noone still needs a flight assist or AO and if things like a radar can just be added to the (official) viewer with a plugin and HUDs can have most/all of their UI done client-side then those are improvements no amount of script limits would ever achieve (as far as avie attachments are concerned anyway).

Hard figures to go on aren't expected for a few more months yet, with several months following that for us to adjust to the new situation. Enforced limits aren't due for almost a year.

There are three issues script limits can address, i) number of scripts, ii) total memory used, iii) execution time. For one very specific purpose (memory swapping to disk) LL is currently addressing total memory with these, still very loosly-defined, script limits. So the answer to your second question *should* be 'the memory used by scripts'. Unfortunately EVERY script compiled in LSO takes 16k of memory and EVERY script compiled in Mono takes 64k. Until we get the ability to control how much memory Mono scripts use that means the answer in the first place will probably be 'the number of scripts'. ('Probably' because not even LL know how they want to do this yet).

For most people's experience of script lag the execution time is more important than memory-use as they won't often encounter the specific issue LL are addressing first. There's a simple reason for that - scripts 'do' more at some times than at others and no-one's agreed a fair definition of 'average execution time'. Good scripters will put in a 'touch to activate' before listening, for example, so most of the time their script is idle. When someone does activate it though the execution time increases dramatically, simply because it's "doing something".

As has been said elsewhere throughout this thread - and the whole debate on script limits - memory-caps, especially while we can't use less than 64k for each Mono script - is only part of the solution, but it is a necessary step. The per-avatar (attachments) and per-parcel (rezzed) limits seem a very sensible way to implement caps and I think Babbage and Kelly Linden are doing a good job of communicating with us. Let's hope "no suprises" continues

The reason I asked what the limits will be (number of scripts, etc.) is because with prims, a person has a hard number to go by (e.g. I need a bed but I only have 17 prims left to play with, and I want to keep a few for flowers.) The exact number of available prims is there to be seen, and the exact number of the bed's prims is also there to be seen.

If scripts are limited by the number of them, then the same would apply, and people could choose items according to the number of scripts in them and the number left available. Memory could also be worked like that. But if time when running comes into it, we could be shopping blind, not knowing what impact an item will have on our allowance.

I'm in favour of the limits - not because I want limits but because I want the tools to see how heavy or light a script is, in order to do something about it.

Hmmm. I checked an Amethyst collar; it came in around 20 scripts, as did a set of Amethyst cuffs. An OpenCollar was 29 scripts. Your alt must have much more elaborate cuffs than does mine.
I always have trouble getting myself to suspend disbelief that anybody would ever want avatar radar, but I guess it may as well be viewer-side for most people who do. It would be utterly useless to me because the only time I want to know about an agent with whom I'm not currently chatting is when I'm approving their interaction with a sim-side script.

I have much the same problem with viewer-side AOs--or would, if I could have an AO do what I actually want. There are huge inefficiencies with sim-side AOs, but at least they can interact with sim-side events without unsupported communications with an unsupported viewer function--all of which we fervently hope will soon be broken anyway, come Puppeteering.

Even if server-side AOs and flight assists and radars went away, however, they still total less than one collar (even one with only 18 scripts). Or to put it another way, it would take a sim full of avatars with viewer-side implementations of these functions to make up for one head of resize-scripted hair.

I think it's very unlikely we'll ever see a direct allocation of script runtime for avatars or parcels; just doing the quota accounting would cost more than the sim currently budgets for script processing itself.

On the plus side, memory limits indirectly control the number of scripts. Big, rarely-used scripts will account for more of one's script memory allocation than little ones that run all the time, so the correspondence with script execution time is doubly indirect--but still, all other things being equal, reducing the total script memory footprint will reduce the number of scripts and their execution time.

Unfortunately, there is one way in which all other things are systematically *not* equal: there is very often a trade-off between memory consumption and execution time for a script. A single data representation may be smaller, but require more time to process. I must say, however, that most scripts I've seen are far from needing to contend with that trade-off: rather, they could be improved in execution time *and* memory footprint, and usually with easy changes.

Yes... my alt has them... that's right!... *looks innocent *.

I just peeked at 3 sets which are probably most common:
#1: 190 scripts total - 0.7ms script time (idle)
#2: 298 scripts total - 1.2ms script time (idle)
#3: 294 scripts total - 1.3ms script time (idle)

Of course not everyone ends up wearing all attachments (#3 is a minimum of 6 attachments up to 13).

A lot of people seem to think that "alot" is a word.

Wow, someone's really messing up.

A single cuff needs one script per chain attachment, and one script per animated avatar. These functions could both be done by the same script, but it makes sense to partition them. Add another script for control, and that should be pretty much all you need. OK, another one for making your chatty bits tingle (ugh).

Oh, I forgot BLING! What self-respecting sex object could be without that!

This is a good example of why script memory limits will be a good thing.

actually, that brown dress... second fromm the right.. I would so wear. but without those silly flowers..

I do not personally script, I can alter them fine to fit my needs when gathered on the forums or in world but personally my brain hurts when I try. Nevre been a probramer rl so I have no real interest in LSL. I don't use them in my clothing attachments to much, a few exceptions are... hmm... bling.. (faints) for jewelry because some people honestly like a blingy (subtle) necklace earring etc... but maybe 10% of my jewelry has it... Anyhow, I dont see a need for scripts in clothing, it takes an extra minute to make a S M L skirt and package it into box.. No need for a 156 or more piece flexi skirt to have so much scripts. I understand a script must go into each piece... (however you will have to pry my BAX boots from my dying hands) I only use the color change feature..

Now yesterday I was in my shop and a lovely lady cam ein waring one of my outfits, I noticed the skirt back was not right and of course Iwanted to click on her and adjust it up a bit.... So, I got to rethinking resizer scripts at that point because sometiems its easer for people to click and go larger than to click and pull skirt up a bit..... I guess

How do you get those script times?

Oh. You meant the scripters.

Hey! In all this talk about the evils and virtues of resizer scripts, why didn't anybody mention the possibility of a helpful assistant doing the resizing (and other adjustments) while the item is worn by somebody else?

They actually come in handy. I run events and we like to get a list of people that attended to help with next year's PR. At one big event the object that was collecting names had a glitch before the data could be read. It was only by some grepping and deduping my mysti's messages that we were able to come up with a list.

Find a full sim with no avies, no prims, no scripts, no child agents, etc.

The script time (and count) will reflect only what you're wearing (scripts start getting throttled at some point though so the numbers on an empty sim won't match the pre/post delta on a sim that's already running a good number of scripts).

Or just go to a sim on which you're an estate manager (or know someone who is) and look at "Top Scripts" for your avie's name but that number always seems to fluctuate far too much to be reliable.

Easier said than done .

Mono is a rather big memory hog since every function is aligned on a 512-byte boundary and once you use more than one script you're wasting a not insignifcant amount of memory just to handle passing messages back and forth per script (not to mention needlessly triggering events in other scripts within the same prim).

Add in a dozen dialogs of options and RLV and it's really not that easy to keep things to 1 or even a handful of scripts so 10-30 isn't too surprising.

Mono should have just done away with small memory limits per script and dumped LSL by switching over to C# and let multiple source files be compiled into one "executable" block which would have solved the problem of having to duplicate a bunch of code per script.

Yeah, but 200?

This is news to me. Where did you get this?

/me was also wondering about that. And maybe a bit more detail on what the word 'functions' means in this context.

Well, sunofagun, it's true, as a quick test easily reveals.

Wow, that's a bummer, dude! Talk about encouraging bad programming!

A function is code like this:

integer foo(integer bar) {
return (bar - 1);
}

It's still called a "function" even if it doesn't return a value, even though in that case it's a misnomer.

Wow I'm going to need to become a genius to play in SL can someone point me in the direction of the Stephen Hawking or Albert Einstein avys please........(script efficient versions naturally)

Ok, that's what I thought. The bit I didn't get is how we know that's aligned on 512B boundaries. Does it also do that on event handlers and/or states? Does this mean we should favor a small number of large functions vs a large number of small ones?

Are L$ good when they are baked?





This has puzzled me for a long time. There are tons of builds higher than the 200m or whatever limit for flying w/out an assist of some sort. LL even changed the build height from 7xx to 4096 and yet they still have it coded such that you'll just hover or slowly fall if you try flying at that height. That just makes absolutely no sense at all.



OMG - another Pep alt has been found.






The flowers are sooooooooo what makes it, though

All I verified is that the smallest a function can be is 512 bytes, but that corroborates Kitty's claim.

Yes, it does mean we should avoid small functions. Which sucks big time.

I don't know whether it applies to states.

Nooooo!

I hope you never see vitriol spewing from my posts.

How???