Talk:LlSensor

If PI/4 is a 45 degree cone: if the cone's axis is 1, does the base have a diameter of 2, or a diameter of ~0.82? --Asha Vultee 12:53, 19 November 2007 (PST)

Strictly speaking, it's not a cone. If you want an idea of what the shape will look like run the following script. -- Strife Onizuka 13:20, 19 November 2007 (PST)

float arc;

default
{
    state_entry()
    {
        llSetPrimitiveParams([PRIM_TYPE, PRIM_TYPE_SPHERE, 0, <0.,1.,0.>, 0.0, <0.,0.,0.>, <0.,arc/PI,0.>]);
    }
}

Agent?

Hey everyone, don't you think the "AGENT" flag should have a description along the lines of "This is used to find avatars only". rather than a blank description? I tried to add it myself, but I'm afraid I'm too newbie to understand the formatting... I couldn't find that particular table.—The preceding unsigned comment was added on 17:31, 23 June 2008 by Hikaru Dreadlow

Will do, the table is in a template (Template:LSL_Constants_Sensor) so that it can be included on llSensorRepeat too. -- Strife Onizuka 15:02, 23 June 2008 (PDT)

All Object Sensor?

Hey, can anyone tell me how to make an llSensor() that will scan for ANY object? For example, both physical and nonphysical, scripted and nonscripted, any combination. I tried combining all the flags (besides AGENT) with bitwise |, but it didn't seem to pick up all objects in range.—The preceding unsigned comment was added on 16:45, 22 September 2008 by Crystals Galicia

BloodyRain Rang: seems like LL screwed the sensors up cause 0 as type should find all things, even avatars but it doesnt work. And without that it seems impossible to detect any objects without going through all combinations of ACTIVE PASSIVE and SCRIPTED (7 combinations btw). Hope this get fixed someday. (2008-12-08)—The preceding unsigned comment was added on 18:02, 8 December 2008 by BloodyRain Rang

My apologies for not catching this sooner (or seeing these comments). The documentation was in error about zero being an acceptable value for type. The error stemmed from the documentation being based initially on the tooltips from the client script editor. Most such errors were caught during the initial import but not all. -- Strife ^{(talk|contribs)} 21:21, 8 December 2008 (UTC)

The return of NULL_KEY caveats are a little lacking

The sensor will not trigger if an invalid key (NULL_KEY) is "found" but if the structure of the script allows it the empty NULL_KEY can be returned. As with the simple following.<lsl>default {

   state_entry()
   {
       llSensorRepeat("", "", 3, 20.0, PI, 1.0);
   }
   sensor(integer detected)
   {
       llSay(0, (string)llDetectedName(0));
       llSay(0, (string)llDetectedName(1));
       llSay(0, (string)llDetectedName(2));
       llSay(0, (string)llDetectedName(3));
       llSay(0, (string)llDetectedName(4));
       llSay(0, (string)llDetectedName(5));
   }

}</lsl>I'm not saying this is good scripting but since it returns 5 null keys and 1 avatar (if it only finds one etc.) not being fully aware of the facts while compiling lists for eg. could get messy. Fact: If the event is not structured well to exclude NULL_KEYs they can be returned. -- Eddy ^{(talk|contribs)} 21:21, 8 August 2009 (UTC)

Agent's sit target no longer shows up?

This statement: "If the agent is sitting on an object, the root prim of the sat upon object becomes a second sensor target for the agent (but not if the avatar is outside the sensor arc, see SVC-5145[c])." no longer seems to be true - if you search for an agent, you only get the agent, and not the object it's sitting on. (No clue when this changed, I only tried it for the first time tonight). Redwood Rhiadra 01:22, 2 October 2010 (UTC)

Hi, this feature is definitely confusing, that is what SVC-5145 is, a request to make the behavior sensible and consistent. I will repeat the tests this weekend and see if it is broken in the same old way or if there are new ways too. --Cerise Sorbet 03:30, 2 October 2010 (UTC)

__________________________________

examples on this page are inadequate.

