Babbage Linden - Limit scripts PER PARCEL

It's not just a matter of burning memory to achieve performance, it's a matter of burning memory to work around longstanding holes and restrictions that just don't make sense.

Like, oh, the lack of llGetLinkPrimitiveParams(), or llTeleportAgent().

I've been wondering if a different system than the magic box will emerge now that SL and XStreet have merged. I find the magic box is difficult to use, takes a long time to update and I can't add a landmark or other fix unless I spend a while updating my item.

snip snip snip at resources ...cut back here, cut back there...

but we never see any cut back in tier charges.

Be nice to see 'more' made available to customers instead of less....

if we want to save resources lets start by getting rid of crappy useless ban lines.

I have a game store called Celestial Game Tower. I been building it for a year and a half now. I have been talking to game designers who work hard to bring content to Second Life. And in some case some took months and even almost a year in one case to develop. One shining example is a cutting edge game called Komikaze. This is a real time asteroids video game and is an incredible example of what can be done in Second Life. Its not a cheap game and when this memory/script limitation hits people that purchased this break through game will not be able to use it on their land unless (just a guess) they owned half a sim. Another game is a chess hud with scripted players. Unless they give avatars a huge amount of memory/script abilities it this will be rendered completely useless. Of course Linden Labs won't refund people who purchased these games and will probably just suggest them to go buy more land in some cases. Also with games with the nice advances with mono such as commercial skill games prims were lowered and amount of scripts reduced. Game hall owners who provide content to Second Life might be compelled to buy more land as a when their games shut down because of too many scripts/memory or whatever. As I understand this on face vaule suppose to be about reducing lag. If that was the real situation there would be limitations on physical objects rather than scripts. a good amount of physical objects will slow a sim down to a crawl with no scripts required. I also have to think about how this will affect different communties and content. Furries for example are heavily primmed and scripted, animated eyes, twitching ears and so forth. This can easily have an impact on them. I think people have been listening to Linden Labs canned answer for lag which mostly is BS. Too many scripts. When I had lag issues now and then and ask for a reset its always the same too many scripts in the sim. I look there are 7,000 scripts which isnt out of the ordinary for a sim with a high amount of content. I been in sims with 10,000 scripts with no noticable lag. Its the quality of scripts and what their doing. I also see this potentially affecting businesses such as rental malls among other things.

I have seen responses as scripts used to grief sims by residents slowing the sim they reside in. Makes no sense to me why someone would do that to their own sim for malice sake. Also I been here since 2004 in one avatar or another and I have to say 90% of lag is user side. Peoples computers arent up to the job. I have two computers and one is horribly "laggy" only because it is an old computer and underpowered by todays standards. I been in sims where people claim its laggy and I see no evidence of lag which means its user side or their network. At the same time I do experience lag when I come across a huge forrest sim with hundreds physical waving in the wind trees and plants. Back to griefing there are a lot of ways to grief a sim, most don't require a lot of scripts and limits won't affect that anyway. All they have to do is find a few abandon parcels with build and scripts on and drop their grief packages. Or just self replecate a bunch of listens scripts or shouting scripts, or penis following scripts. The majority of griefing attempts really are simple scripts. The classic is rez some annyoing following script object and have it chase people with some annoying sound. Its a Sandbox classic. Limits will have zero effect on griefing.

It is always a horrible move when Linden Labs makes a move to destroy content in Second Life unless you happen to own a full sim. It's very clear the old your world your imagination slogan is long gone. Instead of embracing break through achievements and trying to take Second Life to the next level it seems it will be set back a few years in some cases.

If it is a "memory issue" Memory is extremely cheap. Wouldnt cost much to through another gig on a server. Better solutions would be to improve scripting handling of known laggy scripts such as listens and physical scripts.

I am not speculating that there will be a negative effect, there simply will be one and content will be broken yet again and this time for good in some cases. People in Second Life work hard and countless hours to bring content for people to enjoy. Without them Second Life would be a single server in a basement and thats a fact. Linden Labs owes their entire business to people who go to huge efforts to bring content, activites, games, role playing sims, virtual sports, skill game centers, and so on. Creating a situation where a lot of these creations will be crippled, hurt or destroyed is a step backwards and is yet another Linden policy which shoots both their customers (ie residents) and themselves in the foot. This is a huge issue and it will require a huge amount of careful thought on Linden Labs part. They have already on many levels alienated their customer base and drove them away this will be another step to do that yet again. Keep a close eye on this one. Talking to a dozen key game makers, most of them think this can be a very bad thing. If you ask me its better time spent to improve ways scripts work to make them more efficient from the Linden end of it. I had a linden come in my sim to ID some laggy scripts. when I was trying to find some problems and one thing they IDed was a sim radar that was off in sleep mode. It wasnt doing anything. The other was an texture animated sign. Simple script using offsets and sleep commands. They really need to provide residents the proper tools to ID potential lag.

