Good Scripting Standards - let's formalize this

I'd like to propose that we scripters should band together and create a set of scripting standards designed to avoid lag. We could do stress tests to support our standards, and then people who agree to adhere to standards may some sort of "low-lag seal" that's endorsed by the group. Users could then look for the "seal". (or whatever form it takes)

The standards could be used as a basis for education of the scripting community at large.

Hmm, interesting. Ok, one example would be llDialog-based configuration, where, rather than having a continuous open listen, an object/attachment waits for its owner to click it and pops up a dialog. That way it only needs to listen while the user is interested, and it can turn the listener off after a minute or two.

What else is there?

Oh, here's a good one. A flashy color-cycler that doesn't use llSetColor() in a really short timer, but uses a texture animation instead.

Well, this is easy. Starting from the top:

1) Use llDialog systems whenever possible.

As Lex pointed out, here's an example for a one-touch media script.

integer g_listener = FALSE; // Listen Handler
integer randomChannel = 0; // Our random channel

default
{
    state_entry()
    {
    }

    touch_start(integer total_number)
    {
        if(llDetectedKey(0) == llGetOwner())
        {
            llListenRemove(g_listener);
            randomChannel = 10 + (integer)llFrand(100000);
            g_listener = llListen(randomChannel,"",llGetOwner(),"");
            llSetTimerEvent(20.0);
            llDialog(llGetOwner(),"Select an option:",["Play","Pause","Stop","Loop","Retexture"],randomChannel);
        } 
    }
    listen(integer chan, string name, key id, string msg)
    {
        if(chan == randomChannel)
        {
            if(msg == "Play")
                llParcelMediaCommandList([PARCEL_MEDIA_COMMAND_PLAY,PARCEL_MEDIA_COMMAND_AUTO_ALIGN,TRUE]);
            else if(msg == "Stop")
            {
                llParcelMediaCommandList([PARCEL_MEDIA_COMMAND_STOP]);
                llScaleTexture(1,1,ALL_SIDES);
                llOffsetTexture(0,0,ALL_SIDES);
            }
            else if(msg == "Pause")
                llParcelMediaCommandList([PARCEL_MEDIA_COMMAND_PAUSE]);
            else if(msg == "Loop")
                llParcelMediaCommandList([PARCEL_MEDIA_COMMAND_LOOP]);
            else if(msg == "Retexture")
                llMessageLinked(LINK_SET,0,"retexture","");
            llListenRemove(g_listener);
        }
    } 
    timer() 
    {
        llSetTimerEvent(0.0);
        llListenRemove(g_listener);
    }
}

2) Use texture animations instead of color-and-texture-flippers whenever possible.

See this thread for an example.



3) Reduce collisions whenever possible!

This is a big one. If you have an object that will collide often, create a "bounding box" prim around it (vehicles are excluded here).

Physics CPU is a precious resource. Many people squander it by making their furniture "physical." If it's not moving, make it non-phys.



4) Consolidate textures when you can.

Another biggie. Most lag in Second Life comes from handing off of data, and if you're using 50 bajillion textures for one script, you're not helping. Consolidate those textures, and use llSetTextureAnim, llOffsetTexture, and llScaleTexture as needed.



5) If your timers are faster than one second, you're doing something wrong.

Granted, faster timers are occasionally helpful - but not for scripts that are always out. Try to consolidate commands.



6) If your script processes the same data over and over, just store it!

Don't make it do the same calculations over and over if you know the result. Store the result and call it.



7) Use link messages instead of separate timers.

If you have several scripts needing a timer event, call them with a link message from a single timer.



Avoid listeners that hear all on channel 0.

Repeat after me. llListen(0,"","",""; Don't do it unless you direly need to.



9) Use multiple script buffers effectively.

Reduce the time needed to make calculations by multithreading. The sim will thank you when it needs less time to make calculations.



10) If you don't need it, don't leave it out.

This should go without saying.

Here's an interesting quote from eltee in this thread:



I'd love to see a discussion about "passive" object development including a definition of active versus passive. I've read a lot of this before, but somehow eltee's quote made me think that maybe there's something that I've missed in previous discussions.

Passive objects are ones which dont require polling the sim. This means:

Passive objects have no:
- Listens
- SensorRepeats
- Timers
- Spinlocks (while (TRUE))

Everything else is fair go however.

Scripterati!

This is great! I've been threathening to do more, but daytime and side projects have taken their toll on my desire to code. The times I have gotten some motivation, I was wishing there was a consolidated "best practices" list.

Thank you to you who are contributing. I think it'll give those interested in joining the scripteratti a good boost.

So, if it doesn't have these, then it doesn't show up in the count of Active Scripts?

Is there anyway to see the number of passive scripts (or total scripts) in a sim? Does the number of passive scripts matter? Seems like it should, but I've read varied opinions. Some have said that it just gets paged out to disk so it's impact is neglible.

The scripting community helping others find and reduce lag causing scripting practices is good.

Standards and seals of approval are bad.

- Ace

This is a good point. While everyone will approach the solution to their problem in their own way, some solutions are better than others.

I highly suggest people post their lag-reducing solutions here, preferably with code attached.

Im sure not a scripter but I do think this is a great idea..... I often ask someone with knowledge in scripting to check my land for bad scripts