And no, I don't dare try to add any more, because Strife the Control Queen doesn't need examples for himself, so he just deletes them all.

Chaz Longstaff 18:20, 19 September 2011 (PDT)

The ad homimem attack is unnecessary. Taking a look at llListen which is another function that is paired with an event, I added an example script to showcase llSensor with the sensor event. Will that do? --Nexii Malthus 19:45, 19 September 2011 (PDT)

I don't recall deleting any content recently, let alone an example. I remember once in the last year(or two?) deleting an entirely duplicate example (had been double pasted into the article?) but nothing more recent. So I'm at a bit of a loss for words.

I honestly wish people would post more examples, there is even a category for articles in need of examples: Category:LSL_Needs_Example and general improvement Category:LSL FixMe. I generally leave writing examples to others, not because I don't find them useful, I often can't think of a simple useful example, my examples tend to bury the usage in a script that is better placed in the Script Library (which no one ever sees or uses). I don't spend much time here and less time in SL, so I'm pretty cautious with my edits and unlikely to edit an example or script.

So I'm Currently working my way through the new functions and features from Release_Notes/Second_Life_RC_LeTigre/11#11.09.09.240509 but I don't have a lot of time to devote to it. -- Strife ^{(talk|contribs)} 13:21, 20 September 2011 (PDT)

Error with sensor page

has anybody noticed that the sensor page shows up odd when not loged into the wiki?Tmzasz Luminos 20:15, 14 February 2012 (PST)

What browser are you using? -- Strife ^{(talk|contribs)} 12:21, 15 February 2012 (PST)

Never mind, it's definitely a wiki engine issue. -- Strife ^{(talk|contribs)} 12:31, 15 February 2012 (PST)

WEB-4489 -- Strife ^{(talk|contribs)} 10:34, 17 February 2012 (PST)

AGENT vs AGENT_BY_LEGACY_NAME - No ambiguity if there's no name to filter by

The docs say: "If name, id, and/or type are empty or 0, they are ignored." In that case, the name is empty, it's ignored and not to be interpreted in any meaningful way. There is no possible ambiguity on how the name should be interpreted because there is no name to filter by. And please explain the removal of the text about how adding a name affects the result. It was a good example of how to use AGENT_BY_LEGACY_NAME to resolve the ambiguity. Maybe a fictitious name should be used instead of an existing one to prevent self-promotion. I'd agree with that, but that name wasn't even touched. I don't understand the reversal. -- Sei Lisa 10:00, 22 October 2013 (PDT)

I think the example text rollback was an oversight. I shall put it back. I agree, we should choose someone else, for kicks we could make it the last person who edits the page. Thoughts?

I'm going to split hairs a bit, the ambiguity does not go away, it just becomes meaningless. However when you edit the code to add a name, that is when the ambiguity matters and where AGENT bite you in the butt. I'd really would like to kill AGENT off to rid us of this problem. With AGENT we save in letters typed but we get burned by creating a lovely little "Gotcha": For the new users they would see the three flags and expect AGENT to be the generic form that allows you to search by either and most likely to be the one that searches by display name. No AGENT, no misunderstanding in the mind of the reader. Hopefully when they encounter AGENT it will be on the documentation. Regardless, I find using the longer name with the null case distasteful but something I think is worth inflicting on new users. Like using run_time_permissions.

Your gallery solution is the most practical of them all. I not happy with how gallery breaks things but recreating gallery with templates is something I'm going to avoid. -- Strife ^{(talk|contribs)} 21:39, 22 October 2013 (PDT)

On names: using either a famous Linden name or a fictitious name feels better than a variable one. Governor Linden is one I'm considering, and John Doe is another. I'd lean towards the latter.

On the gallery: What I miss with the gallery is a reference in the text that says where to find it ("look at the bottom of this page...")