A typical busy sim has a few thousands scripts on it, and that is how the lines are going to be drawn, based on current typical usage. They will be based on what scripts are allowed today, 16K for LSO and 64K for Mono. The variable stuff will only be able to affect newly written or altered scripts that use the as-yet-unavailable memory functions.

As a rough estimate, your game would need to be using a couple thousand scripts all by itself for this "you would need to pay for half a sim" idea to make any sense at all. And if you really are using a couple thousand scripts in a single item, you had damned well better not be doing that on my dime.

Sorrina, make sure you test your products on the beta grid.

The changes LL is making are due to a real problem that has severe consequences: cache thrashing. They're not just doing it to ruin your day. Until it's fixed, this does ruin people's days.

If your scripts have a reasonable enough footprint, then they'll work just fine. If they use too much memory, they won't work, and that's a benefit to the others in the sim who want their content to work as well. If your scripts use more than a reasonable share of the sim's memory for a given sized plot, it's appropriate that they not be allowed to run. Of course, we haven't yet worked out what's reasonable. But very specifically, it means, not enough to cause cache thrashing in the sim.

Personally, while I think it's cool to do complex games in LSL, I also think it's inappropriate, if it can't be done efficiently enough. Until now, there hasn't been nearly enough feedback for people to understand the impact of scripts they're using.

Let's assume your products are efficiently coded and don't use more memory than is reasonable for an appropriate venue. Now, isn't it to your benefit if nobody else in the sim can rez a memory hog object that causes your customer's whole sim to bog, including your products?

As I keep saying: yes, this is going to cause problems. But the problems it causes are not as bad as the ones caused by failing to address the issue.

If you have a better suggestion for keeping objects from using so much script memory that they cause the servers to thrash, please help by offering your solution. If LL is being stupid, well, help us all out by proposing a better solution. But be sure to address the real problem: unbounded script memory usage causes thrashing.

There's also a problem with script runtime, but it's not nearly as severe. Private island sim owners have a tool that helps, but parcel owners need it (including mainland). Because the impact is less severe, it'll may work best to simply give residents the ability to measure, without a need to institute per-parcel script time limits. I certainly hope so.

what problems is it causing exactly ??

Sorry too many prims for that burger and the scripted pickle animation--well it is over the top. It is lagging the entire world.


Its always smart to dumb down SL rather then to redevelop it from the ground up so it can actually handle massive amounts of scripts. More cost effective and backwards thinking is just much better.

Agreed.

Lindens always claims to be doing well but every step made to 'imporve' the service seems to involve cutting back, or restricting....

I never get the feeling with lindens that customers are valued...

http://en.wikipedia.org/wiki/Thrash_(computer_science)

In essence, LL has been redeveloping the scripting subsystem from the ground up so it can actually handle massive amounts of scripts. Now that they have a modern VM, they can put in the pieces that should have been there all along.

Erm.

Actually, the old scripting subsystem did a better job of handling massive amounts of scripts than Mono does. They're not having to put script limits in to deal with LSO scripts, they're having to put limits in because of Mono scripts, because they're so much bigger and because they can only manage Mono script memory and usage statistically.

Mono's advantage is higher peak performance, and that's it. For the usual kind of "glue" scripting where performance is not an issue LSO scripts have lower impact.

but if this new sytem is done to handle it why are they having to prune back.........

its like saying theyve got a new trainengine to pull more passengers ... but the carriages are being taken away.

lol....

Simply because nothing is simple. Mono has been a big improvement in many ways, but has raised a few issues. The GOOD news is that in general, we're no longer dealing with event processing times; we're dealing more with memory use and "background" times (the CPU time a script takes even when it has nothing to do).

BTW, I'm confident that we'd have problems with script memory even without Mono, when people make things like 200-prim hair with resize scripts where the script has to be in every prim. That's 200 * 16K = 3200K or over 3M, just for one avatar's hair. It adds up!

As long as there is no pressure forcing content makers not to use absurd numbers of scripts, they'll do it. It's a case of "the tragedy of the commons", which you can read about on Wikipedia for more info.

