Using llListen - Always bad?

I've written a couple scripted objects that use llListen to accept configuration commands.

In order to minimize adverse effects (lag) I only listen on a specific (non general) channel and only listen for the Owner.

Someone told me in game that I should avoid putting listen commands into any of my scripted objects, that they all contribute to lag. This was contrary to something I read (either in forum or in the LSL Wiki) that implied not listening on the general channel was the preferred solution.

So - what's the popular opinion? Are listens, in general, bad? or just if coded poorly?

1.7 has a shiny new scheduler, so scripts won't contribute to sim lag. If you have 4000 scripts in an object, the scripts might run slower, but the sim won't.

If you're doing it on a non-zero channel, and you don't have dozens of them, you're fine.

llListen only adds to lags if one of two things are true.

FIRST - Listening for Channel 0 and filtering out things with if/else statements in the listen call itself.

SECOND - Using llListen a lot. A lot of listen events firing off for random reasons seems to eat processes like crazy.

What you want to do is have things filtered within the llListen itself. That is, as you did with the specific channel and owner only, is one way to do it. Go you. That minimizes lag because the script ignores everything that isn't on that channel and from the owner.

Same thing goes for having prims issue commands to one another. Put it on a random channel and have the llListen ONLY trigger for certain commands and/or from certain objects. The llMessageLinked does wonders for that as well, as it makes objects talk ONLY to other prims their linked to.

What happens with lag increasing comes from when you don't filter things out within the llListen itself. If you use llListen(0, "", NULL_KEY, "" anywhere where a lot of things are said, that is one of the biggest lag crimes possible. Basically, that calls listen EVERY time ANYBODY says ANYTHING. See where I'm going with that?

Always bad - well yes, sort of, but sometimes the only solution.

Non-zero channels are better almost certainly (there is some debate about it).

There are things like using a touch to trigger the listners and a timer to turn it off that are nice too - if it's to issue commands to a radio say you don't need it on ALL the time do you? Of course if it's for your security system you just might, but the number of always on listeners required is pretty low actually.

Filtering makes an odd effect - actually pretty minimal on lag, it still listens to everything then thinks about triggering the event to put it crudely, but it makes your chances of getting interference lower, especially if you're on channel 0.

There's really no other viable way of communicating between an object and an agent, and the alternatives for inter object communications aren't necessarily better (link messages being the exception, intraobject communication is much better for most purposes).

So think about avoiding them, but when you must use them, but try to make them only on when you need them.

1.7 may help, although sims that run slowly under script load already are likely to remain running slowly I suspect - and good coding to reduce sim load is still going to be worth it.

llListen is the best solution for medium-range, many-to-one communication.
For short range comms, consider linking the objects in question and using link messages.
For long range, use email, though its only point-to-point.
For long range broadcast, consider emailing an external app/website that will call your objects back with XMLRPC.
For a project with heavy comms and mixed distance requirements, go with a hierarchical network topology that uses link messages where possible and relays them over llShout and/or llEmail transparently.

There are simple ways to only enable the llListen when needed. Use touch to open a dialog box, for example, with a timer to close the listen after inaction, or close the listen after the command is entered.

However, regarding physics, I was still able to get time dilation down to 0.00 with "only" 1500 physics balls in a giant box.

However.. recovery was faster

But that's not what I was talking about, was it?