how laggy is it to use chat functions?

I am working on a simple game of tag to teach myself LSL. I have heard that using chat channels for communication can be "expensive" in teerms of lag, but I am wondering if this means:

"Chat commands are super laggy! Do not use them unless absolutely necessary!"

OR

"chat commands are fine if you take reasonable precautions."

If chat commands are of the devil, what do people use instead, assuming objects that are not linked need to communicate?

On a related note, is it less expensive to parse a list than a string?

Thanks!
SJ

heyas;

some basic guidelines:


open listeners are evil.

open listeners listen to everything everyone says on channel 0. (avatar chat channel.)
use this only for novelty things like pets that respond to things people say.


listeners on alternate channels are less evil.

these channels have less chat traffic for your script to parse. many items use easy-to-remember channels to receive commands from their owners, so if you use like 1, 2, 7, 13, 99, or 666, you could get some traffic.

note: you can use larger and/or harder-to-remember numbers for commands if you include in your package a gesture that translates word commands (ie: /neko * to /897346 *).


filters lessen evilness.
these are the name/key/string filters that you can pass to the llListen. there have been various threads discussing front-end filtering vs back-end filtering.... its all murky to me, i shouldnt try to think about how scripts actually function... :X

but, if the listen should ONLY listen for the owner, use the owner's key. if it ONLY has one command, put that in the message filter. if it ONLY listens to another object, put the objects name. (or use llRegion say, maybe?)



also, when using objects that talk to each other, you can use negative channels. as i understand it, avatars cannot speak on negative channels (even if its a menu button). so there is only script chatter down there.



did that help?

Avatars will speak on negative channels via dialog button presses.

Here is what I am doing at the moment, using a negative chat channel and sticking to llSay and llWhisper with the occasional shout needed if necessary:

person A clicks on person B's title thing

person b's title thing says: "person A clicked on me, my owner is person B"

person A's HUD sees the message and knows it is owned by person A.

Since the message starts with "person A" (their UUID), it knows this is a command it needs to process


How bad is this? If 20 or 30 people are playing tag will I crash the SIM?

SJ

20-40 listens shouldn't be too bad in and of themselves. What does matter is the scripts themselves and whether they are laggy or not. You can get a halfway decent idea of how good or bad a script is by going to a new deserted island somewhere. Take a look at the script ms and then rez 40 copies of your huds and watch the time.

Of course it is really nice if you have a freind with an island that gives you estate manager status.

For one thing, a game like this won't be used all the time, like poseballs at a beach. So, you can get away with less than ideal practices and not be the scourge of SL. Nonetheless, let's see the best we can do.

First, I'd use two states, one for "it" and one for "not it". Only the "not it" state would need a touch handler. The trick here is to figure out who starts out as "it". More on that below.

Second, the object can change its name to owner's name, perhaps with a suffix, e.g., "Lear Cale's tag". Then, when it chats, it doesn't have to say who got touched -- that will be clear from who does the chat. I'd use something simple and clearly visible, like "JANE DOE is IT! *****". Which would look like this:

Lear Cale's tag: JANE DOE is IT! *****

or simply:

Lear Cale: JANE DOE is IT! *****

if you don't use a suffix and just se the object's name to the owner's name. In either case, the text will be a different color, so folks will know it came from an object and not the avatar.

Third, I'd have the object chat two messages, one on channel 0 for avatars to see, and the other for the tag scripts to listen to, on a separate channel, and saying only the name of the avatar who is now "it". This way, only the tag objects hear these messages. More importantly, the tag objects hear ONLY these messages. Script lag from chat happens when too many scripts get run at the same time, due to lots of objects processing each line of chat. Let's avoid having the tag object process the avatars chatting normally and let them focus on messages from chat objects. These will be quite rare -- they only happen when a new person becomes "it".

OK, how to start the game? I suggest simply chatting on the "tag" channel the person's name:

/123 Lear Cale

Every tag object will process this, but only mine will recognize my name, and it'll go into the "it" state. The others will stay in the "not it" state, and save "Lear Cale" as the "it" person so they know when they get tagged by me.

On rez handler for "it" state should go to "not it" state, and "default" state should just go to "not it" state. (Or it could BE the "not it" state, but I find that it's best to leave default state pretty much empty, for use for special features relating to resetting, reconfiguration, or script upgrade.)

Are you going to change the object's appearance for the one who's "it"? I think I would make the object be a cylinder a bit larger than a torso, nearly invisible, and worn on spine or something, so folks can just click on the av's torso. And I think I'd color it a bit for someone who's "it". Perhaps bluish tint for "not it", and yellow for "it". (Most color blind people have a hard time distinguishing red and green, but not yellow and blue.)

Finally, a note about lag. Scripts don't cause physics lag, where things respond slowly to movement. They don't cause display lag, where the display frame rate goes down. (Physics lag can look similar, because both cause jerky movement, but once you've seen display lag it's pretty obvious that it's your display with a low frame rate -- things keep moving you just miss seeing it.) Scripts cause other scripts to run more slowly, so for example, it takes a poseball a long time to seat you after you click "sit". Scripts *might* cause chat lag, but I've yet to test this. I'm just mentioning this because I see lots of people talk about lag with no understanding of the causes and effects, and many tend to blame everything on scripts and neglect to notice the impacts of their 500-prim flexi hair.

If you avoid an "open listen", your script will be the least worry for lag when getting 20 to 40 avs together for a game. Even with an open listen it probably won't be a major problem, and even then only when playing tag. We worry more about objects that are numerous and permanent, like poseballs. Still, best to avoid the open listen and learn good practice!

Let us know how it works out. Good idea for a starter project, and sounds like it would be fun, too.

Jesse -- I didn't know about this. Does this provide access to the sim owner's tools? Any more you can say about this might be a big help to me. Thanks!

Parsing lists vs. strings -- it depends on what you're doing, and hard to make generalizations. In general, though, it's *easier* to work with lists. But I'd structure your program so that the only thing you'll need to do is test two strings for equality.

Being an estate manager lets you use all the tools available on the World -> Region/Estate menu, which includes looking at Top Scripts, etc. Keep in mind that particularly for that menu, the script times fluctuate drastically, and also depend on the sim hardware, so comparing performance of the same item in your sim and in a neighboring sim may not make sense, scientifically.

About lists versus strings.. Lists are far easier to work with, it's true. Still, programmatically speaking, you want to avoid doing iteration on large lists just because it still blows and slows you down. Built-in functions that iterate a list like llListFindList are very quick, though, and extremely useful. However, it's possible to achieve the same results entirely using strings, depending on how you set it up. For projects with larger data and memory usage, using lists will screw you hardcore. The amount of memory wasted with lists is extremely unfair, so if you can use a large CSV string or something instead, it's probably to your benefit.

Yep! Estate Managers have access to the same tools the sim owner has.

Wish I had an island owner friend!

Gearsawe Stonecutter and I were working on the prim drift problem for a couple of months(see announcement in Beta Forum). Milo Linden graciously made us estate managers on an island in Aditi for the duration of testing. It was wonderful!

Many thanks for all the suggestions and great examples! Although more than one person will be "it", I can still use Lear's idea and avoid parsing each line of chat. Thanks again!