Mono offers the possibility to reduce this problem by sharing code space, but currently exacerbates it for more complicated reasons.
Actually, they put in a bigger engine, and folks responded by adding passenger cars willy nilly until it broke the new engine. Well, turns out that the old engine broke down more gradually, that's all. The new one doesn't just slow down, it runs off the track and demolishes the landscape. Oops!

They could have shared code space with LSO as well.

I suspect it would have been easier to share code space with LSO.

Sharing code space in Mono is mitigation of the larger memory use in Mono, not a feature of Mono.

Using Mono for Second Life is like using a 747 as a commuter car. I'm amazed how well they've fitted the turbofan engines under the hood, but *damn*.

Bottom line on this is that LL engaged us early in the process, they're telling us what their plans are as they work them out, and they're paying attention to our feedback.

If folks really have useful ideas to contribute to that discussion, or can foresee specific problems that could be avoided, then join that discussion and make those suggestions.

If you're just whining, well, fine. Whine away.

Concerning a complete rewrite of any large system, that's usually fatal, and when it isn't, it often takes an extraordinarily long time before it pays off. It's generally far better to use the gradual plan: see where you are, plan where you want to be, and take the steps that make sense to get there.

The main thing they need to do is allow controlled overcommitment.

I agree, it doesn't seem to add any serious efficiency for most of the bread and butter functions of LSL, the ones that get used most often. You know, llRezObject(), llMessageLinked(), llSay(), llWhisper(), llOwnerSay(), llTriggerSound(), touch_start() and collision_start() events, the stuff that's in the vast majority of scripts because it's the sort of stuff that the vast majority of scripted objects in SL do.

The main advantages are for complex mathematical equations, which is great for the edge cases where that's required, but most scripters really don't need to create fractals. The extra memory limits were nice for scripts that involved a lot of lists at first, but of course now that extra memory appears to be a double-edged sword (or maybe a better description would be a sword with no handle, ouch!)

But of course, one little itty-bitty problem was that a lot of people bought into the Mono pre-release marketing campaign, and truly believe that Mono will make their 200 color-change scripts more efficient. I don't blame LL for trying to show off the new things that Mono could do, and I don't blame them for trying to sell people on the necessity of what was a very large (and probably expensive) project.


The reality is that script processing and script memory are shared resources in SL. Most good scripters know this and factor these concerns into their projects. Unfortunately, there are some scripters who either don't understand or don't care. Without effective limits on these shared resources, there is no incentive for these scripters to learn or care about this. Good scripters should welcome these changes....incompetent scripters should rightly fear them, for they will be exposed for the charlatans that they are.

Oh, this will be soooo much fun to watch.

On the overwhelmingly positive side, it seems we'll be getting some real tools for measuring and managing the impact of scripts we write. Lacking such tools, it seems a little harsh to condemn scripters who've had little reason nor ability to know better.

(But while we're on the subject of charlatans, , I can hardly wait until one of our favorite "weapons" scripters schemes a way to contort memory limits into breaking everybody else's scripts.)

How can I find out how much lag I am creating? How can I measure each item for the lag it contributes? I like to keep things on in my house, but I do park the dog. It is very easy for me to conserve prims and I do the best that I can. But I have no idea how to measure script resources.

BT

That's extremely harsh and, imo, totally wrong. I would guess that most people who write scripts in LSL are ignorant of these things, including me (this thread and another recent one have been most illuminating). Most of us write what we need and don't involve ourselves in the scripting community, so we don't normally become aware of these things. I write the scripts I need and I'm neither a charlatan nor incompetent. I've been programming since the early 80s. Not so much in recent years, but I still have a *lot* of programming behind me. Charlatans and incompetent, we are not.

You've been coding since the early 80s and while you're writing code, you don't put any thought into performance?

Of course, when I consider it to be necessary, which hasn't been due to backend considerations. Here, the discussion is about about the backend, which is something completely different, and something that I (and I imagine most people who write scripts, who are also neither incompetent nor charlatans) have never had a reason to consider - until recently.

Charlatan.

I agree with you Phil

I know people who are not professional " creators"
or scripters.. the only reason they are here is the shear
enjoyment of experimenting and enjoying building new "stuff"

I'm sure I am guilty of having too many " Bad "
scripts running on my parcel.

But how do we know? will it just dissapear because it is causing a problem?
Will there be a notice or an IM at least?

Erm.

The average Mono script is using only 11K, that is from Babbage's measurements. LSL scripts use 16K regardless of how much they need.

And the memory limit plan predates the Mono rollout.