LAG - Script Warnings - Take off - or - Detaching Eyes, Textures, Etc no longer being used...

[StoneCold Firehawk]

Okay, I'm going crazy. I'm on the verge of needing a break from SL with all the SCRIPT issues - I go into Frank's and such places that have a script counter because of "LAG" - we have such bad LAG because everyone is getting Mesh bodie's and Mesh Heads with scripts. 

So... now due to LAG and Jelly Dolls and high script counts I am determined to strip my girl / avi of what is no longer in use.

I have Catwa eyes, but yet I notice that my Egozy.Eyes are still in her head somewhere. 

HOW do I get rid of all these things? Notice I've selected them to TAKE OFF or DETACH - but problem is... there is no way that I know of. There are others as well in her bode that needs to go.

HELP - I'm in the BATTLE of the LAG - High Script WAR! 

[Syo Emerald]

I'll make this short and quick:

- Jelly Dolls have nothing to do with scripts. They are producted by a heavy rendering load, usually caused by too many large textures on objects worn by avatars. If you end up being a Jelly Doll, check the things you are usually wearing. A number one problem can be jewlery.

- The eyes you show in the picture can not be detached. They are system eyes, one of the essential parts of your avatar that can never be taken off, only replaced by another bodypart of the same type (for example: other system eyes). They are not an issue for your question. System eyes do not contain scripts.

 

If you want to check what may cause problems: focus on the attachments, not on the body. Again, jewlery can be an issue, but also older hair styles, prim shoes and stuff like that.

[StoneCold Firehawk]

So the Jewelry is causing Lag and Script warnings as well?

 

[Syo Emerald]

---

AmberSwann wrote:

So the Jewelry is causing Lag and Script warnings as well?

 

---

I don't know, because I have no idea what you are wearing or how its put together. But from experiance, jewlery can be a good starting point to look for things that cause trouble. What you can be sure about is, that its unnecessary to worry about your mesh head or mesh body. Since you are using pretty common ones, the warnings would go off for everyone who comes along, because they are so common. So if there is a valid reason for those warnings, it must be something else you are wearing.

[ChinRey]

We have to separate between two completely different things here:

Script lag used to be a big problem in Second Life but Linden Lab fixed that long ago and they hardly ever cause serious problems, at least not the kind of scripts you wear. But many places still use outdated script counter lag meters that harass people wearing lots of scripts and besides, unnecessary scripts are never a good thing anyway. Typical wearable items that contain lots of scripts are items with outdated resizers (hair especially) and the OpenCollar.

 

The jellybean function is intended to address what is the most common lag problem today: render lag, that is avatars (and sometimes rezzed items) that are very difficult for computers to render. The most common cause to excessive render lag are textures, some old style flexihairs (but probably not the one you wear in that picture) and simply too many items worn. As Syo said, jewelry can often cause very high render load. But not always, it depends on the textures used. Good jewelry makers only use the textures needed to make their works look good and they hardly ever cause any big problems. Many less skilled jewelry makers tend to overdo the texturing though, it's not unusual for jewelry to have so detailed texturing you would have to scale the thing up to cover almost your entire computer screen before you can actually see all the details. That kind of jewelry will always be very render heavy and one or two such times can be enough to drive your total ARC (that's what we're supposed to call avatar render weight these days) through the roof.

Fitted mesh bodies and heads and clothes don't usually add much to the calculated render weight. That is, they can add quite a bit to the actual render weight but Linden Lab just plain forgot to take that into account when they made the formula for ARC calculation so they won't usually trigger the jellybaby look.

 

In any case, since makers aren't likely to tell you how much render weight their items have, the only solution is to strip down to a completely bare avatar, then add items one after another and see how they affect the ARC. Shouldn't take that long to figure out which items cause the problems.

[StoneCold Firehawk]

Thank you so much you guys for your feedback replies. I do believe the standard computer is going to catch hell in SL... and mine has a high-end graphics card. WHICH it appears I'm going to have to upgrade once again.

I have a NVidia GeForce  GTX 760 2gb cache... and boy do I hear my fans werring away trying to cool it down.  Guess it's time to by the 900+ series now... *sigh*

Cheers!

[Sassy Romano]

---

AmberSwann wrote:

I have a NVidia GeForce  GTX 760 2gb cache... and boy do I hear my fans werring away trying to cool it down.  Guess it's time to by the 900+ series now... *sigh*

