Scripting, lag, and you.

Everyone complains about lag. While measures are being put in place to prevent people from lagging each other through excessive scripts, here's an interesting rule of thumb.
While the lag caused by a script is heavily dependent on the TYPE of script, normal usage patterns may point to an average load per script.
Yesterday I was having one heck of a lot of lag, and so I talked to a Linden. My sim had about 650 scripts in it, which, I was told, is considered pretty high.
There's about 65000 square meters on a sim, so a script to land ratio of 1:100 is enough to cause severe lag.
This means that, no, I'm sorry, but you cannot have 50 sex balls on your default 512 square meter plot of land. You can have about 5, though...
The good news is, we are getting a new scripting engine that is supposed to be 100 times more efficient... so... will that mean you can have 500 sex balls on your default bit of land? Whow. Imagine all the av sex you could do with that! But you have to wait a while, and in the mean time, think of your neighbors and try to stick to 1 script per 100 meters of land that you own. 5 for 512, 10 for 1024, 40 for 4096...
Any input on how to improve this rule of thumb is very welcome.

And, with PoseCubes using my PosAbility software, you'll only need 1 sexball per person, rather than a constellation of floating balls above each bed / couch / 3-some-device / etc.

Are waterfalls bad for running lots of scripts? Everyone seems to think sex balls are bad, but are the pretty tinkling waterfalls not one of the worst offenders?

If so, I'm in trouble!

Since no one tends to be able to agree on what causes lag in a script anyway, and usually resort to beating each other over the head in an attempt to strut their mad scripting skillz and stroke their already massively inflated egos, I doubt you're going to get very far with a reasoned discussion.

Personally I think a good start would be to educate some of the people writing the scripts. Some I've seen that are in common usage are simply fucking terrible in their implementation.

What would be kinda cool is some sort of 'script summary' that shows what's actually active and chewing the resources in a script. As well as giving you an idea how efficient it might be, it might be kinda interesting (what was that reason for your walk replacing shoes having a listener again? )

But yeah. It's gonna end up being throttled. Of course it is, the way people whine and cry about it. And as usual, it's very often people who know fuck all about scripting or lag that cry the loudest. But then as I say, since no two scripters appear to be able to agree on the causes of lag without resorting to trading insults, I'll be interested to see how this thread continues

I see it as a replay of the prim hog wars pre 1.2, and the result will be the same: you'll end up having to exponentially increase the amount of land you own just to have the scripts you want. Good for LLs finances, bad for us.

No, in fact, waterfalls are likely among the LEAST laggy objects you could construct. Texture animation, particles, those are both client-side effects. An audio loop is almost as low-impact. Unless it's some wacky new definition of the word "waterfall", you have nothing to worry about.

Hahaha... that's the line I'll be seeing in my dreams.

Pretty tinkling waterfalls, whether texture animated or particles, are state driven to the point you set them running once and can delete the scripts entirely once they're on. I doubt (but am no expert, unlike the many self appointed ones we have here) they cause much lag. Server lag, I mean. Which is what we're talking about, right? Or are we? and what is server lag anyway? and what about client lag? so then what about scripts that cause virtually no server side lag at all but slows everyones clients to a crawl? how we going to regulate for that? or are we? and if not, doesnt that mean the whole point of throttling is lost? *has headache*

You know, people have this idea that technology is unchanging and everything should be heavily regulated. I'm of the belief that every additional rule you make halves the fun of the game.

There's no good reason that having 50 sex balls should lag anyone. There are (or at least, there shouldn't be) any active script components. If they cause lag, the correct solution is to get the Lindens to fix it, not to legislate everyone into the oblivion.

Well, if this is to be the case than we need a new trust model for SIMs.

Basically, Multiple SIMs should be connected and cross-sim commands like llInstantMesasge / llGiveInventory / XML-RPC / Email need to be throttled based on trust.

For example, if you have your own set of SIMs you could set up a full trust network between them which allows for any of the above commands including cross-sim border movement.

However, anything from outside your group of SIMs may need to follow through some trust rules and you should be able to set up parameters so if they break those trust rules then the SIMs they come from lose trust.

Because in the end, we need a scaleable model. You can't simply leave everything open like the internet or you'll suffer from all the problems that have plagued it.

my own testing on the subject is if there are no listeners the 50 pos balls will already have NO lag.. even though they will increase the script count.. Even with listens they won't be that bad unless there is something talking on that channel. (unfortunately this most likely means anywhere in the sim, and worse if the chat is in range of the devices.)

