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)

I'll work on clarifying that. -- Strife ^{(talk|contribs)} 11:50, 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)}

I have personally fixed at least 15 scripts this month, none of which I contributed in the first place. This time I decided to firstly leave a comment to gauge the reaction, before returning to apply the fix. Void, you were one of the editors of that very same script who didn't compile it, despite editing it twice, so don't try passing the buck to me. If you're at work and can edit this page, I'm sure you can run lsleditor at least. If not, by all means leave me a note, I'm usually free to compile with lslEditor or in world, and happy to do so. Omei Qunhua 01:12, 26 December 2012 (PST)

I did not mean to imply you were at fault, that was my mild annoyance at a note without a fix by a capable editor, but I'm past it. If any blame was to be had it was the user who made the original addition. And no I cannot run LSLEditor at work, nor the SL client. I did assume that the original code compiled and was careful not to introduce any errors into the portion I edited in response to Haravikk's notice of the stack/heap issue. Should I have tested it? probably. should I leave a note every time I make a minor change? that's iffy TBH. it tends to annoy people since it leaves work for them (that may be unnecessary) and then they don't want me to edit... I'm amenable to either route though, so if people would prefer I don't make script fixes without a confirmed compile, or if a talk notation is preferred, say the word, and I'll do my best
-- Void ^{(talk|contribs)} 08:21, 27 December 2012 (PST)

BUG-2366

I think "llSensor removes the sensor repeat if called AFTER llSensorRepeat" is expected behavior, and it was only omitted from this wiki. The limit of one active sensor per script is documented in the old wiki back to the oldest edits that survive, http://lslwiki.net/lslwiki/wakka.php?wakka=llSensorRepeat/revisions --ObviousAltIsObvious Resident 17:00, 23 April 2013 (PDT)

Agreed; declaring a new sensor always overrides any previously set one, this includes setting a new repeating sensor which will reset the timer to the new value, for example if you had a 10 second repeating sensor and changed to 30 seconds half way through, then the next sensor(), or no_sensor(), event will occur in 30 seconds instead of five. It's definitely worth being clear, as a regular sensor overriding a repeating one is strange, even though correct, behaviour since there's no obvious reason that a standard sensor would need to be stored anywhere, while a repeating one clearly needs to be.
-- Haravikk ^{(talk|contribs)} 02:37, 24 April 2013 (PDT)

I'm not so sure, I would have thought it would have been documented on one of the wikis. It's the sort of thing someone would have come across. Folks have been using repeating sensors for timers for a while (this isn't something I advocate) and I have trouble imagining one of them didn't try also using a sensor at the same time. The only way to know is to look at public code and see if folks use both functions at the same time. -- Strife ^{(talk|contribs)} 19:47, 24 April 2013 (PDT)

It was documented in the other wiki, only missing here. Unsure where that kind of limit is supposed to fit in your template schem. --ObviousAltIsObvious Resident 22:46, 24 April 2013 (PDT)

-_- I just not have read carefully enough. I'd put in caveats on both llSensor and llSensorRepeat. I can get to it tomorrow or the next day. -- Strife ^{(talk|contribs)} 01:45, 25 April 2013 (PDT)