---

That actually surprises me because the SL engine doesn't drive the GPU anywhere near as hard as other optimised games.  My GTX 680 sites pretty quiet in SL, the only time is on empty regions where the frame rate would run to three figures completely unecessarily.  I cap my frame rate, cool, quiet PC.

[BilliJo Aldrin]

There is a much easier way. Just don't patronize places that have those annoying script measurement things. Script counting is so yesterday anyway. Avatar complexity is the latest cool new thing to measure and moan about.

By the way, to really reduce lag, turn everyone into jellydolls except friends and people you are actually talking to. I was forced to  do it due to a failed video card fan. Now i'm lag free everywhere i go.

[Jenni Darkwatch]

Like others said before, its a complex issue.

One reason to limit scripts on venue patrons is responsiveness of things like danceballs and/or scripted vendors. Since sims don't prioritize scripts on parcel over worn script (as far as I know anyway, please do correct me if I am wrong), walzing in with scripts that consume a ton of frame time will lag aforementioned danceballs and vendors. It's less the number of scripts, more the time the scripts consume. That being said, having lots of scripts also eats into that time, therefore less scripts = better for venues. There's other things in some venues... like listeners on local chat, as often used in collars. OpenCollar is a prime offender there.

Hoe complex ones avi is should be pretty irrelevant for the venue. LL gave us the tools to just turn obscenely render heavy avis into jelly babies or impostors depending on how much our systems can handle. In other words, if you do care whether other people can see you, worry about ARC. If you don't give a damn... go nuts on what you wear. I've seen venues enforce ARC limits, but I think that's pretty silly.
Sadly not all creators offer demos to check out how well-made their items are. Many, even from very well known makers, are just flat out crap.

[Wendy Starfall]

I've stumbled upon this by coincidence. Scripts only use negligible server resource, granted that the script was created by a halfway decent hobbyist or professional programmer.

A modern LSL script (compiled in mono) can have a maximum amount of 64 kilobytes. That is about as much as an average sim card has, like the one that you would stick into your phone.

An item that is designed in a sophisticated and resource friendly way, usually has more scripts than a quick and dirty hack that is done with lots of copypasta in "only" a single script.

Unfortunately some scripters who don't possess the skill to create high quality programs, often cram everything into a single script and then claim that this was done for "less lag".

That's a bit silly of course. It would mean that a person investing less thought and effort into scripting would produce a better result than someone who follows basic UNIX programming philosophy and takes her time to intelligently split individual logic up into dedicated scripts.

You have to imagine that like a row of windmills which have virtually no impact on the environment other than that they stand there and do their job, compared to a nuclear reactor that is a single entity but can have very negative impact on the environment and destroys everything if it breaks.

OpenCollar, which was mentioned here in this thread, has been a leading edge in LSL programming during the last years and the project itself is on the number #1 spot of globally trending LSL open source projects on GitHub (the largest host of source code in the world) persistently since 2013 and at the time of this writing.

In that sense OpenCollar is the go-to resource for resource friendly methods in LSL scripting.

What most residents experience as lag is the enormous amount of visual content that their viewer has to download in order to render everything and everyone around. A high quality texture, like your mesh head's face, with a resolution of 1024 x 1024 would have an average file size of 4 megabytes. That is about as much information as 63 scripts have.

Scripts are vilified because many people don't understand them. In the end it is all just information that needs to be either processed on the server or downloaded to the computer. Script counters are an indication that the venue's owner is desperate to pass the blame because many visitors are moaning about lag, only to end up harassing their own guests.

The fault is never in your own avatar or in your choice of skin, clothing and accessory. You are not to blame. At the moment lag is part of the nature of the beast and the best known cure for it is zen.

[Qie Niangao]

---

Wendy Starfall wrote:

 

An item that is designed in a sophisticated and resource friendly way, usually has more scripts than a quick and dirty hack that is done with lots of copypasta in "only" a single script.

Unfortunately some scripters who don't possess the skill to create high quality programs, often cram everything into a single script and then claim that this was done for "less lag".

That's a bit silly of course. It would mean that a person investing less thought and effort into scripting would produce a better result than someone who follows basic UNIX programming philosophy and takes her time to intelligently split individual logic up into dedicated scripts.

---

This is an old thread in which to be having this discussion, but I'm afraid this may lead some novice scripters astray.

