Two llListens on same channel not friendly

Trying to do the following will result in only one llListen working properly (the first):

state_entry()
{
llListen(0,"",llGetOwner(),"";
llListen(0,"",some_key,"";
}

Apperently, you cant setup more the one llListen on the same channel with different keys...

Yeah, that's how it's been for a while if not ever.

Your best bet is to simply run a Listen on channel 0 for any key, and then filter by llGetOwner() and Some_Key in your listen() event.

For example if I want multiple 'administrators' for an object, I put all their keys in a list and check against that list in the event handler.

Actually, you're quite wrong on that note

It seems the Lindens again want to protect us from ourselves, nerfing something potentially useful in the process. Having two (or more) listen handlers set up on the same channel used to work. (Proof of this can be found at http://www.badgeometry.com/wiki/llListen )

What I think LL had in mind with this change, was to prevent something like if the two (or more) llListen's had the same exact parameters. Since, with that scenerio, if the object "heard" something meeting those parameters, the VM would trigger two (or more) listen events.

Also, they could have done it to minimize the stress multiple listens put on the simulator. Bino's approach allows the sim to manage only one listen handler, rather then potentially 10 or more, and have the script handle its own filtering in its listen event. This is better for the sim since it can throttle the script's CPU usage in the listen event like it does for any other event. Actually, if this was the reason for the change, I support it wholeheartedly. I just loathe that they didn't norify the community though.

==Chris

EDIT: Added a proof link.

The wiki was built on the LSL docs, which have been unchanged despite the nerfing of Listens.

It's been this way for quite a while. At least since I started dealing with Kazenojin in early Fall 2003, as I was having trouble passing multiple listens on channel zero with different keys for a system being used by officers of the group. I ended up having to put all the keys in a list and filter against that.

In fact during my posting I went over to the wiki, but I didn't fix it (mea culpa).

As I hadn't tried passing multiple listens on the same channel previously, i can't say that it wasn't un-nerfed sometime before September or whatnot.

And since I know about llListenRemove() I haven't had the issue of dealing with multiple listen responses due to stacked up listen calls, so I don't know if the nerfing actually protects us from that.