Too Many Listens Error...

Hello, everyone.

I've recently created a teleporter system for my own use, and I hope to release it as a product. However, my friends have been telling me that my teleporters have been getting the "Too Many Listens" error when I'm not around. The error seems to be occuring randomly, so it's been difficult for me to replicate.

These teleporters can only have three listens at any given time, and two of these listens are only temporary.

1) A listen for communicating with other teleporters
2) A listen for the user interface (dialog menus)
3) A listen for communicating with the "teleport beam"

The first listen is the only one that is permanently open (unless the owner changes the channel).

The wiki and several other sources have confirmed that the error is only supposed to occur when there are more than 64(?) listens open, which is certainly not the case.

I can't post the script on the forums, but I'll gladly provide it to anyone who needs it.

Any help is appreciated.

Are you sure you're removing the listens with llListenRemove()?

Positive. I've checked the script several times, looking for every instance of them. The only one not being removed is the first one.

Sounds like a job for extreme brute force debugging: have it llOwnerSay the handle for every llListen.

In all the scripts you're listening with.

Oh, fun. I'll post an update soon.

Edit: What should I be looking for here? The listen handle is incrementing each time, as it should be (I think)...

You can send one my way if you are still lost.

Are you closing the listen before you open a new one? The order does matter.

Hmmm, now add code to print the handle that it's CLOSING each time. Look for discrepancies.

this is why I mostly use state changes to close listens, there's no mistakes possible there. (yes I know not every device can use that logic).

we recently saw a similar thing with a titler. the listen was only closed after it'd been used, but a new one was started (and it's handle stored) on a timer.. leaving the old one open if it hadn't been used, and now unclosable because the new handle was saved in the old variable, so there was no longer a stored reference.

That's not quite true, the handles are allocated sequentially and llListenRemove doesn't give an error. You could just brute force close all previous listens. Of course this is a TERRIBLE solution, which is why it isn't referenced on the wiki.

In order to debug and to get a more strict control on listen handles, use a list for them:

list handles=[];
default
{
...
handles += [llListen( someChannel, "", NULL_KEY, "")];
...
}

This way you can:
1. See how many listens are open, by looking at the list length.
2. Easily remove all listens, by looping through the list

Alright, I've added debug for both sides of the listen handle (creating and removing), and I haven't found anything out of the ordinary.

I'm definitely considering the list idea.


P.S. Jesse, I sent you a copy of the script. Don't think I'm just dumping this on you, though, I'm still trying to figure it out.

I in no way thought you were going to dump it on someone. Always glad to see people learning here and I can plainly see that you are learning. Sometimes we just need an extra pair of eyes to see the obvious and to help us get over a hurdle. From past experience I can say that this hurdle always happens right before we make a huge leap in our understanding. I will hurry up and log in and grab it, unfortunately i might be looking at a ban here for a few days for reasons that I will not go into here. But if I can not respond in world then I will pass it on to a friend that can get it to you.

Here is the problem and it is a common mistake that has gotten most of us at least once:
[lsl]
else if (Channel == TeleportListenChannel);
{
if (Mssg == "CloseListen" {
llListenRemove(TeleportListenChannel);
llMessageLinked(LINK_SET, 0, "TeleporterDisengage", "";
llSetText(FloatingText, < 0.0, 1.0, 0.0 >, 1.0);
}
}
[/lsl]

Can you spot it? It's this ";" in your else if

[lsl]
else if (Channel == TeleportListenChannel){
if (Mssg == "CloseListen" {
llListenRemove(TeleportListenChannel);
llMessageLinked(LINK_SET, 0, "TeleporterDisengage", "";
llSetText(FloatingText, < 0.0, 1.0, 0.0 >, 1.0);
}
}
[/lsl]

That's A problem, bit it's not THE problem, all that will do is trigger redundantly if it gets "CloseListen" chatted on the wrong channel, which is unlikely to happen. The problem is that he's calling llListenRemove(TeleportListenChannel) instead of llListenRemove(someHandle).

Thanks Argent. I am still looking at it some off and on and will give it a final try in Aditi after I finish, IF I can log on.

Aaah, of course!
It seems so obvious now.

Thank you VERY much for your help, everyone, this has been bugging me.


/me passes out cookies and lemonade

in SendTeleportMenu(key ID){ change the channel to ListenChannel in the else test

in else if (Mssg == "Config" { llDetectedKey will not work in a listen see:

http://lslwiki.net/lslwiki/wakka.php?wakka=llDetectedKey

Remove CleanTeleporterList() from the timer event and just put it at the end of state_entry. Start your llSetTimerEvent in touch_start, add more time if necessary in the different listen tests or set to zero in your listen tests where applicable. Might try using a dedicated handle for channel zero so that you do not have to continually redefine ListenChannel. Remove zero channel when you do not need it anymore and then remove ListenChannel and zero channel again in the timer event?

Should clean up the code and make it easier to debug.