Interoperating LSL scripts are not like modules in a compiled program. There's a significant amount of overhead required for scripts to share so much as a trigger bit. Also, even a completely dormant script requires a tiny bit of simulator time in the scheduler. (Yeah, that's a pretty unintuitive design choice, but surprisingly it didn't change with Mono.)

Because of both (non-native) scheduler and communications overheads, separate scripts are much heavier than POSIX threads; they're almost like separate heavy-weight UNIX processes. (Probably worse, actually, because the communication events are mediated by the script engine, not directly by the OS.)

That said, there are sometimes special reasons to break up large tasks into separate scripts, even if it could all be squeezed into one. But much, much more often such modularization is simply a well-intentioned mistake.

[Wendy Starfall]

Yes, I literally stumbled upon this by coincidence (I didn't even realize that these were dedicated fori until today :matte-motes-bashful-cute-2:).

Well, I'm one for the bootcamp approach for novice scripters with all the yelling, degradation and weird, apparently meaningless ritualism that it takes for THESE WORMS TO BECOME MEN!

The total-unixy modularization that programs, such as OpenCollar pre-4.0 had, are not suited for Second Life because this platform has a way different pulse than an OS of course. My wording was maybe a tad too populistic, yet I want that it is clearly understood that an approach meaning to modularize is not in the slightest way an indication that the programmer was doing a bad or lazy job. Usually it means the opposite and that she or he was investing a whole lot more thought than someone who created a cacaphonical masterpiece of LSL library copypasta in "only a single script".

If anything led aspiring scripters astray it'd be to be labelled "no good" for a dedicated approach that ended up having their users harassed by "script counter bans".

Say, if you "do one thing and do it well" in one script, then strung those scripts together into a program, that novice scripter had a much harder time but once observing it working, has a significantly more gentle time to optimize things and/or combine them into fewer scripts if that's what should be done to suite the particular platform better.

The nastiness that we can observe and that created the dreadened "script lag" is when an avatar enters a region and in turn that region gets a mini-stroke.

I'm not meaning to swoon about OpenCollar so much but this whole process and progress reflects extremely well in this device as it evolved from a hardliner unixy techno-hippy approach into an optimized and sophisticated sample especially for acolythes.

I also want to express here that I don't think it will cause less lag if a person wasn't wearing the one item that resembled an important bond to him or her on Second Life. Please keep in mind that only through this modular approach, it is possible to shrink down that "collar" to less than half a dozen scripts while still retaining the ability to beef it back up into a soaring, bleeding edge role play device. It's a good sample, I think.

 

[Qie Niangao]

---

Wendy Starfall wrote:

 

I'm not meaning to swoon about OpenCollar so much...

---

In fact I want to sing OC's praises a bit myself. I don't know all the details, but there was much wailing and gnashing of teeth in scripting forums when a recent OC version was released (6, I think?) that distributed the multiple scripts around different elements of the linkset. Again, I don't know details of that implementation, but in general that seems quite smart because it pushes the message dispatching down on the platform instead of inside the scripts themselves. That is to say, this avoids the problem that arises if all the intercommunicating scripts live in the same prim: every time any script sends a link message intended for another, all the scripts have to wake up and check whether they should process the message.

Also, just a note of agreement with the several responses in this thread about the impressively robust sim tolerance of scripts these days. It's still beneficial to only have the scripts you need, and for scripters to devote effort on efficiency and responsible resource use, but overall sims run remarkably well even when loaded with way too many way too inefficient scripts. The Lab developers deserve mucho kudos for that.

[Conifer Dada]

If scripts don't cause lag, why is it that when some anti-social landowner puts a dozen breedable horses on their parcel, lag gets so much worse?  It's not like the horses usually have particularly well-crafted bodies or detailed textures - it must be the scripts I reckon!  

Nnnniii-hi-hi-hi-i-i-i-haw-haw-hmm

[Qie Niangao]

It probably takes a site visit to inspect the details, but one thing I've seen in many breedables is just an absurd stream of object updates that lag anybody looking in their direction (but not the sim itself). Granted, it's scripts that push those object updates, so maybe it's slicing the point too finely to say it's not script lag... but it is kinda a different thing, and not representative of the kind of measures that avatars see when landing in a crowded sim.

(Although we're also pretty far from that OP problem in this old thread.)