Jeff made a mistake. wow.


wow.

Yes, everyone has a different way of approaching problems. I don't think this is trying to place rigid requirements on code. Hell, even if it was, how would you enforce it. I have enough of that with Sarbanes Oxley breathing down my neck during the day. How I was reading this is to present generally accepted/proven methods to reduce lag/improve performance. If I'm wrong about the intetions of this, I'd like to know.

A good example is the touch then listen technique. Just starting out, I had no idea that waiting for a touch has less of an impact then a listen. I have done some research, but if it is out there, perhaps i haven't done enough research (very well possible... short attention span). But maybe that shows how this is good. A list of harmful examples and some methods of working with all in one place.

At least that is what I was hoping, not forcing someone elses style or stifling creativity. If I'm wrong... SCREW YOU AND DON'T TRY TO STIFLE ME, YOU DAMN SCRIPTERATI!

"Fixed." Hmph.

listens DON'T pole the sim (and I can't say I've noticed much lag from Just listeners.

This said as soon as something is said on the channel with the listen all bets are off. Try to minimize open listeners on channel 0, try to avoid conflicts on other channels. And whatever you do don't ever communicate between scripts (in particularly often) via says and listens unless it really isn't avoidable.

and spin locks can be worse than timers and sensors (assuming the timer is set at a reasonable level)

speaking of timers, I've seen stats in the past about timers lagging the sim.. dose anyone (a) remember the stats and (b) know if the stats are the same now (since I saw this back in 1.4.. (I'm interested in non firing timers here thus I'm looking for the lag of lets say 1000+ scripts with llSetTimerEvent(multiple day time out); while they are all waiting for the time to arrive..)

the results of the timers aside remember a timer is practically negligible compared to many other tasks, so use them rather than looping for stats.

I advise you to check your facts here.

-Adam

Actually, I wouldn't mind if a Linden would post those facts. Listeners and polling sims have been subjects of fierce debate.

By merit of becoming "active" when a listen is added, it follows that the sim treats things differently - but I have yet to see "official" notes on this posted.

No matter. In general, I avoid listeners in my coding as matter of habit.

Active pretty much means what is says: It means the script is being actively interpreted by the LSL VM. Passive means nothing is happening right that moment.

-Adam

Why on earth are we scripters trying to consolidate a set of "rules" about scripting to follow, instead of hacking at the REAL problem, which is Linden Lab's servers being unable to support many timers or color changes or lag producing problems? Why are we forcing ourselves into submission when it is we scripters that make this game come to life? If you all want to band together and do something, it shouldn't be forcing yourselves to conform. Make Linden Labs "fix" scripting. Instead of fixing login and teleport issues, why not fix some scripting issues?

It seems that time and time again scripters get screwed all over the place. Why are we letting this happen?

Edit: On another note, there have been numerous lag "studies" conducted all over the place, with incredibly contradictory results. Its useless to argue that a timer is more laggy than a listen. Its all subjective to the sim, and whats in it. Sometimes sims are laggy for no apparent reason, with nobody in them. Who knows what causes lag, but saying "You're wrong! Listens are more harmful than timers (or whatever)" doesn't get us anywhere.

Because, for starters, efficiency is a good thing. Given any amount of finite resources, you can always do more if you know what you're doing in the first place.

Moreover, Linden Labs employees happen to be human beings, as we are. If we don't help make their lives easier by learning, we'll face the same problems time and again instead of overcome them.

While you have a point - particularly that we should be pushing for new features and support - it stands to fact that we deal in finite resources, sim by sim. If we don't learn to manage them, we reap what we sow.

We are getting the update to the Mono VM later this year hopefully which will fix a lot of the efficiency issues, but part of this is being a good neighbour in regards to using your fair share of resources.

No, no-one can argue which is more laggy, a timer, a listen or sensorrepeat, but what we can say is that those three functions do seem to make scripts permenently active, and what else we know is that active scripts are the ones that matter in terms of eating sim resources.

Really it needs to be in moderation - no, no-one should dictate how another codes. But some efficiency guidelines, helping avoid common mistakes might not go too far astray.

I'd personally recommend people read Lee Linden's post on lag before speaking on the subject. He's pretty much accurately hit the nail on the head for each and every point.

-Adam

For those that missed Shack's post, Adam is referring to this thread. And I think we are very much in agreement.

The "gods" have spoken. You may commence laughing hysterically.

Efficiency is key. Write bad perl/php/mysql/etc, and you can bring an apache server to its knees. If we are going to share the servers, lets make an effort to not crash/lag them on each other. It's more productive than pointing the finger at LL. The servers may mature, but we'll still be sharing resources. Some of the suggestions in this thread are good. Perhaps an efficiency wiki is in order?

Controls -

BAD: keep checking the same control over and over
GOOD: when you can, disengage your control event and/or use edges

I bugreported this to LL and never heard back, I'd be interested if some other folks could corroborate it.

1. The "Active Scripts" count ignores scripts in child prims within linked sets.
   

This renders the "Active Scripts" metric wildly inaccurate in certain situations, and any guideline stating that "X number of active scripts means Y" doesn't really hold water.

It is worth noting that the "Active Scripts" counter on the debug screen updates every 60 seconds.