linkmessage verses listens

hey, from the dayu i started scripting i had read that listens add considerable lag to sl and to us messagelinked. ive gotten very good with sending lists throught the message link and trasferring tons of info, my problemn lately is that since last few patches it seems to miss some of the messages being sent. ive put severfal test says throughout to find where it goes wrong, and it seems someimtes a script just doesnt pick up teh massage.

Is this a common occurance that im finally seeing?

and then my next question, because of this ive looked back at lisetens and talks more, and it seems the listen isnt what causes the lag, its the filters so if i u crzy channels, then they shouldnt add to lag that much.

has anyone done a study or tested message linked and listens to see which casueses the most lag or if noticable if scripted properly? i can finish a few of my proects tonight with listens, but i dont like addin to lag more then i have to for everyones sake..

thanks for time

I don't think that llListen causes lag so much directly and obviously.
But theoritically it surely uses server power whenever it works.
Even though you set filleters, the server must make a decision if it should be filterd or not whenever someone speaks in the same SIM.
This is like the Kyoto Protocol. Yeah, I know some contries are negative about ratification of it.

Linkmessages are best to use for communicating between scripts in a prim or object.

llWhisper, llSay and llShout with a listen in the same object won't work together, as objects don't listen to themselves speak.

For communicating between objects, in general it's best to use llWhisper, llSay and llShout on a negative channel using very strict filters and states in the listening script.

If I can quibble about this, it occurs in the same prim, not the object.

ok, i understand that, but my two bigger issues were has anyone esle noticed or is it common that linkmessages arent recieved? i never had the issue until recently, but a number of the messages are being recieved by half the prims in the object but no tthe other half...

and would listen with a strict filter and neg channel cause more lag then link message? has anyone done testing between the two?

Sorry, no. They work fine for me. It might be another problem such as missing checkmark of "running" or some mistakes.
I guess that they give the same stress while just working. The point is that llListen has possible to work all at once anytime when someone just speaks in the SIM even as you don't expect it. But the filtate is too fast to observe, so that I can't say it but theoretically. I understand that it is rather said as a manner of scripters.
I believe that the existence of one avatar causes lag much more than one llListen. Get rid of it first.

When a script is delayed there is a maximum queue size of 64 for link messages (bottom of http://secondlife.com/badgeo/wakka.php?wakka=scriptdelay). This may be true if there is significant lag also. I don't know. The crazy thing is that this is MORE restrictive than listens even though link messages are supposed to be less problematic than chat listens AND THEY ARE DEFINITELY USED FOR MORE CRITICAL COMMUNICATIONS! So, you might try to reduce the number of link messages if you are throwing around a lot of them.

It sounds INSANE, but if your object is stationary and your communications are absolutely critical, you might actually be better off with chat messages and a relay object used purely to reflect chats back at the original object.

Um, I think that's not correct. Listens get capped at 16 IIRC.

Perhaps this needs to be tested or verified by a Linden and the Wiki page corrected then.

Ok, I've just tested it. It's not capped for up to 500 messages on listen.

I can't be bothered to test further than that I'm afraid.

Uhmm how did you test that one, out of curiosity? o.O;

i gave it a quick try, and it appears Wiki is quite wrong about the listen events during delay -- that is, if there's listen event during the delay, it gets silently dropped period. Length of event queue nonwithstanding.

scripts used for test:

emitter:

default {

    state_entry() { llOwnerSay( "jabber off." ); }
    
    touch_start(integer total_number) { state on; }
}

state on {
    
    state_entry() { llOwnerSay( "jabber on." ); llSetTimerEvent( 0.1 ); }
    
    timer() { llSay( -1, "wheee!" ); }

    touch_start(integer total_number) { state default; }
}

receiver:

integer listen_count;
integer listen_handle;

default
{
    state_entry() {
        
        listen_handle = llListen( -1, "", NULL_KEY, "" );
        llListenControl( listen_handle, FALSE );
    }

    touch_start(integer total_number) {
        
        llOwnerSay( "Going to sleep for 10 seconds..." );
        listen_count = 0;
        llSetTimerEvent( 10.0 );
        llListenControl( listen_handle, TRUE );
        llSleep( 10.0 );
    }
    
    timer() {
        
        llListenControl( listen_handle, FALSE );
        llSetTimerEvent( 0.0 );
        llOwnerSay( "Woken up." );
    }
    
    listen( integer channel, string name, key id, string message ) {
        
        ++listen_count;
        llOwnerSay( "Triggered " + (string)listen_count + " times." );
    }
}

If you comment the llSleep(), listen is triggered normally during 10 seconds it takes the timer to execute. Uncomment the llSleep and you will see that no listen() call is generated and passed to script after it wakes up (except generally for single call that may slip in *after* script enters timer() event, before listen handler is closed)

Nope. Just tried it, and it definitely queues up at least 50 listen events during the sleep. However, in order to see that, I needed to comment out this line:

Once this line is executed, the queued up listen events get discarded. Disable that line, then turn the jabberer on for a few seconds while the listener is sleeping, and you can see that listen events are indeed being queued up during the sleep.

I'm guessing you were thinking llSetTimerEvent(10.0) would cause the timer event to get in line behind the listen events and not be processed until after the listen events that occured during the sleepy time. Alas, it doesn't work that way. Apparently, they are in seperate queues, and it empties the timer queue before even looking at the listen queue, so pending timer events get processed before listen events, even ones older than the timer event. (Actually, I suspect timer events don't queue at all, it just sets a flag after the time expires, and timer gets called the next time through the event handling code in leu of pulling the next event off the queue.)

Aye; at the least i wasn't expecting the ListenControl() to discard possible listen() events which were generated before the control call is executed, because it's really silly behaviour >.<;;

I tried it the way you describe and it indeed does work then, the events get transmitted once the delay is up and the amount can easily exceeds the internal 64 events queue of a script, so guessing you're right about this being handled through separate mechanics o.O;

I've killed the scripts.

But I had one script with a for loop counting to 500 and saying the numbers on channel 10.

The other script, when it first heard a message slept for 10s, and then just said the numbers it heard back.

I got the numbers 0 - 499 continuously twice.

The limit of 16 for listens isn't the queued events, its the number of active listens you can have running in the script at once. That's the reason they put in llListenRemove() so you could shut off a listen no longer needed since calling llListen() creates a new listen without removing the old one first (unlike the llSetTimerEvent() which controls the only timer the script can have).

Also during times of sim slowdowns or lots of scripts running actively at once listens and link messages both can get lost due to timing issues.

Listens in and of themselves don't cause a lot of lag if filtered right. The key filter is using a channel other than 0 since that's teh general chat channel. Putting the listen on antoher channel alone cuts down on the lag since the script no longer proccesses every line spoken in chat to see if it meets its criteria. The worse lag inducer of course is this: llListen(0, "", NULL_KEY, "" since this means the listen event has to proccess every single line of chat spoke. Even just adding something more in the argument list will cut down the proccessing/lag because the initial check agains thte filter saves the event code from being executed. The example I used is what's commonly called an 'open listen' which gives all listens a bad name.

Also there's a delay to a degree with listens so link messages are supposed to be faster to proccess. If you don't need immediate response from between two objects that need to communicate you can use the email functions/events to have them communicate without a listen though it has its own restrictions.