LAG BUSTERS: Tips & Strategies

I know Ferran and I are not the only ones who want as little lag as possible where we live and where we vend. We know some strategies and I bet there are others out there. Please contribute with ways to cut down on lag.

I'll start.

256x256 textures for boxes and vendors. They rez super quick, often quicker than the build they are in. Our number one strategy for lag cutting.

Surreal

heck, you can get away with 128x128 textures on alot of stuff too. hit it with an unsharp mask at 50% and it will look better smaller.

use smaller images for particles. if i need a single particle i never go over 32x32. for alot of particles try putting more than one in your image. if you have an image with 5 raindrops in it that means you only need 1/5 as many particles in the world.

get rid of listens in your scripts. do you need to talk to the object or could a click work?

get rid of timers too. sometimes you can get by with llSleep instead.

make stuff you or someone else can click to turn off when you leave so your neighbors don't burn your house down.

listens:

Don't get rid of them, just move them out of channel 0! If you filter by a higher channel then it won't be triggered unless you speak in that channel.

textures:

- reuse where possible
- jpeg compress anything not transparent to about 70% quality - usually you can't tell the difference

The wiki is your friend, and has a good discussion on lag here.

- Ace

For the love of all things holy... don't use setTexture or setColor on a .01 timer when you could spend 10 minutes being a little creative with making a texture and use llsettextureanim instead. This seems to be a recently growing problems with signs and backgrounds in malls. One of my biggest SL pet peeves. If you want help doing this I and many others I'm sure would be more than willing to help out.

As far as listens go, I like being able to issue a variety of different commands on channel 0... so what I do is link the listen to the touch_start event and give it like a 30 second timeout.

A couple of other things.... really think about how often you need certain things to update. For instance, do you really need the online indicators you have all over the world light up green the instant you sign on?? Maybe you could change the interval to one or two minutes. Do you really need that visitor counter to check the crowd every 5 - 10 seconds or can you get a pretty good count if it only checks who's around once a minute?? Little things like this reallllly add up when people aren't using them responsibly or understanding the effects they have... it's like script pollution or something.

-Meiyo

Do you think a "lag free" Marathon would be useful, or even possible?

Educational events talking about lag free tips like these, also set up a list of voluntary locations (malls, clubs, stores, homes) where a small group can go and inspect and can offer specific tips as to how to reduce the chances of lag for that site. I think the results could be very interesting to measure.

There should be no difference between a timer or a sleep. For example, in my rental scripts, I update the info display every 5 minutes and send an email to my server every 30 minutes. I use a 5 minute timer to trigger these events.

An llSleep(1) and a timer set to fire every 1 second should make no difference to server side lag. If it does, LL needs to fix the problem on the server.

Here are some basic rules our fearless anti-lag fascist ::coughflippercough:: devised for our store in Indigo:

Here are our basic rules:

1. Scripts. Any scripted object using LISTENERS, TIMERS or SENSORS must be approved by the staff. If you're unsure about a script, do NOT use it until you have checked with FlipperPA Peregrine. If you're not a scripter, make sure you check every script with staff first. For VENDOR scripts, be sure to check with us first. We may have a better vendor script you can use. Its activated by TOUCH that do not use a listener, timer or sensor in conjuction with the touch function are typically OK.

2. Space. Refrain from over stepping your space or ruining the ambiance of the store. This means, stay within your allocated wall space, or up to 1.5 meters out from the wall. Please do NOT place signs on the floor to garner more attention, or everyone will want to do it.

3. Light Objects. NO LIGHT OBJECTS CAN BE USED AT ANY TIME! These create major lag on the client side. Again, if one person uses one... EVERYONE will, killing the effect, and creating a LOT of lag.

4. Particles / Rotating Stuff / Sounds: NO NO NO.

5. TEXTURES. Texture sizes have to be maintained carefully. Yes, you may give up a little bit of detail, but a 512x512 texture takes 4 times as long to load as a 256x256 texture. A 1024x1024 texture takes SIXTEEN times as long to load as a 256x256. Therefore:

- ALL OBJECT TEXTURES FOR ITEM BOXES MUST BE 256x256 OR SMALLER!
- You may use ONE 512x256 texture for your sign / billboard that goes on the wall.

this will improve EVERYONE'S shopping experience, and the performance of the store for ALL vendors involved. We're a team here; don't forget that. Only by working together can we avoid lag; if you don't believe this, just check some place that doesn't have these rules, and enjoy selling in their 3-5 fps area.

