llListen

Hi everyone,

I'm scripting my vehicles and houses to handle multiple voice commands. In terms of minimizing server lag, is it better to do one general call to llListen with "" as the filter, or set up individual llListen with a filter specific for each command?

With no filter, the server is going to send an event for everything I say when I'm within normal voice distance of the object. However, if I have 10-15 voice commands, I'd need to set up 10-15 listen commands with specific filters.

Alternately, I haven't experimented enough with the listen function/event -- does it do wildcard-type filtering? Should I only do voice commands on a non-zero channel and not use a filter?

- Jon

From my understanding of things, it would be much, much, much better to have one llListen() on a non-zero channel and to filter in your listen() event than to have multiple llListen()'s and/or to llListen() on channel zero.

I would assume that was the case, but many of the vehicles I have seen clearly use channel 0 for voice commands, so I was wondering if they just haven't considered this, or if there is a way to handle it without causing undue server load.

- Jon

My vehicals usally need to be touched before they start to listen and then stop listening about 30 seconds later. My newest one starts on channel zero and will switch to whatever channel the owner picks and when touched IMs you it's channel it listens on.

First of all, filtering doesn't do much to reduce lag. Whether SL itself filters every potential listen event or if you do it in your own code doesn't make a lot of difference. So setting up multiple listens means extra lag even if they're all filtered.

Using channel 0 is the laggiest option because of all the traffic that goes through it. Using llListen on a high channel and doing your own parsing is really the best option.

llListen(1, "", NULL_KEY, "");

...

listen(integer channel, string name, key id, string message) {
     list msglist = llParseString2List(message, [" "], []);
     string command = llList2String(msglist, 0);
     list arguments = llDeleteSubList(msglist, 0, 0);
     if (command == "door") {
          if (llList2String(arguments, 0) == "open") {
             door_open();
          } else ...
          ...
      }
}

Then, of course, your commands will look like "/1 door open". That's about how I usually do things.

Some scripts are just designed badly. Either the designer wrote the script before we were able to chat on multiple channels, or they don't know we can, or they think that it's important that the user spam channel 0.

Having to filter out chat is less efficient than not having to, but honestly, it's the spam that annoys me. It's a good idea to do ALL your input on a higher channel (note that channel 1 is probably not good, either) and then (as of later today) use llOwnerSay for the output.

You can bundle gestures with your object, as well. One could then type "/speed" and get "/4096 speed", for example.

Hey John,

I think you're probably best off doing this yourself using something similar to kali's method. The best-case scenario for server-side filtering can only ever be equal to what you can do and the overhead of looking up the action listener call-backs is tiny but for something like a large-audience game you would save overhead.

Sorry for bringing a bit old thread but I'm afraid of repeating such as the above discussion again.
What I'm interested in is the string filter of llListen. Talking of the channel or key filter, in my understanding, the script doesn't listen to the command unless it is filterd out.　Then, what about the string filter?

1. llListen(0, "", NULL_KEY, "on");

.....

listen(integer channel, string name, key id, string message)
{
    //Do what you want
}

2. llListen(0, "", NULL_KEY, "");

.....

listen(integer channel, string name, key id, string message)
{
    if(message == on)
    {
        //Do what you want
    }
}

Is there any diffrence between them? I guess it doesn't listen to anything until someone says, "on" in 1, but it would listen to all chat and always judge if the condition is true or false in 2. Am I right? If so, 1 is much better than 2 even though it would be multiple listen, isn't it?

Hi Seagel,

Honestly, both are pretty bad as they will listen to all chat by all agents on channel 0. #1 is particularly bad if you keep spawning multiple listeners and never destroy them.

You may want to look at the LSL Wiki entry for llListenRemove(). Any time I have a script that listens for input on channel 0, I usually have a touch event create the listenener, and then destroy it after I have run conditional checking insider of a listen event.

You can also use the timer event to destroy the listener after a reasonable period of time, just in case someone is bashful.

Hope this helps.

Thank you, Numa.

But bringing this old thread means that I know what they discussesed.
Now I want to know how I can use the string filter. You said, "they will listen to all chat by all agents on channel 0." Does this mean that we cannot use the string value as a filter at all? Please clarify this for me. Thanks.

Hi Seagel,

Yes, you can use the string filter like that if you're listening for one command, but...

Your script will listen to everybody and then send a request to the server to filter everything it hears (if I understand listeners correctly). In areas that have a lot of chat, this can take hurt sim performance because it's trying to filter all the chat. With multiple filtered listeners, the problem increases.

I believe it's more efficient to use a single listener and filter through with if-then statements (like your example #2) than to setup multiple listeners with string filters (like #1).

If you combine that with only creating a listerner when needed, and destroying it as soon as you don't, it should not effect performance too much.

Hope this helps.

If the filter means like that, what about the channel filter? Even though I set the channel as "-1234841899887", would it liten to everybody and then send a request to the server to filter everything it hears. And finally does it realize that it is not the channel to listen to?

Thank you. I know it is so kind of you to let me know about that.
But I know what the channel 0 means and I often use llListenControl and llListenRemove. I just want to know how to use filters here.

Seagel,

I believe the method of having an open filter (provided it is on a quiet channel, as you already know) is the best way to do it. Each listen with a string filter is going to STILL be filtering, just in a different way. So 10 listens with different string filters are going to be far more sim intensive than 1 listen with some "if" statements in the listen() event. The only case where this *might* not be true is on channel 0, but in that case it isn't that one is better than the other, it's that they are both just bad (and yes, I know you know this. simply saying it for anyone else reading who may not).

Also, something I think helps when you are doing an open string filter and using "if" statements is to include returns to avoid redundant filtering. For instance, including a quick test to see if the input is of any worth can help you avoid running your entire listen event if there is no need to. Basically if your listen event is done don't make it continue to check it's input.

...and of course that could just be some goofy thing i do that i think helps and really just wastes time. Neuroticly stepping over cracks in the concrete as it were.

Does restricting the llListen to the owner improve performance?

handle = llListen( 0, "", llGetOwner(), "" );

I should have read this thread first.