As for 650 scripts.. I'm in a sim with almost twice that.. yet many sims with 650 scripts have many more problems.

more realistic numbers (max) for a 512 plot are:
* 1 or 2 scripts that run constantly 24/7 non stop
* 3-5 actively chatting elements or 5-10 passive listeners
* 2-4 physical, phantom objects updating every second or 2
* 0.00000 objects running llSensor more than once in 5 to 10 seconds
(half this if it is a boot script no where near your build making it hard to fly over your land)
* limit numbers of timers.. but while they do lag some.. it normally isn't the reason for any notable lag.
* 1 physical object NOT phantom (this is an interesting case.. this as the phantom version if on a timer like my butterflies will cause practically no script time usage.. but WILL use physics time.. depending on the prims 3 physical non phantom objects have been known to single handedly kill sims)

its hard to say what is too much.. but if you are notably over any of these numbers or are on the line with many of them consider script reducing.

The following will create absolutely NO server lag:

* scripts waiting only for linked message events
* scripts waiting for touch events.

as any script that only dose the following:

* set the hover text
* start (but not update) a texture animation
* make particles
* llTargetOmega if I'm not forgetting its name (client side rotation, like spinning for sale signs.. thats right those annoying things DON'T lag the sim.. they just look ugly)
* set sit location, eye position/direction.
* set sit/touch text

if a script only dose a set of the above and nothing else.. you can remove the script after it is initialized the prim will remember its state.

(however not all of these states will work if the object is re-rezed or moved)

all of this said mono when it comes out will give 100x improvement.. then hopefully they will be able to time slice scripts better based the amount of land you have.

This is, of course, quite true. However, I should point out that client-side effects like texture animations, object rotations (with llTargetOmega, not llSetRot()), and particles will often "lag" a user's SL experience because of the load that they put on the client. Its true that in these cases the sim itself is not lagged, but people may very well be experiencing lag when any objects with these effects are within their line of sight.

- Ace

Amen.

It's not scripts that are the root of the problem here at all.

They most certainly do not occupy spatial resources, so tying it to land will be completely unfair. And then limiting my potential by the amount of money I can contribute per month?

Don't hinder the game with regulations and red-tape. The Internet is already suffering that -- let's keep one free frontier somewhere out there.

\


Geez, Eggy, funny when you say that, you aren't bombarded by hate mail like me, just because you're part of the FIC and a tekkie?

BUT I'VE BEEN SAYING THE EXACT GODDAMN SAME THING IN NUMEROUS THREADS.

Duh, you finally experienced lag and finallly talked to a Linden.

Like we all did months ago, and got the same information, that sims begin to lag at 300, become a slide show at 500, and grind to a halt at 650.


NUMBERS OF SCRIPTS DO MATTER DAMMIT.

All this endless pontificating about different kinds of scripts can't mitigate against the fact that

NUMBERS OF SCRIPTS DO MATTER DAMMIT.

So glad to be getting some recognition of this.

And so glad that finally some people have pulled their heads out of their asses long enough to get the facts that we all had months ago, which is why we had this discussion started long ago.

And your idea of voluntarily complying with "1 script per 100 meters" is merely a voluntary idea which won't work, because education and voluntary compliance doesn't work.

So now that you're prepared to recognize that NUMBERS MATTER, you can see why my concept of charging those who have more than X number, 300 or whatever, and have more than X number on Y meters, i.e. numbers plus density, is a reasonable concept. It means that a tier bill of high numbers of script on density of meters will be something you you have to pay to play. It's the only way to concentrate the mind wonderfully.

See, you can appreciate the problem with scripts when it is in something you think is part of the "masses" like sex balls. If it was in kewl vehicles and weapons that kewl tekkies had designed, you'd be less likely to have had this Epiphany, of course.

Honestly, Eggy, I never lack for a laugh a minute when I see all the hypocrisy and self-referentiality here on this forum.

Only thing I dont understand, if you need 50 sex balls, thats fine. Is there any reason you have to leave them out when your not signed on though? Isn't it just a 2 second process to drag the ones your not using in and out of your inventory?


At least then, when you're not in world, others will not lag all the time.

That, or pressure from users for efficient and fast scripts will lead to better script/pose balls/etc that will run comfortably in your 512/65535th of sim CPU quota.

