Talk:LlSensorRepeat
Scanning adjacent regions
If I remember correctly using llSensorRepeat you can get sensor data from adjacent regions every (I think) 5 seconds. Should we include this information in the article? This does not affect llSensor. I am not sure if this has been fixed in previous updates. --TxMasterG Ping 15:06, 10 April 2007 (PDT)
- I've not heard of this restriction before but if it can be verified then it belongs in the caveats section. I have not done worked with llSensorRepeat in a long time. -- Strife Onizuka 20:18, 10 April 2007 (PDT)
It seems to me that if you use 0 as your 'type', it never runs sensor() or no_sensor(). Why is this? How can I make it detect everything?
- Try
ACTIVE | PASSIVE | AGENT
-- Strife Onizuka 10:10, 17 May 2008 (PDT)
The initial description is misleading: "Performs a single scan [..] and repeats every rate seconds." In fact, it lies dormant for rate seconds after the call, and then fires the first scan. Tali Rosca 10:31, 15 October 2008 (PDT)
Confirmed false positives
llSensorRepeat does in fact return false positives from thousands of meters away. This is to include adjacent simulators. These false positives even override safety detections such as llOverMyLand from within a sensor event. The use of llSensor in a timer event as opposed to llSensorRepeat behaves properly. When detecting agents for the purposes of tresspass warnings or ejections this is extremely bad (especially if you intend to maintain a friendly relationship with your neighbors).
I should like to note, however, that while this is a nuissance, it does function properly within it's OWN simulator {as far as not overriding say llOverMyLand( llDetectedkey(X)) } .. All of this holds true compiled for MONO as well as LSL.
I have submitted support tickets for this, and we could all probably benefit from a little higher escalation on it if everyone who has encountered this does the same.
Cheers,
Mel
- Support ticket is the wrong way. Please open an issue in the Jira, in case there is none so far.
- Lynch (talk|contribs) 22:25, 28 December 2008 (UTC)
Sense Avatar by UUID?
So, if AVATAR is depreciated, what's the accepted way to search for an avatar by UUID, rather than by username? Is it still llSensorRepeat("", llGetOwner(), AVATAR, 50, PI, 10);? --Sheridan Otoole 23:23, 19 October 2010 (UTC)
I guess you could use either AVATAR flag. -- Strife (talk|contribs) 23:27, 19 October 2010 (UTC)
Second Example
Is it me or does the second example have no way of clearing avatar names from VISITOR_LIST
? Not sure we want copy/pasted greeters stack/heaping over time! Also since they're fairly common things for people to want to script, it might make sense to add some best practices such as storing avatar's by UUID, and using llGetDisplayName(). For example:
<lsl>// Written by Evans Love.
// Continuously scans for visitors within 10 meters and reports new visitors to object owner.
//-------------------------------------------------------------------------------------
// Variables list VISITOR_LIST; list VISITOR_NAMES; float SCAN_RANGE = 10.0; float SCAN_INTERVAL = 30.0;
// Functions report_new_agent ( ) {
llOwnerSay ( llList2CSV ( VISITOR_NAMES ) );
}
//Program default {
state_entry ( ) { llSensorRepeat ( "", NULL_KEY, AGENT, SCAN_RANGE, PI, SCAN_INTERVAL ); } sensor ( integer number_detected ) { integer agent_number; for ( agent_number = 0; agent_number < number_detected; agent_number++ ) // Iterates through all Agents detected. { key this_agent_key = llDetectedKey ( agent_number ); // Working Agent Key integer index = llListFindList ( VISITOR_LIST, [ this_agent_key ] ); if ( index == -1 ) // If the Agent is not on the list. { string this_agent_name = llGetDisplayName( this_agent_key ); if ( ( "" == this_agent_name ) || ( "???" == this_agent_name ) ) { // Fallback to legacy name if we can't get their display name this_agent_name = llDetectedName( agent_number ); } VISITOR_LIST += [ this_agent_key ]; // Appends the Agent to the Visitor List VISITOR_NAMES += [ this_agent_name ]; // And store their name
llRegionSayTo ( this_agent_key, PUBLIC_CHANNEL, "Welcome!" ); report_new_agent ( );
integer length = llGetListLength( VISITOR_LIST ); if ( length > 100 ) // Get rid of excess names { length -= 101; VISITOR_LIST = llDeleteSubList( VISITOR_LIST, 0, length ); VISITOR_NAMES = llDeleteSubList( VISITOR_NAMES, 0, length ); } } else // If the Agent is already on the list. { } } } no_sensor ( ) { }
}</lsl> Or something like the example I posted in Talk:llSensorRemove: <lsl>// When touched, an object with this script will continue scanning until no avatars are found within 10m integer scanning = FALSE; default {
touch_start(integer x) { llSensor("", NULL_KEY, AGENT, 10.0, PI); // Start the scan } sensor(integer x) { string text = ""; vector myPos = llGetPos(); // Loop through avatars from furthest to nearest while ((--x) >= 0) { key id = llDetectedKey(x); // Get display name, or use legacy name as a fallback string name = llGetDisplayName(id); if (("" == name) || ("???" == name)) name = llKey2Name(id); // Add distance to the name name += " (" + (string)((integer)llVecDist(myPos, llDetectedPos(x))) + "m)"; if (text) name = "\n" + name; text += name; } llSetText(text, <1.0, 1.0, 1.0>, 1.0); if (!scanning) { // Repeat the scan every 30 seconds llSensorRepeat("", NULL_KEY, AGENT, 10.0, PI, 30.0); scanning = TRUE; } } no_sensor() { // No avatars nearby, lets turn off the scan llSetText("", ZERO_VECTOR, 0.0); llSensorRemove(); scanning = FALSE; }
}</lsl>
-- Haravikk (talk|contribs) 12:52, 14 September 2012 (PDT)
- I tossed in a quick fix to limit the list to 200 names... with the most recent in front, and only repot the most recent entry. I f someone else wants to take it farther feel free
-- Void (talk|contribs) 23:14, 15 September 2012 (PDT)
- Omei Qunhua 14:39, 25 December 2012 (PST)Just a shame the author of the second example nor any subsequent editors didn't even bother trying to compile the script on the live page LOL. "OK" ==>> [OK] needed on line 37.
- What do we think new scriptors will make of all these corrupt examples?
- It's the responsibility of original editors to make sure scripts compile before adding them to the wiki. If every editor checked ever script for compile on every page they edited (even if that wasn't a section they were editing) then we'd have far fewer editors... what's more amazing to me is that someone that can obviously see the problem and easily correct it chose not to. I've added the suggested fix, and no, I didn't check the compile because I happen to be at work, and I'll probably forget all about doing it if it doesn't get done now. If you see a mistake by all means remind people to check their edits for accuracy, and if you are able, go ahead and fix it too.
-- Void (talk|contribs)