Too Many Listners...

I had a script crash after this latest patch, but in an unusual way. The runtime error was printed under my name, not the name of the object who's script crashed. It did not register in the script console errors/warnings window either.

So I got:

WhiteFire Sondergaard: Script run-time error
WhiteFire Sondergaard: Too Many Listens

The object in question never gave an error, I had to poke at the scripts I wore before I found the one that had stopped working. I replaced it, and it ran fine.

It's a script that only listens on four channels... It may have had problems with duplicate filters because of a bug, though. But should that not cause the object to give the error and something to show up in the script console?

Is there a sim/avatar limit on listening scripts? I have a lot of land in the sim and do a lot of R&D there, as do some friends.

I'm really quite puzzled, nor can I get this to reproduce. For all I know this is just some sort of one-time glitch that I'm fretting over.

Reproduced the error condition that would cause the script to reissue llListen()s with out removing the previous ones, and it does not seem to cause the script to fail. Presumably llListen()s issued with the same arguments do not cause duplicate listens to be created.

Which makes this even more confusing as to what caused this....

Wrong... although it's counter-intuitive if you create listeners all killed listen1 on channels 0, 1, 2... they all fire.

Multiple listens with the same criteria will I believe create multiple filters, but only result in one 'listen' event. That's what the Wiki implies anyway. You can always store the listen handle and remove it before issuing another 'llListen()'. Or, if you want to be paranoid about things, switch states, which removes all listens.

I am not sure of where you are getting your information, but, emperical evidence suggests it is wrong.

for (i = 0, i < 100; i++)
llListen(100, "", NULL_KEY, "";

That does NOT crash a script.

for (i = 0, i < 100; i++)
llListen(100 + i, "", NULL_KEY, "";

This most certanly does. Further, the error given is:

Object: Script run-time error
Object: Too Many Listens

So while the script in question is in fact technically flawed, it still is workable. Further, I as I said, I recreated the conditions where it should fail if the duplicate listens would have over-run the 64 listener limit, and it did not.

Note also that in the case of the script (clearly) coming up with too many listners, you get the error from the object, not from the avatar.

Interestingly, the error reported by the second code snipet does not produce anything in the Script Errors/Warning dialog. Perhaps this is common for runtime errors? I'll have to test like div by zero and such.

Still left is the question why I get the error from ME, not from the object that failed, and why I got the error in the first place.

At this point I'm kinda guessing "glitch".

I was stupid this morning and listened to each object rezzed with 'llRezObject()' without removing previous listens. After a while I got this message. Not terribly surprising.

WARNING: The unexpected thing is that the object DIED without warning. It did NOT sit there with an error or simply turn off the scripts in the object, it did NOT return to my inventory. It was simply WIPED from the face of SL!

Just tested inworld, made an object create a ton of listens on diff channels so it crashed, then attached it and reset the script, the error showed up with "Object" when not attached, and my name when attached.

Um, that's not quite how I set it up, but the second part is what I expected to happen.

Try this script

integer listen1;

default
{
    state_entry()
    {
        listen1=llListen(0, "", llGetOwner(), "");
        listen1=llListen(1, "", llGetOwner(), "");
        listen1=llListen(2, "", llGetOwner(), "");
    }

    listen(integer chan, string name, key id, string msg)
    {
        llOwnerSay("Heard on channel "+(string)chan);
    }
}

I'd expect, intuitively, it only to listen on channel 2, it responds on all of them viz

[0:54]  You: boo
[0:54]  Object: Heard on channel 0
[0:54]  Object: Heard on channel 1
[0:54]  Object: Heard on channel 2

Which is precisely what I said would happen. I'm sorry if I misunderstood your post and that isn't the equivalent to what you were doing and observing.

Was the object attached to your avatar at the time?
I've seen attachments speak as the avatar when encountering a runtime error before.
==Chris

Eloise, the 'listen1=..' part of those lines simply stores a number returned by llListen(), which allows you to enable/disable with llListenControl() or remove with llListenRemove(). It doesn't do anything to previous listens, whether they used the same variable or not.

The following three code snippets work the same way with listening to chat (that is the script responds to chat on all three channels), only that with the first snippet you can't control or remove the first two listens, which you can with the second snippet, and the third you can't control or remove any listeners.

listen1=llListen(0, "", llGetOwner(), "");
listen1=llListen(1, "", llGetOwner(), "");
listen1=llListen(2, "", llGetOwner(), ""); 

////////////////////////////////////////////

listen1=llListen(0, "", llGetOwner(), "");
listen2=llListen(1, "", llGetOwner(), "");
listen3=llListen(2, "", llGetOwner(), "");

/////////////////////////////////////////////

llListen(0, "", llGetOwner(), "");
llListen(1, "", llGetOwner(), "");
llListen(2, "", llGetOwner(), "");

Thanks Kayla.

I had worked it out eventually, I just remember the confusion the first time I got a too many listeners message because I'd read and understood it the other way. It *still* intuitively makes more sense the other way to me, but my intuition is wrong about other things too, and sometimes my intellect kicks in.