Babbage finally blogs about script limits

Eh? I thought the only limit was one generator per prim and whatever the viewer was set to render client-side?

I think that the problem here is frequency... I can make a one or two prim emitter that will pretty much drown out any other emitters within view... being able to enforce reasonable caps on particle effects wouldn't be a bad thing overall. but it isn't so much a lag issue, it's mostly just an annoyance (you can mute particle sources)

The size of particles has nothing to do with what hppens server side.

This is the first I've heard of this. Particles are client side. All the server has to do is pass the parameters for each prim to the client -- just as it passes the other parameters like size, type, path cut, floating text, and textures. After that, it's all in the client. So is rotation for nonphysical objects. The rotation you see won't be synchronized to the rotation that others see.

This is news to me, Kara, too. There's nothing about it in the wiki at http://wiki.secondlife.com/wiki/LlParticleSystem or http://wiki.secondlife.com/wiki/Limits and I'm sure there's nothing about it at the Particle Lab, where I've spent a lot of time recently.

There's a limit -- set clientside by the user in edit-preferences-graphics-- to the number of particles your viewer will render, which means other people's particle systems can easily interfere with yours (sometimes making particle systems very difficult to debug) but I'm sure there's no allocation per sim. If there is, what do you say it is?

On the client side you are limited by whatever people have set for max particles. I was told there is also a server side limit too on a per sim basis. The discussion was in the context of allocating it on plot size, like with prims. I have since forgotten what it was though.

On the client side you are limited by whatever YOU have set for max particles. And all the particle sources in your draw distance will be affected by that number. That's why particle effects sometimes seem weak.

As for there being a server side limit. . .first I've ever heard of it.

The closest I heard was that someone claimed that particles use no server resources at all, and someone else countered that it takes CPU time and bandwidth to send the particle parameters. True, but considerably less than a single texture, though, and only temporarily, on rez or when the particle system parameters change.

*BUMP*

Head spinning reading this thread, but I do have a question/issue and am not even script smart enough to know how to word it right, hopefully someone will be able to decode my ignorance enough to know the answer (or to figure out the question for that matter). At Virtual Ability, some of our users, are blind. There is certain scripting they use, to navigate SL, because they cannot see the graphics. The scripts tell them things like, 'This is the chair, sit here'. Because they cannot read the pie menu that says that. These scripts are housed in differnt things, one of the most famous is the virtual guide dog, but there are other things, that help the blind to navigate also. Any idea how the new scripting limits will affect scripts of this nature? Or, having provided you with no specifics of the scripts involved (because I do not know them) can you not advise?

It's a bit difficult to say without knowing what the scripting is like but, off the top of my head, if whatever makes the chair say," This is the chair, sit here" is part of the chair's sit script already it's not going to make much difference. If, however, you've got two separate scripts in your chairs -- one ordinary sit script to handle the sit anim and another one to tell people where the chair is -- then you need to think about combining them.

That's because, at present, each separate script in a rezzed item grabs memory -- 16kb for LSO scripts and 64kb for mono -- whether the script actually needs it or not.

Treasure, are you sure these are sim-side scripts, not special features of a custom viewer?

Caveat: I don't know anything about what's going on there, and can't get in-world now to check what's at Virtual Ability, but I think if I were doing this, I'd use the information given to the viewer, for example the presence of a sit target or an active touch-handler in a prim, which information is not shared with in-world scripts in other prims.

On the other hand, if *all* the relevant items were scripted specially for such an application, then it would be quite feasible to locate them with in-world scripts--and not necessarily require high memory use on a parcel to do it. Assuming the guide dog is an attachment, however, whatever scripts it uses would count against the avatar limit, although it's tough to know how worried to be without knowing where those limits may be set. (You might be able to get an initial read on the size of the scripts, using an idle sim and comparing sim memory use with and without the attachment.)