On the edit: Given that I have yet to see one use case for AGENT_BY_USERNAME, I would aim for readability, and AGENT is preferable not because it's shorter, but because it doesn't confuse with something that is very rarely if at all there (the username or the legacy name). Once you put a name, if that ever happens, which I doubt, especially for a new user, you can change it to the correct type of name. And of course, you can not "kill" AGENT, because AGENT_BY_USERNAME does simply not work at all with llDetectedType, and AGENT_BY_LEGACY_NAME is very clearly a misname for that case. The flags are shared with llDetectedType and there's even no indication in that page that AGENT_BY_USERNAME won't work at all with it. That is a separate issue, but the logic that leads to preferring AGENT there also applies to prefer AGENT when no name is specified in llSensor. -- Sei Lisa 01:16, 23 October 2013 (PDT)

<rant> I consider the introduction of AGENT_BY_LEGACY_NAME a mistake. The whole display name system has been a hack on top of the existing, now "legacy" name system, including the LSL additions. The same logic that led to the introduction of AGENT_BY_LEGACY_NAME should for example have led to deprecating llKey2Name and introducing llGetLegacyName as a synonym, yet that didn't happen. People are expected to know that llKey2Name returns a legacy name and not a display name or username. It shouldn't be any different with AGENT; just adding AGENT_BY_USERNAME to provide access to the new functionality should have been enough. The mere presence of AGENT_BY_LEGACY_NAME has proven to introduce more confusion than the one caused by forgetting to change it to AGENT_BY_USERNAME when using a username in the name (again, if that ever happens). The problem is that it references a name where it isn't applicable, leaving the reader of the code wondering: "Name? What name?" It's akin to giving instructions to someone having a step that is not applicable at all. Imagine telling someone "Go straight through this street; turn right when you see a sign that says 'X', and turn left when you see a sign that says 'Y'" but there is only an 'Y' sign and all that is needed to reach the destination is to turn left when reaching it. The instructions are logically impeccable, and anyone following them literally will reach the destination, but the receiver will wonder where is that 'X' sign. That's what I feel every time I see a llSensor call using "" as name and AGENT_BY_LEGACY_NAME as constant. If one is to be killed, it's AGENT_BY_LEGACY_NAME, not AGENT. </rant>

There, I said it. To elaborate on shortness, being shorter is not at all a reason to prefer it. I really wish that it at least had a namespace prefix like SENSOR_ or OBJECT_TYPE_ or the like, to reduce the chance of name collisions and clarify the scope of its applicability. It doesn't, sadly. -- Sei Lisa 02:00, 23 October 2013 (PDT)

Good point about directions.

llDetectedType: I'll poke the template so it does not show the AGENT_* constants there, only AGENT. I really wish they had prefixed them, also the texture animation constants, who would guess PING_PONG was a texture animation constant without looking it up? LSL was built before it was designed. Personally it all have been better if LSL was object oriented, you wouldn't have had so many silly lookup functions.

Governor Linden was actually who I was thinking of, that or Philip Linden. -- Strife ^{(talk|contribs)} 10:59, 23 October 2013 (PDT)

I have to agree with Sei on this one. It is clearly silly to say you are searching by a name when that is exactly what you are not doing. Like it or not, AGENT exists, and we should demonstrate it. I will continue to use AGENT where appropriate for as long as it compiles. I also belong to the school that feels that the whole display name idea was a stupid mistake. Omei Qunhua 12:52, 23 October 2013 (PDT)

@ Strife:

On names: While I still would lean towards John Doe, I have no strong opinion; Governor Linden is fine with me. Philip Linden could potentially have political issues in future, I hope not.

On prefixes: Sad thing is they made the same mistake recently when they introduced HORIZONTAL and VERTICAL for pathfinding. Talk about namespace pollution. Oh, well.

On the change: would you consider re-applying my changes then?

@ Omei: Thanks for the support :) I wouldn't go as far as calling it a stupid mistake, but it's a hack no matter how good or bad idea it is. -- Sei Lisa 13:20, 23 October 2013 (PDT)

Thanks for the change, very appreciated! -- Sei Lisa 10:05, 24 October 2013 (PDT)

You are welcome. I would be ok with causing a little political uproar. Streisand effect, would be good for the wiki. -- Strife ^{(talk|contribs)} 22:01, 25 October 2013 (PDT)

