too many listens (help!)

[Christina Halpin]

The key I made keeps getting a "too many listens" problem.

 

I am pretty sure I turn off all of the listens in a timer. But still get the error.

 

Can they accumulate across sessions? Like someone logs out with 10 listends, maybe they still have 10 when they log back in?

 

If I change states in state exit, will that solve my problem? 

[Rolig Loon]

You can keep as many as 65 listeners open at once, but I have a hard time imagining a need to do more than a fraction of that.  If you're hitting the limit, something isn't right.  Do you perhaps have a llListen in a loop somewhere?

Changing states will always close all listens, so that's one very sure way to avoid the problem.  Using a timer is a good plan too, but you should also plan on other ways to kill a listen before the timer finally triggers.  If you open a listener to start a dialog, for example, close it at the top of the listen event.

BTW, people don't accumulate listeners.  Scripts do.

[Miranda Umino]

Rolog has surely right .

You do surely something wrong in your script .

 

Maybe  you call llListenRemove with a wrong arg  too

 

I don t understand why you tell about sessions . What kind of sessions ? Viewer sessions ? 

Scripts are independant of viewer sessions .

For the http listeners ( those created by llrequesturl) , you need to restore them , but not for the messages listeners ( those created by lllisten)

[Richie Kanto]

Seen this one before... and the issue is almost certainly the listens are not being turned off. Look at your coding, are you turning off the listen by correct name (are you naming your listens EXACTLY the same as in the listen remove command, including capital letters), is your timer running correctly or is something turning off your timer before it runs or is it being reset to run again each time the listen is activated (you mentioned using a timer to turn off the listens). Run a test (usually I have the script say something when it enters the time state to check).

As far as "sessions"... I'm guessing you're thinking the listens are pegged somehow to the avatar the script is listening to. They are NOT. The script continues to run with no avatars around, unless you've scripted in coding to the contrary, so it is possible listens continue to accumulate even when no one is around. To know more would require knowing the layout of the script but the fact you've asked this hints to me that perhaps you didn't realize the script runs continuously when in world.

Yes changing states should turn off the listens, but, I'd want to know why they aren't shutting down to make sure something else isn't affected also.

Good luck trouble shooting... hope this hint where to look is helpful.

[Dora Gustafson]

---

Christina Halpin wrote:

Can they accumulate across sessions? Like someone logs out with 10 listends, maybe they still have 10 when they log back in?

---

If by sessions you mean rezzings, all open listens will remain from rezzing to rezzing

The listens will accumulate if you do not:

1. Reset the script at rez
2. Remove listens before opening
3. Change state

About 2.

It is perfectly legal to remove listens that are not open so before open you should remove, like in this example:

default{    on_rez(integer n)    {        llListenRemove( handle );        handle = llListen(dialogChanal, "", NULL_KEY, "");    }    listen(integer cannel, string name, key id, string message)    {    }}

I recently had a problem with cross talk which was not cross talk

It was a listen that was active on channel 0 from another time the script was running

The remedy to fix it was a llListenRemove( handle );

 

[Innula Zenovka]

Just to clarify how listeners work and how to remove them without changing states,  a listener is identified by an arbitrary integer assigned by the system with the listener is opened.   People sometimes get confused and think that llListenRemove(5) means "stop listening on channel 5" -- it doesn't.   If there's a listener that happens to have been assigned the value 5 by the system, it'll remove that, whatever channel it's listening on, but otherwise nothing's going to happen.

If you wanted to make a listener for llDialog that listens to one user at a time, you could do something like this, which would only every have one listener open at once:

