Monday, January 1, 2007

A Polite but Stern Warning to all Wearers and Makers of Bling Jewelery

I have a message for anyone who wears or creates Bling-effect jewelery in Second Life.

Amatur Scripters created the popular bling scripts with the option to issue a chat command, such as "Bling Off" or "BO" which turns the shiny particle effect on and off. This script creates a small amount of constant lag, and every time it is copied into a seperate prim or object, the lag is increased. This stacks and is considered one of the greatest non-intentional causes of lag in SL by myself and several of my fellow scripters.

Now let me explain what you can do about this problem. First of all, turning off the 'bling' does nothing. As long as the object is attached to your avatar or in the world, it is causing lag.For a start, please take off any Bling jewelery or other decorative object that recieves chat commands. Some tools and equipment need chat commands, but not jewelery and other decorations that you would wear all the time. Also I ask you to only purchase jewelery and accessories that don't use chat commands. It would help out everyone if you would do this.

The last thing I can ask everyone here is to spread the word of this problem in SL. Most people don't know this, even most amatur scripters are oblivious to the problem. Advanced scripters like myself tend to be reclusive, which makes it hard to get the word out. Please carry this message to the clubs and malls for me.

Now I'll take a moment and explain what I'm talking about in scripting terms, for the scripters who want to make low-lag bling jewelery and similar scripts. I'll also try to explain alternate methods to make your scripts less laggy.

First let me explain how this causes lag. Chat commands depend on the llListen() function and the listen() event to function. A script which is listening accepts every line of chat spoken in range of it and runs it through a procedure to determine if it is meant for the script to hear or not. Even if it is not meant for the script, the script must analyze it to find out. This costs processing time, and creates lag.

Now I'll offer some solutions to this problem. The most direct way to prevent this lag is to not use the listen function in the first place. If your script has only one function, you can use the touch_start() event to switch between on and off procedures.

If you must use chat functions, there is another technique I can reccomend. The llListen() function returns an integer variable. This variable is called a 'handle' and if you save its value to a variable of your own, you can pass that value to the function llListenRemove() which stops the script from listening. This stops the lag, but your script can nolonger hear chat commands. I use this in many of my scripts that use the Dialog box. When someone touches my scripted objects, the llListen() event starts listening, but a timer is ready to shut it off if a user gives a command, or if they haven't said anything for a minute or two after touching it.

Finally I'll tell you about the llMessageLinked() function and Link_Message() event. Some people use listen and chat functions to communicate between several scripts. If you have several scripts on the same object, however, you can use the llMessageLinked() function. This function sends a message to one or more prims in an object set. This message triggers the link_message() event in all the scripts in the prims that are messaged. Because this event only triggers when a message is sent directly to it, it doesn't cause lag like the listen events.

I hope that everyone who reads this will remember it, and pass it on to others. We can work together to make Second Life a much less laggy place.

You are aware, of course, since this thread is so old that particles don't cause any lag on the server because they only exist in your client AND you can turn particles off in your client. Particles run in your viewer only - not on the server side.

Anonymous on April 15 - he didn't say particles caused lag - he said llListen causes lag. And it does put a tremendous amount of lag on the server when issued with no other commands. Another anonymous was correct by saying add a channel - meaning a private channel. llListen is idle when there is no public chat. When there is public chat, however, it attempts to parse every initiation string to see if it matches the command it is listening for. Put 100 of those on an active sim and you're asking for lag. That's all ;)