LSL Wiki : llSensorRepeat

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.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
      \|/

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:

Constant	Value	Senses
`AGENT`	1	agents
`ACTIVE`	2	objects that are physical and are moving and/or objects containing an active script
`PASSIVE`	4	objects that are non-scripted (or script inactive) AND not moving (whether physical or non-phsyical)
`SCRIPTED`	8	anything that contains an active or passive script

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

default
{
state_entry()
{
llSetTimerEvent(1); //Repeats the sensor every 1 second.
}
timer()
{
llSensor("",NULL_KEY,AGENT,95,PI);
}
sensor(integer num_detected)
{
//Do Stuff here.
}
}
}
}

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:

default {
  state_entry() {
    llSensorRepeat("", "", AGENT, 1.0, PI, 0.5);
  }

  sensor() {
    llSleep(1.0);
  }
}

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