listen(integer channel, string name, key id, string message)
The listen() event handler is invoked whenever a chat message matching the constraints passed in the llListen function is heard. The channel the chat was picked up on, the name and id of the speaker and the message are passed.
Channel 0 is the public chat channel all users see as chat text. Channels 1 to 2,147,483,648, and the negative of that entire range, are private channels that aren’t sent to the SL client, but that other scripts can listen for.
When using a custom state, you can remove your handler using llListenRemove(listenCallback).
If you want your listen() event handler to be invoked for all messages on the specified channel, don’t specify any constraints when you call llListen. In the following example, the listen() event handler examines the id parameter to see if the speaker is the object’s owner:
Example 1:
default
{
state_entry()
{
llListen( 0, "", NULL_KEY, "" );
}
listen( integer channel, string name, key id, string message )
{
if ( id == llGetOwner() )
{
llWhisper( 0, "I hear and obey, master." );
// interpret message
}
else
{
llWhisper( 0, "You're not the boss of me." );
// etc.
}
}
}
Your listen() event handler can also examine the message parameter to check for a specific command. The following example checks just for a command, no matter who is speaking:
Example 2:
default
{
state_entry()
{
llListen( 0, "", NULL_KEY, "" );
}
listen( integer channel, string name, key id, string message )
{
if ( message == "open sesame" )
{
llWhisper( 0, "Welcome!" );
// open door
}
else
{
llWhisper( 0, "That's not the magic word." );
// etc.
}
}
}
If you want to completely ignore messages that don’t meet your constraints, you should specify the constraints in the initial call to llListen, and your listen() event handler won’t be invoked to handle undesired messages.
In fact, you should try and constrain all of your llListen() commands as much as possible. Open listens on channel 0 can affect both script and sim performance, particularly in busy areas, since they will trigger the listen() event for each and every line of speech in regular chat.
For example, a much less laggy way to do example 1:
(Example 3)
default
{
state_entry()
{
llListen( 0, "", llGetOwner(), "" );
}
listen( integer channel, string name, key id, string message )
{
llWhisper( 0, "I hear and obey, master." );
}
}
Note that a script can listen on more than one channel at once:
(Example 4)
default
{
state_entry()
{
llListen(0,"",llGetOwner(),"");
llListen(1,"",llGetOwner(),"");
}
listen(integer channel, string name, key id, string message)
{
if (channel == 0)
{
llSay(0, "Channel 0.");
}
else if (channel == 1)
{
llSay(0, "Channel 1.");
}
}
}
However, try to keep the number of calls to llListen to a minimum to reduce lag.
Q: Is it better to specify multiple listeners, or a single listen without filters and a block of IFs?
A: Using multiple listen filter cause less lag.
Q: How long is the message queue in listen() event ?
A: After testing, it appear to be 30, all others are discarded.
Credit to: Lslwiki.net (not working) with changes made for brevity and clarity.