llListen & listen()

HIyas Everyone,

I understand the wiki says a script can only handle 65 calls to listen. What exactly is a call?Is it the number of events in the listen() handler?

I'm use to using menus for everything but now I need to switch to chat commands for this project I've started. It seems that the listen() handler has a max of 20 or so events that it can handle. Besides switching states, is there any other way to list more events?

The obvious just hit me... I can just use one event to call up a llDialogue menu.

Each time you call the function llListen(), another listener (usually for the purpose of adding more channels to listen to) is added to your script, and the llListen() function actually returns an integer which references that specific listener, to a maximum of 64 total calls.

Each listener can potentially cause a listen event to trigger, like when someone talks. As long as your script isn't either taking too much time in the listen event to do stuff, or it isn't being triggered faster than 64 times a second (because I think 64 is about the size of the event queue off the top of my head), you should be just fine.

Sorries Tyken, your explanation isn't clear for me.

I'm pulling my hair out trying to figure why in the llDialogue menus I've scripted, I have tons of events under the listen() event handler BUT in the much simpler script using chat I can't get over a dozen events to work under listen(). It WILL work but something is limiting the number of events. Arrrrrggggg! I've must've been to the wiki on this a dozen times now... lol

Okies... I decided to drop my script into a new prim and it worked fine!

Used Jopsy's "Scrubber" Script to clean out the old prim and wah la: it works fine now.

What the heck is going on that a prim can keep a script from functioning properly?

without seeing the code, probably couldn't guess.

the 64 limit is on llListen(), meaning you can have 64 of them active at one time max.

if you open one each time you pop a dialog, and make it specific to the av the dialog is for, at some point you need to clear them either by closing them or changing state. I'm not sure what happens if you try to open more after that limit, but I'm guessing that it fails to start the new LLlisten(), and that MIGHT be what you were seeing (in which case a script reset would have cleared it.

as an example that I use when multiple av's can touch for a dialog (in default state)

touch_start( integer vIntTouched ){
  do{
    key av = llDetectedKey( --vIntTouched );
    dialog( av, <insert other junk> );
    llListen( -42, av, "", "" );
    llSetTimerEvent( 45.0 );
  while (vIntTouched);
}

listen( <insert declarations> ){
 //code to process responses
}

timer(){
  llSetTimerEvent( 0.0 );
  state Reflect;
}

and then in another state

state Reflect{
  state_entry(){
    state default;
  }
}

note: with this method, if you get more than 64 people clicking within <45 seconds of each other, #65 will get the dialog, but not get a listen (because it failed to start) and any new clickers will have to wait 45 seconds without the object being clicked, before it will be able to start a new listen. essentially it waits until it has been clicked for 45 seconds before it will clear any accumulated listens (state changes clear all current listens)

Thanx Void... that all makes sense now.

I have come to the conclusion that I personally cannot safely build or script in either of the 1.19 RCs. I have had builds that mysteriously check themsleves "Phantom" and lock. I have llPlaySound that wants to loop by itself. I have prims that won't run scripts properly. I have minimal viewer stability while scripting. I have reverted back to the last 1.18. It's really unnecessary to take a week to build and script something that would normally take a day maybe 2.

I believe it spits out a script error, for one thing. It used to anyway. Once or twice I've accidentally started new listens without removing old ones on changes of ownership and other circumstances.

One thing to note is that even if you have 64 listens active that would cause an event for a given chat, you still only get one event per message sent through chat. Just think of each filter added wtih 'llListen()' as being a new term in a big logical OR.