Difference between revisions of "Talk:LlSensor"

From Second Life Wiki
Jump to navigation Jump to search
Line 87: Line 87:
: 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]].
: 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.  -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 21:39, 22 October 2013 (PDT)
: 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.  -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 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. -- [[User:Sei Lisa|Sei Lisa]] 01:16, 23 October 2013 (PDT)

Revision as of 01:16, 23 October 2013


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)