Jump to content

Remove 'listen' after a period of time


Vindictii
 Share

You are about to reply to a thread that has been inactive for 2619 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

I am learning how to use 'llListen' and I am seeing places where I may want the 'listen' to only be available for a short time. For example: I have an object that when TOUCHED with set a 'llListen'. I want that listen to only listen for about 10 seconds and then stop listening, regardless of whether it hears anything or not. I still want the listen to work if it does hear anything, but it if doesn't I want to reset the script.  What am I missing? Can anyone point me in the right direction?

Link to comment
Share on other sites

Very easy.  Take a look in the LSL wiki for llListenRemove for details, but the general idea whenever you open a listen handle goes something like this:
 

giLsn = llListen(MY_CHANEL,"","","");   // Where giLsn and MY_CHANNEL were previously defined global variables
llSetTimerEvent(10.0);
.
.
.
listen(integer channel, string name, key id, string message)
{
    llListenRemove(giLsn);
    llSetTimerEvent(0.0);
    // Etc.
}

timer()
{
    llListenRemove(giLsn);
    llSetTimerEvent(0.0);
}

As an extra precaution against having listen handles open when you don't want them, you can also add llListenRemove(giLsn) just before you open the llListen in the first place.  That's usually not necessary, but if you have a complex script with several paths that might lead back to the initial llListen, it's smart to do.

Edited by Rolig Loon
  • Like 3
Link to comment
Share on other sites

This is good stuff, I've only recently been learning more about listen handles and so forth, as opposed to just cutting and pasting snippets because I know they'll work. A week ago I didn't even realize you could use two listens in the same script... *facepalms*

Link to comment
Share on other sites

2 minutes ago, Berksey said:

[ .... ]  A week ago I didn't even realize you could use two listens in the same script... *facepalms*

In fact, you can have up to 65 open at once, although it's hard to image why you might want to do that on purpose.  It's unfortunately easy to do it by mistake, though.  That's why I added that final comment in my post.  If you have a script that iterates back through the event where you have the llListen statement, and if you have never closed previously opened instances, they might pile up, eventually locking your script altogether.  For example, something like this would create problems sooner or later:
 

default
{
    touch_start (integer num)
    {
        llListen(giMyChannel,"","","","");
        llDialog(llDetectedKey(0),"Pick a choice ... ", ["YES","NO","MAYBE"],giMyChannel);
        gkAv = llDetectedKey(0);    // Save the user's UUID
    }

    listen (integer channel, string name, key id, string message)
    {
        llRegionSayTo(gkAv,0,"Go ahead .... touch and make another choice.";
        // I don't really care what you chose, so I'll ignore your answer.  This is just an example.
    }
}

 

  • Like 2
Link to comment
Share on other sites

I always played it safe with llListenRemove as well. Although, I also always wondered if that would be really necessary if you call just the same llListen, same channel, same filters. So I just did a quick test where I called that function 5000 times and it didn't threw an error. :SwingingFriends:

Link to comment
Share on other sites

2 hours ago, arton Rotaru said:

I always played it safe with llListenRemove as well. Although, I also always wondered if that would be really necessary if you call just the same llListen, same channel, same filters. So I just did a quick test where I called that function 5000 times and it didn't threw an error. :SwingingFriends:

Then you called llListen 5000 times using exactly the same parameters. That resulted in the creation of only one listener. Try this...

integer i;
default
{
    touch_start(integer total_number)
    {
        llSay(0, "Touched.");
        for(i=0;i<100;i++){
           llOwnerSay((string)llListen(i, "", llGetOwner(), ""));
        }
    }
}

Put that in a prim and touch it. Each call to llListen uses a different channel number, and so creates a new listener. You should get a run time error after 65 iterations.

Edited by Madelaine McMasters
  • Like 1
Link to comment
Share on other sites

8 minutes ago, Madelaine McMasters said:

You should get a run time error after 65 iterations.

Yes of course, I did test that as well indeed. That was out of question. I just wanted to know what happens if it's always the same parameters, because I always did a llListenRemove in that case, too. But it's obviously not necessary. :SwingingFriends:

  • Like 1
Link to comment
Share on other sites

19 minutes ago, arton Rotaru said:

Yes of course, I did test that as well indeed. That was out of question. I just wanted to know what happens if it's always the same parameters, because I always did a llListenRemove in that case, too. But it's obviously not necessary. :SwingingFriends:

Oops, I didn't read carefully enough!

Link to comment
Share on other sites

Rolig, it's the intention that counts, not the example given. No worries.

I was delighted to find out I can use more than one listen simultaneously, because my stuff can use llRegionSayTo on a hidden channel while the user can use chat commands on channel 0, thus allowing the user to interact with the item without having to make them privy to the channel the item uses for its magical fun thingies it does (like registering hits on the combat meter).

What I need to do now is go back and add listen removes in the same places I've, say, added things like llStopAnimation() and so forth (basically any time the item is detached or otherwise deactivated). It just makes sense from a good coding perspective, even if I don't have multiple users touching the same item or using multiple chat channels thought up on the fly.

I appreciate everything people share here, because the documentation is really limited compared to the live knowledge, you know?

Link to comment
Share on other sites

Only one detail is missing: a state change removes all listens.

So - if you have no clue which of your many listens are open :) - you could change state and change back - all closed.

But of course a real scripter always knows what listen is active and don't needs that big wipes. :D 

 

  • Like 1
Link to comment
Share on other sites

On 5/14/2017 at 7:23 AM, Nova Convair said:

...But of course a real scripter always knows what listen is active and don't needs that big wipes. :D 

 

Still doesn't hurt to remember it... Thanks for bringing it up.

Edited by Berksey
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 2619 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...