Don't click here unless you want to be banned.

LSL Wiki : Sensors

HomePage :: PageIndex :: RecentChanges :: RecentlyCommented :: UserSettings :: You are


Sensors allow objects to locate other objects or agents near them.





Sensor functions raise the sensor event, within which the detection functions are used to determine all kinds of info about what the sensor has found.

If no matching objects/agents were found, the no_sensor event is raised instead.


Using sensors increases server load, which can contribute to lag.

Functions | Events | Detection
Comments [Hide comments/form]
I'm pondering about the while-loop note: how is it any use when the sensor event can't execute because the script is still executing the while-loop?
I tried calling llSensor in a for-loop to get around the 16-objects-limit, but it simply didn't work and only detected the last. I'm using a timer-event now with a very small timeout to get around it, which works like a charm.
-- StevenKramer (2006-07-29 10:48:26)
They were not commenting on any "work around" Steven, merely saying that if you place a llSensor() within a while loop, you can get a higher rate of sensors. Leave it at that.

And there is NO way to get 'around the 16-object limit'. Every scan picks up the first 16 objects/avatars. You know there's a llSensorRepeat() that combines llSensor() with a timer...

-- BirdRaven (2006-07-29 11:10:56)
But that was not the point I was trying to make: putting a call to llSensor in a while-loop is not going to work as expected, because events only seem to trigger when a script is idle. If you're repeatedly calling llSensor in a while-loop, you won't get any higher rate of sensors out of it at all, because they won't execute until you return from the function and the script goes idle again. Only the last call will have any effect.

It's like setting the timer five times in a row and expecting five timers to trigger for each interval.

I guess I should elaborate on the second point. It's not all that relevant, I only mention it because that's how I bumped into this. I was actually trying to get position and rotation of prims in a linkset from within just one script in the root prim. So I basically already know what I'm scanning in advance. I might be missing something, but I couldn't find a better way than to record the linked prims' keys, break them all apart and the run scans on them to get what I want.

My comment seems to have dissappeared from this page after I edited it? Silly wiki.
-- StevenKramer (2006-07-30 03:25:03)
Is it actually better to use a timer with llSensor? I've noticed some weird issues with llSensorRepeat, even before 1.11, but what was keeping me from using it was whether or not this would add more load to the server or not.
-- DolusNaumova (2006-07-30 10:09:10)
Apparently, the scope of a sensor is limited to the state in which llSensor() or llSensorRepeat() is called. I worked around this by putting a llSensorRepeat() call in the state_entry() event handler for each of the states in my script, but I wanted to verify that this is the way it is supposed to work.
-- GoozabaGobo (2006-08-01 15:12:25)
It is.

Anyone know of a way to bypass the 96m limit or the 16agents limit?
-- Bobbyb30Zohari (2007-01-15 18:35:26)
Not in a single object, no. Try multiple sensors in different objects and use of llShout() on a high numbered channel to network them.
-- (2007-05-10 06:54:51)