integer listener;integer dialog_channel= -9990;key toucher;default{	state_entry()	{		//llSay(0, "Hello, Avatar!");	}	touch_start(integer total_number)	{		if(toucher){//if someone's already using it			llRegionSayTo(llDetectedKey(0),0,"Sorry, but this is in use by "+llGetDisplayName(toucher)+". Please wait a moment");			return;		}		toucher = llDetectedKey(0);//otherwise...		llListenRemove(listener);//remove any listeners that might be running, though there shouldn't be any		listener = llListen(dialog_channel,"",toucher,"");//listen to the latest toucher		llSetTimerEvent(30.0);//keep the listener open for up to 30 seconds		llDialog(toucher,"Please choose an option",["Yes", "No", "Maybe"],dialog_channel);	}	listen(integer channel, string name, key id, string message)	{		// do stuff, then		llListenRemove(listener);//stop listening to that avatar on that channel		llSetTimerEvent(0.0);//turn off timer		toucher="";//clear the toucher's identity, so it can be used by someone else	}	timer()	{		llListenRemove(listener);		llSetTimerEvent(0.0);		toucher="";	}}

 

 

[Christina Halpin]

Um, thank you VERY MUCH. This is a wonderful list of suggestions.

 

I have a lot of listens -- maybe 25, mostly used when the key changes outfits.I will triple check them. I put a change of state to happen whenever someone started, but then I lost other things. So I put it for state-exit, but I have no idea if that works right.

 

 

 

 

[Innula Zenovka]

Obviously I don't know what the script's like or what it's doing, but I have to say that if you need that many listens to make it work, there's almost certainly a simpler and better way to do it -- particularly (though I may have misunderstood this) if the item is just being used by one avatar (which the reference to changing outfits suggests to me is the case).

If you need to keep track of what's going on, remember you can always check at the start of the listen event what channel is being used and the uuid of the avatar speaking, or, if it's an object, to whom that object belongs -- llGetOwnerKey(id).   That might help you simplify things a bit.

[Rolig Loon]

If you expect to be hearing from several different people each time any one of them changes an "outfit", you only need one listener, which you never close.  As Innula says, you always know who's speaking.  Assuming that the "outfit" is a scripted item that sends a "Hello" message when it is attached .......

 

llListen(secret_channel,"","","");listen(integer channel, string name, key id, string msg){    llOwnerSay("The UUID of the person contacting me is " + (string) llGetOwnerKey(id) );    llOwnerSay("She is wearing the object called " + name + ", which is sending me the message " +" \" " + msg + " \" ");}

 This will work as long as the person is in the same sim, using a script that speaks with llRegionSay (or llRegionSayTo).  If the person is not in the same region, listens won't work.  The best you can do is to either have the outfit scripted to send you (not your object) an IM, or have it send a message by HTTP or e-mail to your object.

 

[Innula Zenovka]

The reference to "outfits" has me wondering if it's something to do with RLV and shared folders, which can get complicated and probably needs listeners on three channels (main RLV relay channel, dialogue channel and a channel for RLV viewer to use for replies), but I don't think it should need more than that, even if several different avatars are using it at once.

[Christina Halpin]

llOwnerSay("@getpath:pelvis=9002");
listen_id_9002 = llListen(9002, "", dollID, "");

llOwnerSay("@getpath:right hip=9003");
listen_id_9003 = llListen(9003, "", dollID, ""); 

 

I think I am starting to figure this out. I don't need two listens (or, really, more than that), I can just open a listen to dollID. I guess there isn't much reason to turn it off even.

I am thinking I could get too many listens if either of these gets executed again before the first listen gets turned off. I think that takes 30 seconds.

RIght now I am hoping it works to change states on exit. In other places, I started turning off the listen before I turned it on. Like

llListenRemove(listen_id_main);
listen_id_main = llListen(cd29, "", id, ""); 

 

Thanks again to everyone. It's no fun to build something that always breaks. 

 

[Innula Zenovka]

Yeah, you're getting the idea, I think.   You certainly don't need lots of listens if you're simply running through a list of things to check like that.   Just run through the list, with llList2String(lstWornClothes,n) and advance n each time you get a reply, and ask for the next item.

While I don't know what you're doing with the shared folders, obviously, I'd certainly suggest using @getpathnew rather than @getpath (in case there are several items worn on the same layer or point).

You might also find @getinvworn worth looking at.