which is better? 2 specific llListens or 1 all purpose llListen?

which is better?

llListen(0,"","","command1");
llListen(0,"","","command2");

or

llListen(0,"","","");

ie. is it better to have 2 llListens listening for specific commands or should we have the script run the listen() function for every sentence heard?

Psyke.

listen on a different channel maybe?
or listen to a specific user...

wow Sio that was fast!!

in this case I was thinking of the script wanting to listen for 2 specific commands from normal chat.

So the question is what uses more resources.. having listen() run for everything in chat or having 2 llListens for the 2 specific commands.

I may be talking outta my backside here, but wouldnt you need a conditional in the single listener event that handled the first example anyway? I tend to go for the second because of that, unless, as Sio says, I want the listener or channel to change.

in either case the conditional has to run in listen() since both commands need to be differentiated. This question has nothing to do with channels. A poor example is those ball seats that have "show" and "hide" commands.

llListen(0,"","","show"); //<-- these only run listen() in 2 specific cases.. but twice the resources or not?
llListen(0,"","","hide");

or

llListen(0,"","","")  //<-- this runs listen() for every chat heard!!

both will require:

listen(...) {
if (message == ... etc etc

One all purpose listen is always better than multiple listens, specific or otherwise.

Even placing a listen on a seperate channel does not improve things in any way. The fewer listens you use, the better. Always.

Agreed it doesn't help the listen-lag, but it at least it saves it having to process all the channel 0 chatter whenever two or more avs are near it.

Some of us chatter on channel 0 even when there is only one AV present, tyvm. I like to think of it as conversation for the introverted, but my doctor disagrees.

scary. I do that too. I have been known to shout at prims.

Hmmm... I always knew there was something odd about Mal.

(and Kris, lol)

Proper use of if() statements reduces processing time for each line of text spoken to hardly noticeable (or not noticeable) values.

The ONLY disadvantage to using channel 0 is the spam you create when you do so.

Granted, but you are assuming good rogramming practices here. You *know* how many badly made scripts are out there... well, to the nearest thousand or so anyway.

you're awesome Kris. i've had times when i've stripped the default texture right off a misbehaving prim. sometimes they need a firm talking to.

i vote for one llListen and sort it all out in the listen event. it's just neater that way.

What research have you done or read to back this up?

I don't mean to be a bitch, here, but my gut reaction is that it'd be more efficient to have two separate but specific listens than one blank listen. The reason is that, while the sim has to compare everything said against those two listens, and this means more server processing, a blank listen requires LSL script to be run every time something is said. My guess is that the code to check two listen criteria in whatever language the server is written in will be quicker than all of the setup, event creation, context creation, variable creation, and script-running that's necessary just to process that little "if" statement that ends up ignoring almost everything anyway.

I don't really think it's possible for us to test this, I think we'd need to hear from a Linden on the dev team. We've both got logical sounding arguments.

two listens runs the check code serverside twice. one listen runs the lsl script once.

The good: llListen(50000, "", llGetOwner(), "";
(or another channel, llGetOwner if only listening to the owner)
The bad: llListen(0,"","",command);
The ugly: llListen(0,"","","";

But make sure the logic of your code handles change of ownership!

With regards to the resource usage question... How about doing an experiment for us? Without an experiment we could speculate on this one forever.

In general (and you all knew it anyway):

1. Your listen event handler will process/parse whatever input it gets. This takes time (although we are not talking large units of time here).
2. It's more resource friendly to filter via llListen() parameters than to let the events fire on many scripts.
3. Sometimes the script just has to listen to everything, and that's OK.
4. If the solution permits, you have the ability to remove listeners if they are unused. eg. Touch for command mode, Touch again to disable command mode.

If you find you're in a position where you have choice and time, try take the resource-friendly options.

I remember the scripted objects exhibition, there was panic that all those scripts would bring the simulator to its knees. Guess what? Lag free. I think that says a lot for our good scripters of SL.

I compared the SimFPS between when I had one object with one Listen, and one object with two listens. The impact was doubled with two listens. The filters did not matter in the slightest.

One llListen is ALWAYS better than two, and there is very little difference between a listen with filters and a listen without. The only time that difference appears is when someone actually says something, and that only lasts mere moments, and is pretty much imperceptible to us all. Proper use of if() statements (such as enclosing the entire code chunk inside the listen() event in one that the speech MUST pass) reduces this momentary impact even further to something equivilent or less than a single partial object update.

Since the code within the listen() event actually gets used far less often than the actual llListen() itself (using llListen() impacts SimFPS, even without anyone saying anything, and there is far much more time where people AREN'T talking than when they are... say... a ratio of at least 120:1, time wise, if not something more like 600:1 or 6000:1), it's far more important to minimize the impact by llListen() calls than listen() event code anyway. Lessening the impact of listen() code is always preferable to NOT lessening it, but your first priority should always be the reduction in llListen() calls.

My (relatively unschooled) understanding of it is that:

two llListens means two sim-wide subroutines (or whatever the technical term is) running *all the time*

one llListen means only one of these things running *all the time* but adds only marginal conditionality in parsing within the listen event itself (it's really not much, just an "if" and an "else if" if there are only two commands you're listening for)

so maybe the solution is contextual:

if your script is running in a quiet sim where you just want to do something like open or close a door or sit or unsit, one llListen is probably fine, since it will only rarely call the listen event, where the parsing/processing time is marginal anyway.

if your script is running in a place where there's a lot of Channel 0 chat going on all the time (Tringo, anyone?), it might be better to suffer the slight additional constant drain on resources that two llListens implies in order to avoid calling the listen event every second.

which leads me to the logical next question:

why isn't Knuth a last name in SL?

I'm going to use a firm tone of voice here - not because I want to berate anyone; but because as SL grows in popularity and complexity, this is a very very important concept!

The bottom line is this:

Listens on Channel 0 are almost always a bad idea!

A listen on channel 0 means your dratted object is going to be slowing the entire sim down every time an Avatar opens their mouth anywhere near your object! This is not only inefficient, but "selfish" - the idea that your builds are somehow important enough to justify slowing down everyone else's experience...

And as Moleculor puts it: 2 Listens will effectively double the load - because now every chat message has to be parsed twice, to see if it should fire off the "listen()" event. Your code may not execute twice - but the Linden's "llListen" code does have to, to check whether or not every statement meets the criteria - for each and every listener within hearing range!

All of your "llListen" statements are going to all be processed in one "listen()" event.... So even if you do listen for 2 different commands with 2 different listeners, you're still going to have to have an "if"statement in your "listen()" event. Why not eliminate the seperate listens, keep the "if" statements you would have used anyways, and lighten the load with only one "llListen" call?

Its a simple matter to type "/50 do_something" - to talk on channel 50 to your scripted object. So there's no reason not to have your scripts listen on non-0 channels. If you want new owners to know how to use their object, give them a Notecard when they buy it, explaining what channel to use for commands.

The ONLY reason to listen on channel 0, is if you want your object to "pick up on" conversational cues from Avatars around it. Any "direct commands" to your object should be done on a NON-0 channel. Period.

Thanks for your attention - hope I didn't come across too harshly!

Take care,

--Noel "HB" Wade
(Tread Whiplash)

*breaks out into applause*

What about a Listen in two separate scripts, either of which would linkmessage the command control script?

In this setup, you eliminate the IFs. . . My impression so far has been that specific listens are faster - my thoughts being that the listen event fires only when the command is heard as opposed to firing the listen event every time something is said and then deciding if the listen event should have been fired at all.

I imagine I'm about to get pummeled

One listen in two scripts link messaging will still be two listens, plus the extra processing to pipe through linked messages, which may or may not be less efficient than if/else blocks. However, I really think people are over rating the damage listens cause a bit. As my own tests and tests by others (such as Francis) have demonstrated in the past, listens really don't cause huge damages. While channel 0 is more inefficient, and will cause the listen() event to trigger more often, even with 100's of open listems the FPS barely dipped when the channel was spoken on. As far as the bit of a tirade about the evilness of channel 0, yes, it is not efficient. However there is also the aspect of user friendliness. And to declare any use of channel 0 as being completely unexcusable and selfish is a bit off. With that logic, that channel 0 effects other user's experience, perhaps we should limit textures sizes to 32x32 rather than some builds with massive amounts of textures. Perhaps everyone should just completely remove their attachments. It is relative... Discourage use of channel 0, sure. Educate people on the harm, sure. Claim people are being outright selfish, nah.

"Everything in moderation, including moderation."

My contention is that textures affect users less than channel-0 listens.

Why? Because once you download a texture onto your local system, its just going to be pulled from Video-RAM or System-RAM everytime it comes into view. If it slows your system down, its only affecting you; and you can set your video system to lower details to avoid that - there are reasonable limits to the texturing & Prim system.

But a channel-0 listen requires the server to stop what its doing and process the chat message every single time anyone opens their mouth. That has a far bigger effect - especially when you take into account the fact that there are possibly hundreds or thousands of scripts running in a Sim at any given moment. And as the world becomes more populous, this is only going to become a more critical issue.

It may not be selfish in the same way as stealing something you don't want to pay for - but its bad practice, and harms other people's experience unnecessarily. At least a custom texture can enhance someone's visual experience... In 21 years of gaming, I have never ever heard of someone wishing for more Lag.

You can listen on other channels and do the exact same things as you could with them on channel-0, so it *is* selfish if you knowingly put listeners on channel 0. You are, in effect, saying that you believe your script to be important enough that you don't care that it negatively impacts the Avatars / users around it.

Now Alondria, I do agree with you whole-heartedly in your response about linked messages w/multiple listens.

The bottom line folks, is that each extra listen adds far more processing time than any simple set of if/else statements would.

So don't listen on channel 0, use 1 listen, and filter based on the command or text you send in the message. This is the most efficient way, and probably the simplest way. And its rare in programming that the simplest way is the most efficient, so take advantage of it!

Take care,

--Noel "HB" Wade
(Tread Whiplash)

P.S. Here's an example of how I do it:

 
    //Pick some sort of channel to listen on.
    integer g_uiListenChannel = 5000; 

    //Set up the Listener itself
    integer listenHandle = llListen(g_uiListenChannel,"","","");
    .
    .
    .
    .
    .
    //"message" may contain multiple commands or parameters, 
    // each seperated by the "|" character. 
    // This is called a "pipe" character (SHIFT + backslash Key).
    listen(integer channel, string name, key id, string message)
    {
        list parsedMessage;    
        parsedMessage = llParseString2List(message,["|"],[]);
 
        //Do Some processing in here with the parsed message.
        //For example:
        if(llList2String(parsedMessage,0) == "say_hi")
            llSay(0, "Hi!");

        else if(llList2String(parsedMessage,0) == "say_given_parameter")
            llSay(0, llList2String(parsedMessage,1));
    }