llSensorRepeat(string name, key id, integer type, float range, float arc, float rate)
Performs a repeating
sensor scan for
name and
id with
type (
AGENT,
ACTIVE,
PASSIVE, and/or
SCRIPTED) within
range meters and
arc radians of forward
vector (
name and/or
id can be empty or 0). A range of 0.0
m 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
\|/
Notes
- 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 .)
llSensorRepeat constants:
Table Notes
- 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).
Note: After using
llSensor/
llSensorRepeat 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/
llSensorRepeat and
llDetectedType 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 or
llSensor (or
llSensorRemove, obviously).
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.
Note:
llSensor and
llSensorRepeat 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 object.
Note: Using the
no_sensor event
without a
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.
Functions |
Sensors