Listenting... .what causes lag

I'm aware that...

llListen(0,"",NULL_KEY,"";

listen{do intensive stuff here regardless of string}


will be very laggy due to it processing everything it hears on channel 0.


I have a script that listens for 4 commands.

I'd like to know what which approach is least laggy.


version 1

key player;

default
{
     state_entry()
    {
        llSetText("Touch me to start",<1,1,1>,1.0);
    }

    touch_start(integer total_number)
    {
        //get player key
        player = llDetectedKey(0);
        
        state waiting;
    }
}

state waiting
{
    
    state_entry()
    {
   llListen(0,"",player,"");
   }
   

 listen(integer channel, string name, key id, string message)
    {
    
        if (message == "foo" || message == "bar" || message == "fob" || message == "barf" )
        {state processing}
}

state processing
{
do shtuff with listen now turned off;

state waiting;
}

or would it be better to have 4 listens?

key player;

default
{
     state_entry()
    {
        llSetText("Touch me to start",<1,1,1>,1.0);
    }

    touch_start(integer total_number)
    {
        //get player key
        player = llDetectedKey(0);
        
        state waiting;
    }
}

state waiting
{
    
    state_entry()
    {
   llListen(0,"",player,"foo");
 llListen(0,"",player,"bar");
 llListen(0,"",player,"fob");
 llListen(0,"",player,"barf");
   }

//Will all 4 of those trigger this same event?   
listen(integer channel, string name, key id, string message)
    {
    
        {state processing}
}

state processing
{
do shtuff with listen now turned off;

state waiting;
}

also which one would be better if it was not filtering everyone but the owner?

I believe (and am sure Strife will correct me if mistaken ) that four separate listens would be a greater load on the sim than one because of the way listens are implemented. Once the listen returns, you'lll be in LSL "space" rather than "sim" space which although may be slower to you should take lower priority on the sim.

Listens to user NULL_KEY on channel 0 should be shunned anywhere. If you can't use a non-zero channel (e.g. "/1 command" then you should definitely prefer one listen to multiples. But you really should try to avoid 'em.

Nice use of states, Blueman.

To use Intro's non-channel-0 suggestion, and because you are responding to a touch, try using llDialog to present the user with your four options and to set the channel in such a way that they do not need to know anything about it.

Also, consider starting a timer in waiting:tate_entry to revert to default after a minute or so if no response is received. It's great to see that you are concerned about lag, and this will make sure than any listen-related lag is limited to very short periods of time anyway.

I've got a question along a similar line...

Does open listen on a high, unused channel cause any lag when there is nothing being said?

I'm trying to make an anti-griefer tool for clubs where you would put these scripts in the floors and walls.

They would stay dormant and wait for a message from the security people's HUD attached script.
Once activated they would scan and actively push objects that are within 30m
of the ground and that are owned by the person indicated.

Any listener will cause some lag while it lies in wait to be triggered. If you dont need an item to listen for long periods create something to turn it off (and on when needed) or remove and recreate. The off switch can even be activated by text (via the listen itself) but the on switch must obviously use another method. But I doubt an unused listener causes significant lag. The fact is that ANYTHING causes some lag

channel ... stands the highest chance of causing lag because everything on that channel will inspected.

name ... this is a great filter because the chat can stay in its raw format
llListen( 0, llKey2Name(the_avatar_key), the_avatar_key, "" ); is better than
llListen( 0, "", the_avatar_key, "";
(unless the avatar in question is the only one that will use the channel)

key ... bounces any text generated by unauthorized sources ... (too bad this isn't a list)

message ... the last step. I'm not sure if it it ever makes a huge difference except on channel 0. Although it would help enormously if the listener itself were poorly constructed...

I had a thread about this a while ago, but no particularly scientific tests were made (and no Linden commented ), but the conclusion drawn was that listening on an obscure channel would generate zero lag.

As the way listen's hopefully (ie should work) is to have a table of listens for each channel (if there are any). When a message is sent on a particular channel, it sends the message to all objects listening on that channel. So if no messages are being sent to channel 1234567 then that listen will never have to do anything.
Assuming a reasonably sensible method of storing the listens associated with each channel, then there should be no overhead for having loads of listens (unless they are all on channel zero).

Also, your comment in regards to supplying a name AND key to the listen shouldn't hold true (unless something silly is happening), as the key limits the listen to single object/avatar, as such the name should never need to be tested.

The best solution where available is either a dialog, or an obscure channel and a gesture.

I use doors with a channel, say 12345, typing /12345 lock all the time is a pain. So I create a gesture which looks for the command /lock and if found, send the message /12345 lock for me. This combines simple commands with zero-lag listens, if you are likely to have lots of doors on different channels, then you have your commands more meaningful, e.g:
/wcLock
/wcUnlock
/kitchenLock
/kitchenUnlock

etc etc.