Can it look the other way?

I'm trying to make a single prim see 30 things that are scattered symmetrically around it. A single sensor() call can't see them all, as there are too many. I thought I could look at the 15 in front, and then the 15 in back, but the arc is always in the forward direction. Is there any way (a negative arc?) to look just behind and not in front? I will do the experiment :) but if anyone knows... Dale Innis (talk) 20:08, 15 August 2015 (PDT)

Try rotating the prim. -- Strife ^{(talk|contribs)} 12:33, 16 August 2015 (PDT)

Diameter or Radius?

Why does this functions wiki page not explicitly state weather the float RANGE, is a Diameter, or a Radius?

Just calling it a Range, seems kinda ambiguous. Sure many of us can just assume, or experiment to be sure. But it seems like info that belongs on the upper most definition of the function.

Maybe I'm just missing it due to sleep deprivation. ThumpieBunnyEve Hax (talk) 15:23, 18 March 2015 (PDT)

"Range" means distance from the prim's or the wearer's center. That forms a sphere around said center, with the range's radius, within which everything is "in range" and everything outside is "out of range". Therefore it is the radius. --Pedro Oval (talk) 04:44, 19 March 2015 (PDT)

I submit my edit to the page for clarity. I was confident my mention of radius, and "distance from center" was sufficient, valid, and helpful. If it doesn't get changed back, then yay for a positive contribution! ThumpieBunnyEve Hax (talk) 07:33, 19 March 2015 (PDT)

I personally find it more confusing when put that way. It doesn't state the center of what, or the radius or what geometric figure or why it matters, while "range" is clearly implicitly referring to a distance, which logically must be from the script that has the sensor to the detected object. I don't know where did your confusion between radius and diameter come from, as not many people will realize immediately that the range volume forms a sphere. My vote is for that change to be reverted. --Pedro Oval (talk) 08:57, 19 March 2015 (PDT)

I fail to see where saying "Range" by itself is any more descriptive or accurate. It leaves more to the imagination then saying Radius, which by definition indicates from center point, inclusively to an end. Range, in fact can be easily misconstrued as a diameter, a square field, or a point at a variable distance forming a ring. Semantics are important and layman's terms such as "Range" when referring to a Radius, do not provide enough info for an accurate visualization of the procedure. I prefer to call a dog "a dog", rather then "the thing". One I know not to store in the attic for a few years, the other, not so much. If you don't understand what the word Radius means, you can easily look it up in a dictionary, but looking up "Range" in a dictionary wont provide you any insight as to weather this process uses a diameter or a radius. In fact many people who I've taught scripting to have asked me if "Range" was halved, when the Arc, was PI / 4. Implying they presumed "Range" to be a diameter. I wonder where they got that notion?? Perhaps it was from the lack of clarity in this functions description. I suppose Ray-Length could be another plausible word. but it's 2 words. and "Length", by itself would also not distinguish between diameter and radius as both are a measure of length. ThumpieBunnyEve Hax (talk) 09:56, 19 March 2015 (PDT)

radius: 1. a straight line from the center to the circumference of a circle or sphere. 2. the thicker and shorter of the two bones in the human forearm.

There's no sphere here. There's a vector that goes from the sensor to the potentially sensed object, whose length can be in-range or out-of-range. And there's another vector, the X axis of the prim, whose angle with the first vector determines whether the arc is in-range or out-of-range. No idea where your pupils got the concept of radius from, but I'd bet that it's either from their own imagination or because you introduced it as a sphere in the first place. --Pedro Oval (talk) 11:04, 19 March 2015 (PDT)

Quote: [ it's either from their own imagination or because you introduced it as a sphere in the first place. ] ~ Pedro Oval

Response: I'd say it's more probable they infer it from this image, which is part of the wiki for this function itself. http://wiki.secondlife.com/wiki/File:Sensor_pi.png ThumpieBunnyEve Hax (talk) 13:10, 19 March 2015 (PDT)