llSensorRepeat(string name, key id, integer type, float range, float arc, float rate)
Performs a repeating sensor
scan for name
, and/or SCRIPTED
) within range
meters and arc radians
of forward vector
can be empty or 0). A range of 0.0m does
perform a scan. The parameters
have the same function as llSensor
, except rate
, which defines the number of seconds between repeated sensor
or no_sensor event calls
. The sensor does not persist across a state change.
Raises the sensor
and no_sensor events
. ^ .
\ | / If arc is x radians,
\ | / the sensor will look for x radians
\ | / around the object's forward vector,
\ | / so the actual sweep of the search is
\ x|x / 2x radians, and thus PI radians will
\ | / search all around the object
- This function will wait for rate seconds before doing the first sensor sweep.
- The limit of range is 96m. Values greater than 96m will work, but will only be treated as 96m. (As of SL 1.6.12, there is a bug/feature where it can return agents/objects up to 300m+ away.) ( As of SL 1.18.3 , this bug/feature has been Resolved Sadly :( The limit now is actually 96m .)
- Active: the script is running and currently doing something. A basic default script that is running may not be active but a script that has a command involving monitoring (like llListen) will always be active. Active means sim resources are being used.
- Inactive: the script is running, and awaiting an event, but isn't doing any monitoring (like llListen); no sim resources are being used.
- Running scripts may be active or inactive (or, to use SL language, active or passive).
: After using llSensor
to find a passive, active, and/or scripted object, llDetectedType
can be used to check the active flag (meaning physical regardless of motion or not) and the passive flag (meaning non-physical even if the script is active^).
So, it seems, llSensor
use the passive and active flags differently.
Values can be combined to search in multiple categories using bitwise OR (|)
. For example, llSensor("", "", AGENT | ACTIVE, 25, PI)
would search for both agents and physical objects. Because the scan arc is measured in all directions from the forward vector, specifying PI radians will search 360 degrees.
Q: ORing sensor types was broken for a long time, is it for sure fixed now?
A: It still seems to be broken as of 2004/08/23.
A: Still mostly broken as of 2005/10/16. AGENT|ACTIVE doesn't work, AGENT|PASSIVE doesn't work, AGENT|SCRIPTED doesn't work, but PASSIVE|ACTIVE does.
A: As of 2006/01/05, this problem seems to be resolved, and everything works as expected. However, the SCRIPTED flag has some peculiar behaviors when combined with others; see the bottom of the llSensor page.
A script can have only one sensor at a time. The current sensor is removed by another call to llSensorRepeat
For single-use sensors, see llSensor
. If you don't need the scan to be repeating ALL the time (and you usually don't), use llSensor
. Use llSensorRemove
to turn off.
will not detect the object that contains them. This also applies to attachments
--they won't detect the agent they're attached to, unless the sensor script is within a child
: Using the no_sensor
event will cause the repeating sensor to stop. Use a "dummy" sensor event with nothing inside the brackets if you just want to react to something not being found.
Detecting objects in adjacent Sims.
Objects/Agents in adjacent Sims will only be detected approximately once every 5 seconds. Between times, no_sensor will be triggered instead (assuming there is nothing in the sensor's sim
that is detectable.
- A sensor rate slower than 5 seconds will only sporadically detect objects in adjacent sims.
- Sensor rates of 0.25 seconds detect objects approximately one time in twenty.
- Sensor rates of one second detect objects every fourth to sixth time.
- llSensor never detects objects in adjacent sims.
Another way of creating a sensor repeat, heres a low lag Example - James Benedek
Also see llVolumeDetect
. Depending on what you're trying to do, it might be a vastly more efficient way of going about it.
Delaying in the sensor
event does not cause old data to start stacking up. Sensor sweeps seem only to run when the script is not processing an event. For example:
The above code will result in one sensor() event per second with recent data, rather than filling your event queue with a sensor event every half-second as you might fear. This means it's safe to have a sensor running frequently but occasionally do things that require delays.
I might have found a bug involving llSensorRepeat in a hud object, can anyone verify this? What happens is that if you put llSensorRepeat in a hud object and then the hud object rotates via a scripted llSetRot, the llSensorRepeat stops repeating. - LuccaKitty
This article wasn't helpful for you? Maybe the related article at the LSL Portal
is able to bring enlightenment.