Babbage Linden - Limit scripts PER PARCEL

The problems are boring to fix. I know I don't want to try. Not even if they paid me. Would you?

You make a good point Amity, why wasn't something like this (however primitive) done from the start?

Even so, I'm going to be cautiously optimistic about this.

Hopefully, this will complement MONO's ability to only use as much memory as necessary (as opposed to LSL2 always assigning scripts the max amount). Also, remember that MONO scripts with the same uuid share bytecode. So if you have scripts intentionally designed to take advantage of that, you will see far less impact.

Not so sure it really works out that way in practice, at least for scripts where most of memory is state rather than code. Also, from what I've observed, Mono memory usage is pretty unintuitive, so it would not surprise me to learn that in some cases, recompiling code to LSL2 will make it fit in space too small for a Mono compile of the same script.

It will mean a significant change in how I script. Or, really, a change *back* to the memory-stingy practices we all followed in LSL2.

Some concern over how much overhead is incurred in measuring and enforcing limits; that tends to be why such things go unimplemented.

Assuming they get most of the details right, this will be a good thing.

I'm getting out of the habit of participating in discussions with Lindens, because what usually happens is that I take a long time researching and formulating what I have to say, and then receive no acknowledgement that I even exist in the discussion.

But maybe if someone else actually does get a Linden's ear and likes one of my ideas, they can submit my idea as if it were their own, and it might make a difference.

The amount of memory that an avatar gets could be tied to the amount of time the account has existed, and/or the presence or absence of payment info, and/or there could even be purchase of more memory.

A long time ago when I ran a MUSH, there was a crude way of limiting the amount of resources individual characters could use. Commands and functions that were particularly taxing on computational resources required "deposits" to run them. Every day, when someone logs in, they get 100 pennies. If a particular function required a 10 penny deposit, then a person with 100 pennies could only have ten of those running at one time.

Though crude, it was fairly effective in limiting the kind of griefing meant to crash the MUSH, and it helped regulate allowing more experienced coders to have more access to resources to do special things, and limited the amount of damage an inexperienced coder could do through mistake.

I'm no expert on griefing in Second Life, but it seems to me that the vast majority is done with throwaway accounts. The griefer expects to eventually be banned, doesn't expend a lot of time and money investing in the account, and thus has nothing to lose when going on a tear of doing as much damage as possible in a short amount of time. So if I were doing criminal profiling on griefers, I would expect to see (a) new accounts (b) no previous interaction with the world (c) no payment info (d) no money spent. If accounts like that were limited by the memory they could use, they would be limited in the damage they can do.

Furthermore, it takes time to learn how to make and/or identify efficient content in Second Life. Though not a perfect measure, it makes sense that people in Second Life longer would be able to make better decisions on resource use.

And, if people in Second Life for longer periods of time were to have more memory available, that would help grandfather in those who have dumped a lot of money on the items they have now, so they wouldn't see it all go poof with new restrictions.

If you have a business that requires the extra memory, then it would make sense to pay for it (as long as Linden Lab is not overcharging or extorting; of course, the temptation is there for them). The point of selling extra memory though would be more in the way of a bonding mechanism than a profit mechanism. The idea is, people make more careful and serious decisions when they have something to lose over those decisions (e.g., money). (And now that I think about it, instead of "purchasing" extra memory, maybe it could be done with a refundable deposit. That acheives the bond effect, wtih less financial consquences for the user.)

There are cases when new people probably should fairly have access to more memory (fast learners, alts of old accounts, and Second Life is supposed to be free). I don't know if they would be the case where things are just unfair for some people for overall health of Second Life, or provisions could be made to address them. It wouldn't prevent all griefing or inefficiency, but my guess is that it could reduce a lot of it. It would still give an incentive for more efficient content, without putting as much of a hammer down on those who have been in world for a long time and dumped a lot of money into what they have now.

Yup!
The ones that didn't cooperate and seemed to have a mind of their own.
The ones that wandered off into neighbouring sims - like Raymond Figtree's famous crabs.



There's a snippet from the blog entry referenced in the OP that might calm a few worried souls:



If 2000 on a 512 is an edge case, then maybe the limits will be aimed at the extreme hogs.

That many in a 512 is EXCESSIVE.

Just have to see what's considered "kosher".

I'm just glad my stuff is lightly scripted.

