listen() is triggering multiple times per chat if multiple listen handles are matched.
tracked
Lucia Nightfire
Today, someone in a scripting group posted evidience of this with this repro script:
default
{
state_entry()
{
llListen(0, "", "", "");
llListen(0, "", "", "123");
llListen(0, "", "", "");
llListen(0, "", "", "");
}
listen(integer channel, string name, key id, string message)
{
llOwnerSay("channel = " + (string)channel + ", name = " + name + ", id = " + (string)id + "\n" + message);
}
}
listen() should only trigger once per chat upon the first successful listen handle match.
There should be no further listen handle checks.
Log In
M
Mercury Linden
marked this post as
tracked
Given Monty's re-think, I'm updating this to be tracked!
Monty Brandenberg
Funny thing about the llListen() and listen event wiki pages... I don't think any Linden ever contributed to them. Sadly, the wiki is more like a collection of reverse engineering notes than an API contract. (I am grateful for the contribution, this is our failure. And the effort was and is remarkable.)
I looked at this and thought you're both wrong and all four handlers should be invoked for "123" in chat. These shouldn't interact and if you had, say, variable patterns defined by data or even external notecard or more exciting still an external server, you'd still want consistent handling and non-interacting matching as the coder could not possibly anticipate the interactions correctly.
But then we see that the 'listen' event offers no way to distinguish what listen handler matched the pattern. So, that was never going to happen. And we also see the 'listen' event Caveats warning that, at most, a single event handler invocation will occur. I guess that's the contract. And this is a genuine bug.
Then I looked at llListenControl() and wondered what it's contract really is. If the handler for a message "X" disables a listen handler for "X" and then that message is rapidly sent, what happens? Does the call affect queued but not yet delivered events? I.e. the call takes "eventual effect." Perfection is elusive...
M
Mercury Linden
marked this post as
expected
This is working as expected, but we need to update the documentation to account for this behavior.
Beatrice Voxel
Mercury Linden Perhaps what's needed then is an alternative mode for the listen() function, such that one mode behaves like this, and the other only matches once regardless of how many 'cases' in the list get a hit on a given string.
And yes, documentation will help, because a programmer can then take steps to weed out those cases where you'll get multiple matches on a single given string.
Lucia Nightfire
Saying '123' in open chat showcases the bug. Saying anything else does not.