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

LSL Wiki : llSensorRepeat

HomePage :: PageIndex :: RecentChanges :: RecentlyCommented :: UserSettings :: You are crawl338.us.archive.org
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

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


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.

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
There are 11 comments on this page. [Display comments/form]