Turning off listens & the timer event - resource use question

I'm debating the pros and cons of turning off listens when not needed. In my current situation, all the chat going to a listen would have been generated by a Dialog.

As I understand it, when filtering listens, it's best to let the filtering be done at the server level rather than the script level by making your listens as specific as possible. I have done that/ Suppose you want to go one step further by turning off listens when not needed by using llListenControl.

Problem is when you do that, you usually have to set up a timer to trap for the possibility that the user has clicked the ignore button rather than your Cancel button that you would use to turn off the listen. Normally you would turn the timer on & off.

In my situation however, I already have a timer running constantly that gets polled every half second (this is a modified AO). So turning off the timer is not possible. So to trap for the need to shut off the listen, I would have to write code that would get processed two times a second. That in itself seems rather costly.

Following the principle of letting the server rather than your script do the work, my inclination is to keep the listen running and not incur the overhead of code in the timer event. So gurus, would you think it would be better to try to shut off the listen in this situation with the overhead involved, or just keep the thing running.

You can still use the timer, just put a counter and flag in to control when to trigger the removelisten. ie. in your case you have the timer triggered every .5 seconds, so put a counter in for when it reaches 60 you can reset the counter and and flag that checks the counter.
general codelett (no inworld to check syntax)

if (listening == TRUE)
{
listen_counter = listen_counter+1;
if (listen_counter > 60)
{
llRemoveListen(listen_control);
listening = FALSE:
}
}

I often leave such listens active. Just make sure you are using some large (preferably random) channel number. It simplifies the logic and the design of your system, and should not contribute much to lag at all since the first filter on the server is by channel number (probably/hopefully by a fast tree or hash search).

Since it's an AO, you'll have at most one per av. Worry more about this kind of thing when the object is one that is likely to have lots of copies ingame, like a poseball.

You're thinking the right way, but there's no way we can really know (without some pretty serious testing) what the tradeoff is between code operators per second versus an active listen.

In this case, I'd probably go with simplicity. You're unlikely to find dozens and dozens of these in the same sim, so as long as you're not hogging the processor unreasonably (which neither solution would do), you should be OK.

Hewee, I wish I knew how they filtered it. I'd always hoped that they used a hashing scheme, though I didn't quite come up with an effective way to do that given all the possible wildcards without testing 16 different hashes for every chat. But that still might be better than specific tests.

I read a pretty specific description somewhere in these forums, involving a chat log and that when a script with an active listen gets activated, server code scans the chat log and applies the flitering. Unfortunately, that description seems to ignore the important point of how&when the script gets activated in the first place, so it can't be the whole answer.

However, assuming it's at least partly true, it does show why even well-filtered listens add to server lag when there are a lot of them and there's a lot of chat.

With llDialog I set mine up so that the listen is activated during the touch event and turned off in the specific listen events and the timer is just a backup. As Destiny pointed out, it is pretty easy to setup conditionals so that the timer can still be used.

psuedo code

touch_event{
listening = TRUE
counter = 0;
listenhandle = llListen(etc)
}

listen_event(
if(etc)(
you could in effect reset the listen if you need more time by redefining counter as 0 again here
}

timer{
per Destiny
}

Thanks for the input everyone. Destiny & Jesse, I was aware of how to use a counter in the timer to shut off the listen as you both aptly described. But the point of my question was about the cost of running that if statement & counter increment twice a second vs just keeping open a well filtered listen.

All of this may sound like splitting hairs but this is a modeling HUD that will be used by SL models in pretty laggy environments. The fashion industry in SL is pretty obsessed with lag, so I'm concerned to make this as resource lean as possible.

Yep, went to one fashion show and will never go again
How many variables? I would take it this is for different walks and poses. A string of buttons (or with the new detected functions, just a long strip) down the side of the hud with different poses and only one script? No listens and don't have to worry about a menu popping up?

It is a HUD. But I still have to have the dialog & listens for all the user options. Putting all that in the hud buttons would double the size of the thing. Unfortunately, it has to be two scripts. With all the options and notecard reading, even Mono can't manage to contain it all in one script. The code in the second script is only active when loading something.

I may be answering my own question here but ... The only need to write code in the timer event is to trap the possibility of the user hitting the "ignore" button. I could just turn it off if the user responds appropriately by clicking one of the other options, and forget about trapping for the ignore button. I wouldn't be any worse off than if I left the listen running all the time anyways.

you could cheat.... knowing the listen probably isn't going to get a great amount of use (I'm presuming here) you could either change states and have it as a sort of setup mode, or alternate mode (timers can cross states but the code in them could be different)...

or you could abuse the use of sensor repeat to grab an extra temporary timer for your listen killing.... simply have it search for something it can't find (like an av with it's own object key) and drop your listen kill code in there along with a stop sensor repeat call. I believe you can indefinately prolong the sensor repeat in the same manner as a timer (needs testing)

For the sensor idea, be sure to use a short range, and include both a sensor() and no_sensor() event. Oddly enough, unless they fixed it, no_sensor() doesn't work unless there's a sensor() handler.

I suspect that since your script is executing anyway, the cost of one addition and test isn't significant. But I doubt you'd be able to measure the difference either way -- we're just talking about one extra listen per model. Or are you going to have 50 models?

Another thing you could do .. which I have used in ocasions when I needed more than one timer is set another script, that has the time in it and that will send a linked message when the timer event fires.

/54/e7/241442/1.html#post1890883

Overall, having lots of listens isn't terribly bad for the sim, so long as you don't go overboard. But, multiple listens in a single script will throttle your script's performance, it seems, from my experience.

I would really advise AGAINST using a llSensorRepeat() for an "extra timer." Even if no objects are ever sensed, you are probably causing quite a bit of logic to run in the server code (as well as using functionality for an unintended and unintuitive purpose), whereas a simple timer should only have to be queued in a list of events.

If you really need a "second" timer, I would advise rescheduling a single one instead, or using a least common multiple of the periods and some counting logic if you can.

of course there's always the ever obvious choice.... put all the listen logic in a seperate script so it can use it's own settable timer

Thanks for all the ideas. I ended up using two listens. One was very rarely used. It could be set to a large negative channel but needs to be open to all id's. I am able to turn that on and off as needed. The second one manages a dialog that will likely get much more use. Since I am able to filter that one by both channel and id, it is quite specific. Since there will be at most a dozen users of this HUD at any time in a sim, and considering the extra code and complexity of turning it on and off, I decided to just keep it running all the time. From what I've read and the input here, that seems to be a reasonable choice will minimal impact on performance and the sim.