Please forgive me if this is a silly question, but can someone explain how this will work when an avatar sits on an object? Right now, as I understand it, the avatar becomes part of the link set and then their script use is recorded with that object on the parcel. I know I can always tell when someone is using danceballs or sitting on something in my sim using the estate tools because the script time for that object jumps.

How will that be handled? Will every parcel have to have enough buffer room to allow for avatar scripts, or will that be seperate? (Or do I not understand something here that I really should? Wouldn't be the first time. )

That's one of the things they are fixing in 1.26, avatars' attachments are getting better accounting, they will show up in top scripts separately even if they are not sitting.

Is there a method for determining the number of scripts running on a parcel on the mainland? I would like to be able to test my parcel and the mall next door.

Not now, but they are going to give us a way to see that before hard limits happen. It's weird for LL, but this time around they seem to be intent on letting us know just what will bork before it borks.

Although I assume you're jesting, this is my favoured solution, if someone on a 512 wants to run a launch a big script and there's nobody else on the sim, let them.

if scripts are going to be limited isnt everything going to become dull and static...everything interesting in sl uses scripts...

Thank you.

I wonder when we're going to get more of something (other than daft rules) from Lindens for our money rather than less ?

I don't think that's going to be a problem. They're not disabling all scripts, they're just trying to allocate them such that one parcel can't use up a hugely disproportionate amount of the sim's script capacity. I expect that as a result scripts will generally behave *better* than without the limits, and there will be more incentive for using scripts that are more efficient.

A net positive impact will only result if mechanisms to measure and enforce the limits are themselves efficient (as I mentioned above). If those mechanisms are bad enough, they could be like having a dozen runaway scripts on every sim, and nobody would get decent script performance. I'm planning to ignore that possibility for now.

As my land within the one sim I live on is split up into a whole bunch of parcels and 2 groups, I hope they're at least metering on group id instead of parcel id..

Thanks for the info.

i hope estate owners have the ability to disable this.
i dont want to be in a situation where i have to take this into account when parceling for seo, media, rez zones, etc.
i also worry how this will impact the stores demo rezzers and even the furniture we sell.

I don't agree with all these limitations. Breaking SL objects just because their server can't handle distribution of resources evenly?

There are sims the uses lots of server resources and sims that are low load. All LL need is to do is to distribute the resources evenly. Unfortunately they can't do it. So they are now limiting our script memory usage? And u guys agree to it?

What if I need more memory for script? Buy more land? Land barons will love this. LL will love this. Who suffer? Shop owner...but they will transfer the expenses to their customer.

And after this, what's next? When will LL stop mess up with the grid?

Its seems like never ending. Second Life is no longer as fun and free as it used to be.

Are you suggesting that real time physics simulation should be done on a distributed cloud? Or that the simulations should dynamically reshard? Either way, I'd think the result would be abysmal performance.

Will noone think about the prim babies!!!!!!
/327/64/312848/1.html

Preggy Mommy just had a 16k baby girl. Awwwwwwww!

It's bad enough trying to fly a vehicle now...what with regional boundary disturbances - LONG OVERDUE TO BE TACKLED - crashing in parcels which already use the maximum number of prims and now script limitations.

It's certain one group of SL users who get very little help or attention from Lindens are those who like to use airborne transportation in second life.

If you want to try saving a few resources why not start by turning off ban lines and getting rid of mass upon mass of free alt accounts.

I can't say I disagree or agree particularly with limiting the available resources for scripts in order to improove simmulator performance, but I think they shoud adress some of the jira reported issues before applying this limitation.
It has been long since it was first reported that dissabled scripts loose their dinamic memory, if they are not-running when taken to inventory, crossing a sim, teleporting or during a region restart. Fixing this issue, would allow for instance huds, atachments and vendors that at present time are impossible to consider because they need to remember permissions, basic configuration data, etc.
And what's worse, when this issues were originally reported, someone among the Lindens sugested to use http, xml-rpc and/or email to backup the information, which are now are also being considered as causes or diminishement of performance, and that in some cases like permissions are also impossible to produce (none can enable payment through them for instance).
This is a list of reported issues concerning this matter, all unasigned, one of them re-opened but still unasigned:
https://jira.secondlife.com/browse/SVC-1853
https://jira.secondlife.com/browse/SVC-26
https://jira.secondlife.com/browse/SVC-2558

Lets keep this thread at the forefront my opinion is that its important....