Ok, this is helpful thanks I will pass it on. The guide dog is a Virtual Helping Hands thing, not Virtual Ability but the point is the same. There are other objects that do similar. For example: I had a gathering on my sim, and one of our blind members came over, prior to the gathering, so she could pinpoint where she would sit, once she came back for the gathering. I think she placed her object under a particular chair. (just a regular old chair, the chair itself has a sit script of course, which I don't believe is used in these situations, it is in the object itself, that the blind person has). That object directs them to where to sit. Oh I am abysmal at explaining this. What we're really wondering is if the new scripting limits will affect these people, negatively, that use a scripted object to navigate SL. I think you gave us some info here, thanks Qie.

I spent a little time in-world looking at the Virtual Guidedog and associated stuff, and indeed this is almost all based on in-world scripts. (The exceptions being a special screenreader that reads SL chat aloud, and a login program to get through the SL login screen, and apparently to rotate the avatar--something no script can do.)

It appears that the object placed on your land was an instance of the "Polo" half of the "Marco / Polo" system, which contains a tiny script and a notecard describing what can be done with that object, and to make it easy to find.

I'm not sure what went on to get the avatar to sit. A script can't make an avatar sit on an object, but it could move the avatar to a location and then play a sit animation on the avatar. The guidedog has some special sit animations inside, but I think they're invoked by the embedded AO, and I didn't find a command to invoke them while the avatar is actually standing. Anyway, that's all just trying to understand what's involved here.

The bad news is that the guidedog is positively bristling with scripts, so memory limits may entail some trimming. The good news is that the other objects (the cane and the ring) have many fewer scripts... and the even better news is that the extra ones in the dog would be mostly obviated by the extensions to LSL that are on Kelly's list as proposed efficiency improvements, pre limit enforcement. (The ones that will be easy to replace are things that hide and show the dog and its harness, etc., and that move the prims around: wag tail, make limbs move, etc.)

Once those are all gone, the thing shouldn't be much more of a memory hog than the collars discussed earlier.

I also suspect that many of the scripts could be combined to cut memory footprint. I couldn't tell whether they're currently compiled as LSL or Mono because they're no-mod (including what appears to be a derivative of the Franimation AO script--technically a GPL violation), but just judging by script names and overall functionality, they're likely pretty simple, individually. Because this is an attachment, TPs and border crossings would go much more smoothly if compiled as LSL, and each would probably fit comfortably within the 16K limit of LSL--as long as Babbage doesn't artificially inflate memory accounting for LSL-compiled scripts.

Longer term, I really think a custom viewer could be much more effective in making SL more accessible to the vision impaired, and the AI to make that easy to use would seem a much more interesting challenge than making boobs jiggle. But to be honest, I wouldn't advise anybody to work on the viewer source right now--and especially not interfacing with the UI controls--just as Viewer 2.0 is supposed to be released, with unknown changes to UI implementation and unknown source availability.

/me notices some updates to SVC-3895 from Babbage...

/me is cautiously optimistic.

/me too.

Fool me once, shame on you. Fool me 7 or more times, shame on me.

/me takes a "pics or it didn't happen" stance....

and why shouldn't I? it's what they expect for opening jira's, why should fixing them be any different?

THANK YOU FOR THIS> I am SICK of residents AND LL blaming other residents for the LAG which is caused by LL's failure to use enough server capacity/power/speed/hardware (choose your term) to run the grid.

/me keeps an eye out for the next deploy post in status.secondlifegrid.net

I think the limits are clearly justified. A friend gifted me a pair of shoes from a so-called famous sl shoe maker and these shoes eat 0.500+ script time continuously and are no mod so I can't get rid of the scripts for changing rather simple features.

Maybe estate owners need to start banning anyone entering sims with more than 0.500 milliseconds script time.

We really need lsl script time by avatar detection so they can be bounced out on entry. Or maybe an estate level setting for max script time per avatar and when people try to tp in they are told they are over using resources and to remove scripted attachments until they meet the allowed levels. Then when people figure out their abusive shoes are no longer welcome anywhere they will learn to demand non abusive script time guarantees on products before buying them.

During my first weeks in SL, someone asked me to look at a fire they had.

The flame was two flat intersecting prims.
In each prim was a script constantly listening on channel 0 (!!) for a Chat line beginning with the word "on" or "off". I thought it was a gobsmacking waste.

Some time ago, before the days of Open Collar, a person asked me to look at some freebie collar scripts. They were a right mess.

SL must be be full of badly-written resource-consuming scripts.

From a positive point of view, it's wonderful that people with no tech background in programming can make and/or modify scripted objects.
The downside is a bit like environmental pollution. We see around us in RL the effects of wasteful consumption.

My understanding is the the limits to be imposed will have little direct impact on most people for their own script load.
It's the avatars with hair of 700 individually-scripted prims and the equivalent of a major swiss-army knife as an attachments that are the concern.

Ditto for small parcels stuffed with scripted objects. I was fortunate when selling a big chunk of a sim that a neighbour was a major Zyngo palace stuffed into a 8192. Most of the prims were in the machines.They had 2 prims unused and I'm sure that they were looking ahead to the days of script limits related to land area. They bought up all the sim at premium prices - apart from a 4096 that someone is sitting in. Despite their owning a relatively huge area of land, the Zyngo build has not expanded.
This is as it should be. Like it or not there is a limit to resources.

I'm reposting something I put in another thread, because it's more relevant here.

/me wonders now, and has always wondered, why LL doesn't take some simple user education steps that would contribute to a less crashy SL.

For example, if I were Babbage I would sponsor a contest for the most resource-efficient hair and boot scripts. [Ones that don't have one script per prim when worn, for example]. I would package the winners along with a simple template hair and boot that would show the effects of the swapped textures/sizes/etc., and make this kit WIDELY available.

I would also hire a temp intern to hang out at clubs and identify the attachments that hit script time hardest, and drop on the creator a notecard FROM A LINDEN!! pointing out how to compile attachment scripts in LSL not Mono, and containing one of the aforementioned kits.

Take it from a project manager, this would be MUCH less work than providing better script instrumentation (tho of course we desperately need that), and determining/enforcing script limits. PLUS, and here's the payoff, it would take effect much sooner.

Perhaps the Forum Cartel should run such a contest, and widely distribute the results. I'm sure the folks at Oxbridge would be on board.

AND NCI...they have more campuses to help distribute the contest info and the results.

This is a great idea.

The problem with such a contest is the horns of this dilemma. Either the winner is objectively determined, in which case, you get what you measure (which usually isn't what you really want), or it's subjective, in which case we get what the decider thinks we want.

The solution that avoids this problem is the marketplace. Put in controls to make the cost (in terms of resource usage) clear, and let the marketplace decide which is best. As usual there will be multiple answers, because different people have different needs.

So, LL shouldn't do this. But, if a resident group wants to, that's great. It's not "official", so people are allowed to take the results however they choose.

However, it's not needed. As a result of this whole issue, LL will be implementing functions that will make it simple to write efficient resize scripts.

Sure, and I'm sick of residents blaming LL for problems caused by their own (or their neighbors') overuse of resources.

There is no amount of resources that can't be overused by residents. In many cases, the residents have no idea they're overusing resources (for example, by wearing hair that has 200 mono scripts in it, using over 12M of memory that serves no purpose most of the time.

LL could octuple the number of memory, servers, and everything -- driving their costs up enormously -- and we'd still run into this problem. But LL would quickly run out of operating capital, and SL would fail completely.

No matter how much hardware LL adds, we would still run into this type of problem. For more insight into the core issue, google "the tragedy of the commons".

Here's what we do: we keep adding stuff to our land until we hit some kind of limit (prim limit, lag becomes unacceptable, etc). When we start to feel the pain, we back off. I do it, the guy next door does it, the people on the next sim do it, nearly everyone does it. That pushes us all close to the edge, but OK. The problem with script memory limits is it is very hard to tell when you've gone past a reasonable limit for your situation.

LL is fixing that, bless their hearts.

/me creates a hat and puts it on xstreet. Only 50 prims and ultra-low lag!! It's really 255 prims and each prim has 100 scripts in it..