Object finder using llSensor

[Tighern McDonnell]

Ok before I spend a good bit of research time learning new functions (although I really enjoy doing that...) I am looking at making a hud that will search for a specificly named item. User clicks on the hud, it looks for the item at 15m if it does not find it the color stays red, if it does it it searches at distance of 5m if it does find it then it turns green, if not it turns yellow. The name of the object is going to set and not a variable. Is using llSensor the best way for this or is there another option out there? Also if llSensor is the best route are they any other resorces out there better than what little bit I can find on the LSL Portal wiki? It has good information but as a beginner I am not quite picking it up. Thanks again for any help. Almost have this project nailed down and useable. 

[Innula Zenovka]

Hi, Tighern.

If you're using llSensor() then, in the sensor event, you have access to the llDetected functions, among them  llDetectedPos().    This means you know exactly where your target is, and, if you use llVecDist  to compare that with llGetPos(), you know exactly how far away it is.   So only one pass of the sensor is needed.

You ask if a sensor is the best way to do it.   I don't know about "best" but an alternative, if you're making the object for which you're searching yourself, is to ask the object if it's there, using llRegionSay  (if you are confident it's going to be on the same sim) and a very negative channel, and grab the object's uuid in the listen event if it replies -- as you probably know (but it took me a while to realise), the uuid is key id in 

listen(integer channel, string name, key id, string message)

Then, once you have the UUID, you can use llGetObjectDetails to find out a lot about the object, including where it is.   You can grab the key with a sensor, of course, using llDetectedKey(), 

I just mention this as a possible alternative method to consider.  But, either way, you only need one pass of the sensor, I think.

[Qie Niangao]

Most likely a single llSensor() will get what's needed for this, unless the object or the avatar is moving and the HUD indicator is supposed to update as that motion occurs. If the user is supposed to press the HUD again for each scan, that's not a problem.

Another thing that's probably not a problem for this application is that a sensor only returns the nearest 16 objects that meet its filters. In this case, there's a name-specific filter, so that should be fine (assuming nothing is spreading same-named chaff).

[Tighern McDonnell]

Excellent. Exactly what I as expecting to hear back. Just wanted to check as I am still VERY new to scripting. Thanks. Will see what I can get put together in the next couple of days.