I'd say that this sounds like a good idea to me. Even something as simple as a spot with a notecard at every mall entrance, explaining such tips, would be nice! Myself am currently in the process of reuploading my textures and proceeding to some vendor resizing, because, well, being the still half-newbie I am, I didn't know all of this when I started selling my clothes And I must say, I can easily see which ones take the less time to load now. (Oh yes, and the JPEG tip; how many people do actually use TGA for vendors just because they don't know better *looks at Hiro and blushes*)

And there is none.

A question about reducing lag by not using listens. Would the following code:

integer listen_id;
...
llListenRemove(listen_id);
listen_id = llListen(0,"",llGetOwner(),"");

...make a difference?

Not exactly.

That should be done *anyways*. Multiple listens for no reason is A) a pointless waste, and B) can cause problems with your script.

What that code (Or other varients) does is ensure that you dont re-initialize the same listen function over and over again.

It *could* help system performance, *if* someone has been doing something to cause their listens to keep initializing, but in and of itself it doesnt effect the performance of a single listen.

His Grace did some really cool research into lag in this thread

I added a bit of code to the Timer events in OSMP. I'm not sure if SL uses the same method but each "timer" is registered in an array when it's created, then at each timeslice, the server will check if any timer events should fire. When your script is stuck in a while loop with sleeps, that thread will never get the timer events, but the server will still spend time checking to see if it's time events should fire. So I don't see how a sleep could be less laggy than a timer.

Is this actually true? Prior to 1.5, all chat went into a big buffer, regardless of channel. The lag induced by listeners was because all listeners would crawl the buffer to see if there was a match on the listen filter.



It doesn't matter what form you upload stuff at at, be it .tga, .jpeg or .bmp. Your images are all re-encoded in JPEG2k.

It only matters by what code is in your listen() event. If you have MASSIVE amounts of code in your listen that fire every time someone speaks, then yeah, it'll cause lag when someone speaks. If you have just a few if statements, the difference between llListen(0 and llListen(200000 is near-zero.

Some Aimee tips:

Learn to hollow and cut objects in place of using multiple prims that form right angles to each other. More than learn...make it your religion. This trick can turn a 100 prim house into a 25 prim house with almost no loss in detail. Thank you Flipper for showing me the way on this one.

Think about texture reuse. I recently built a train car with a side texture that featured a window and a corrugated lower portion. When it came time to texture the rounded roof, I used that same exact texture, but adjusted the repeats and offset so ONLY the corrigated portion was showing. It looks nice and viewers need only load one texture.

Learn ALPHAs. I see alot of builds that are prim-heavy simply because the builder doesn't know how to make a section see-through. Examples: Picket fences that use a prim for each picket, detailed prim window, etc.


All that said, I think people need to strike a balance. The most lagless environment is a sim free of prims, textures, scripts, and people...but what fun is that?. At Midnight City we complain about lag the way RL folks complain about the weather. It's there..it varies from day to day.. but it's the price we pay for rich beautiful content. Dwell helps us gauge our balance between lag and features, such that if dwell goes down, we adjust the plan. Your results may vary

-aimee

Aimee you rock lol I couldn't have said it better. I do try to implement 256x256 for our higher volume retailers *cough* me and tor--
but no. I wont sacrifice beauty and fun for lag-free...
My basic rule is if I turn on updates and see server hits that's when I'll have it removed. Oh, and Seburo (The greatest gun in the world) wars allowed ONLY 200ft or above!
I don't think I'm too strict...

add to this the note:

Do not set your land to block everyone.. you destroy your neighbor's alpha windows, fences, ect. (fortunately I don't have this problem at the moment.. but have in the past)

except one happens once hank, the other happens 3600 times an hour

the biggest way to combat lag with scripts is have objects go *IDLE* when not used.. this is not mearly jus not saying/doing something.. to be idle, a script must be in a state that has no timers, no listens, no repeat sensors, etc.

Touch triggers can still be used. What i often do with my particles, is have them touch to turn on for awhile... they rest in state Idler, then when touched go to state Running, where all the real code is... the running state has either a 1800 second timer, which reverts it, or an accumulator in its existing timer should there be one to half an hour, after which it returns to the idle state.

Not every script can be thus modified obviously... but alot of them can... and honestly do you *REALLY* need your 0.1second timer color changing 100 grid dance floor running... when theres nobody around to actually be 'impressed' by it? probably not

hey good stuff! i got a big project i'm working on and i just learned a ton of stuff to make it more efficient. i have a listen that listens for commands from a llDialog and i just realized i don't need it listening all the time. i can call llListen when a click turns on the llDialog and get rid of the listen when the menu's done. and the big fat gang of if's the listen event uses can use returns to keep from going through the whole list. thanks for all the tips. i love the idea of idling scripts.

I've been talking with a few other people on doing regular workshops to help minimize lag in shopping areas. A lot of people don't know that large texture sizes create lag, I sure didn't until I was told so.

I compress my jpgs!
But I like lights & spinners.
I suck.

Do different textures on each side of a prim cause lag? My place is texture intense, but I do use 256x256 on most of them. And is there a way to turn off and on all particle emitting scripts in a plot?