Funny, Varney has 600+ scripts and hasn't ground to a halt.

Prok, you're a land baron. If you'd like to learn about scripting, you can start with the scripting WIKI, or the scripting tips forum. But please, please, PLEASE, don't think making up random facts about script performance is a good way to learn scripting. Because it's not.

I'm not a "land baron" Hiro because I don't buy and sell land. I rent land. Unless you're now extending the definition of "land baron".

But whatever, I don't think there is anything negative about land baroning. I think some practices of land barons are negative and that others who engage in good practices should seek to extend those good practices and publicize them more rather than adopting a punitive approach.

Eggy just explained that LOTS OF SCRIPTS=LAG.

I don't need any wikis to find out that truth.

I don't need to be told this is a "random fact" when I've seen it over and over again on dozens of sims.

Everyone knows it is true.

It is very hard for the scripterati to admit it is true because it's a silver nail in their coffin.

But it is true, it is true. Too many scripts=lag.

Lozi 1020 ish active scripts... 150-200 sim fps and 45 physics fps.



most builds out there seem to use these within reason (ie. my 4yo desktop with a G-Force 3 doesn't notice) but when animated textures, rotating objects, and particles become the primary part of a build you are quite right.

The vast majority of pose balls contain a show/hide feature which involves an open listener, usually on channel 0 and not filtered, to add insult to injury.
Prokofy, I never said otherwise. I was the original proponent of the current prim limitation system in the summer of 2003. I had experienced plenty of lag before you even joined, thank you very much
Heck, in beta/1.0 sims used to lag with as little as 5 people in them.
As for the people in this thread protesting against any sorts of limits, well, your position is selfish. The "tragedy of the commons" is an old, well-known problem, and SL's original, overly libertarian design, was flawed. Just as there is a per-parcel limit to prims, Linden Lab has already decided that there WILL be a throttle on scripts "real soon now" and I eagerly await the day when LL will realize that textures need to be limited as well.
In the real world you pay for a piece of a server, you get what you pay for, and if you overuse resources your ISP will send you a nastygram and even kick you out. If I run an overly CPU-intensive task on a shared machine, the system administrator will kill it and if I do it again he will lock my account.
If you want complete freedom, buy a server, or go play with offline CAD software where you won't interfere with other people.
This is a massively multi-user social world, not your little personal sandbox that you can use and abuse as you see fit. The SL user base has repeatedly shown that it cannot be trusted to control itself, and so LL is stepping in to do it for them.

I believe his example was sex-balls, which are notorious for having open listens and are one of the biggest contributors to lag.

But to say "LOTS OF SCRIPTS=LAG" when you "don't need" to so much as basic knowledge of scripting is absurd. I can make 10 scripts grind a sim to a halt, and I can make 1320 scripts barely affect the sim at all. (See Animations forum -> my PoseCube thread -> the stress testing).

Saying how many active scripts would be more accurate. But, if all of your active scripts are texture rotates... then hey, it's still going to put the lag on the client, and it will be
localized to only creating lag to people actually looking at the prim.

Varney has 714 active scripts. It is not hardly "grinding to a halt".

A much more intelligent approach at limiting lag from scripts would be to limit sensors and listens, or search for technological ways to improve LSL, like providing inter-object communication and dialog boxes without using listen scripting.

And if you weren't so damn condescending in your posts, maybe you'd be able to alter your position without looking like you were backpeddling. Please cut your "scripterati" crap. Especially to a person who scripts freeware scripts and helps noobs with scripting help every time he's got his Live Helper channel activated.

And ... here's a picture of Willy Wonka telling you, "You get nothing! You lose! Good day sir!

There's really not much more to say than this.

Except that most of the ones I see have listeners on an open channel listening to every. So yes, they do have active components, and are parsing every sentence within listen range every time anyone says anything for the words "show" or "hide".

-Flip

No offense, but you have been plugging this thing so relentlessly that I think it will have to be very good indeed in order to live up to your boasting.

Maybe you could back off the advertising a bit?
At least until you have some actual product?

One simple equation folks...

MORE EFFICIENT CODE

EQUALS

LESS LAG

EQUALS

MORE FUN FOR ALL.

Now, I'm not saying everyone should be required to get the PhD in CSE from MIT before writing LSL... but c'mon people, when you know you're creating lag, don't stick your head in the sand.

Regards,

-Flip