Which is cheaper, sensor or listen?

Which would cause less strain on the sim?:

1 sensor with 4 listens and 16 link messages.

or

4 sensors with 16 link messages.

Adam

How about one time limited listen on touch and howevermany link messages you need?

Touch not possible, I'm just interested to know if 1 sensor with 4 listens is better than 4 sensors with no listens.

Part of answering your question, is that you also need to know how often each of those events would actually trigger, and how much filtering they have to do in the given environment to sift through stuff you don't need, and find the data you want.

So all things being equal, choose the one that:

1) Runs the least (i.e., sensors = objects/people coming and going, listen = chatting).
2) Generates the least data to process.

If you have 4 sensors running in an area where people are rarely chatting on the channels to which you listen....the sensors are more laggy.

If you have a lot of people talking on channels to which you're listening and a short-range sensor that repeats slowly and has heavy filtering, the listens are more laggy.

Thanks Kenn, that's what I suspected. Indeed, it is a short range sensor (10m), on a 1-second repeat. The listens are on a channel that nobody/nothing else is communicating on, so it seems it'd be better to use 1 sensor and 4 listens.

Is it really not an issue how many link messages there are? I find that hard to believe, unless the link message is a client-side communication, which seems unlikely. Surely link messages contribute to lag?

Adam...in both of your situations, you had 16 link-messages listed. Therefore, there was no variation in the lag.

Link-Messages do cause script-processing, as they are script functions, but they do tend to be much more efficient than a sensor or a listen.

Sorry Kenn, I was referring to a different answer where someone said use as many link messages as you need.

I really really wish the linking mechanism in SL could be nested - in so much of my work I end up having to use way too many sensors and listens in place of link messages because I can't nest links. How much more efficient could link messages be though, since ultimately aren't they listens with very defined filters?

In most practical applications running 4 sensor-repeats is going to be more costly than 1 sensor-repeat and 4 listens.

I'm assuming you are transmitting the sensor result to 4 objects via chat? It is reasonable to expect this to be less costly than running the sensor in each of those objects. As above mentioned the only way it could be more costly is if there is other chatter on the comm channel.

Don't wanna seem stupid or get the thred too far off the OT, but I'm a novice+n00b+everythingelse scripter....

A sensor can detect objects as well as people?

Yes.

http://rpgstats.com/wiki/index.php?title=LlSensor

"Values can be combined to search in multiple categories using bitwise OR (|). For example, llSensor("'", NULL_KEY, AGENT | ACTIVE, 25, PI) would search for both agents and physical objects."

Why can't you nest them?

If you link a linkset to another linkset, they all become the same single linkset, not two linksets inside a linkset. I really, really, really hope that I've been wrong about this the whole time and you're about to show me how I can create a heirarchy inside a linkset

Can you use llVolumeDetect() instead of llSensor() ?

Not in this case, because of the linkset problem (ie, if linksets could be nested then yes I could use llVolumeDetect in this case), but also because of the size of the area i'm sensing.