llSensor question

[Innula Zenovka]

I'm trying to debug something and I'm running into difficulties understanding data I'm seeing because, I realise, I'm not completely sure how llSensor is supposed to behave.

Assuming I'm looking for scripted objects called "Target" in an environment where there are probably a lot of scripted objects around.

I know from the wiki that "Only 16 objects will be scanned each time."    I know that this means if I call

llSensor("","",SCRIPTED, 20.0, PI); 

it will return a list of up to 16 scripted objects, if there are that many within a 20 metre radius, ordered according to how close they are to the scanner.

However, what I'm less sure about is whether the simulator actually picks the 16 nearest objects and presents them in an ordered list, or if it picks 16 objects within the radius according to some other criterion and then orders them by distance from the scanner.    

I suspect it's the former but I'm, given what I'm seeing in my tests, I'm  not completely sure, and would find it very helpful if someone knows the definitive answer.

Similarly, if I run 

llSensor("Target","",SCRIPTED, 20.0, PI);

am I guaranteed to find all the scripted objects called "Target" within the 20 metre radius, up to a maximum of 16, or will the scanner scan all the scripted objects in range, select 16 according to whatever hidden criteria it uses, and then return details of any that happen to be called "Target"?    

I would expect the former behaviour but, based on what I'm seeing, I'm really not sure.   Again, it would be very helpful if anyone could point me towards the definitive answer.

[Rolig Loon]

I wish I could tell you something definitive but all I can say for sure is that you will get a list of no more than 16 objects within your search range.  I strongly suspect that they are ordered by distance, based on the few times I have bothered to check, bit I don't know if that's a rule.  I am reasonably certain the the first one has always been the closest when I have cared. to look.

When you search for a named object, again I strongly suspect that the function filters first for the target name and then for the range, not the other way around. So, if there are 25 objects in range and 15 are named "Target", you'll always see all 15 Targets and that's it.  Again, though, I cannot be 100% confident that's a rule.

[steph Arnott]

12 hours ago, Innula Zenovka said:

 

The distances are graduated on accuracy. Accrurate to say five meters then it get more and more 'aboutish. Further away the worse the 'aboutish' gets.

[Fenix Eldritch]

I set up a test with 24 prim cubes as shown in the attached image. The 20 green cubes had an active script and the remaining red ones had no script. All cubes were named "Target" and all had a unique description text which I could use to identify in the sensor results. The green cubes' descriptions were essentially "ok x" where x was 1-20 in sequential, increasing order. The others were similarly "bad x" with x being 1-4 again, in ascending order from the left where the sensor prim was.

My scanner used the same senor command as your example and when I looped over the num_detected range and spoke the detected prims' descriptions, I got "ok 1" through "ok 16" in the expected ascending order. Then, as a second test, I put a valid script into that red cube just over the line of green ones. The resulting sensor event gave me the expected "ok 1" through "ok 5", followed by "bad 4" and then continued with "ok 6" to "ok 15". This is what I was expecting to see.

It's a simplistic test, as far as I can tell, it appears that the sensor will pick up the first 16 scripted objects named "Target" and nothing more. It'll ignore other similarly named prims that don't have an active script and it didn't pick up the extra ones beyond the nearest 16.

Something to note is that my first attempt at this failed because I was using the default "hello world" scripts in my target prims. I neglected to realize that the script had to be actively doing something for the sensor to pick it up using just SCRIPTED. If it was running, but idle, the sensor wouldn't flag it. So my new target test script was just a while(true) loop. Is it possible that some of the target scripts you're using are idle at the time of the sensor sweep?

[steph Arnott]

13 minutes ago, Fenix Eldritch said:

 

 

Which is expected because you have it on one plane. Try that in three. You fail to understand the the sensor estimates the further the distance. What you have done proves nothing in regards to the OPs question.

Edited March 2, 2019 by steph Arnott

[Fenix Eldritch]

I would expect the results to be the same in three dimensions.

Using the same group from above, one at a time, I linked a target prim to the scanner prim and then rotated about the root randomly. I then unlinked and repeated the process for the next target prim. Eventually I had a cloud of target prims clustered around the scanner at arbitrarily XYZ positions - but because I essentially orbited them round the scanner, their distance from it remained constant and thus easy to verify the order. Lo and behold, the sensor reported everything in the same order as before.

[Rolig Loon]

6 minutes ago, Fenix Eldritch said:

I would expect the results to be the same in three dimensions.

Using the same group from above, one at a time, I linked a target prim to the scanner prim and then rotated about the root randomly. I then unlinked and repeated the process for the next target prim. Eventually I had a cloud of target prims clustered around the scanner at arbitrarily XYZ positions - but because I essentially orbited them round the scanner, their distance from it remained constant and thus easy to verify the order. Lo and behold, the sensor reported everything in the same order as before.

Nice work.  Thank you.  I have wondered about that for years and have assumed that it was true.  Thank you for testing, Fenix.

[steph Arnott]

6 minutes ago, Fenix Eldritch said:

I would expect the results to be the same in three dimensions.

Using the same group from above, one at a time, I linked a target prim to the scanner prim and then rotated about the root randomly. I then unlinked and repeated the process for the next target prim. Eventually I had a cloud of target prims clustered around the scanner at arbitrarily XYZ positions - but because I essentially orbited them round the scanner, their distance from it remained constant and thus easy to verify the order. Lo and behold, the sensor reported everything in the same order as before.

Okay. Dream on. The server would over load and crash if the results were as accurate as you want. Sensors are only an estimation, nothing more. Then again you change strings and assingn them as keys which messes them up.

 

Just now, Rolig Loon said:

Nice work.  Thank you.  I have wondered about that for years and have assumed that it was true.  Thank you for testing, Fenix.

Why? Am suprised that you do not know that the server is capped to stop this.

[animats]

Try moving the prims around and testing again. Order of creation might matter.

[Qie Niangao]

On 3/1/2019 at 7:20 PM, Innula Zenovka said:

... but, based on what I'm seeing, I'm really not sure.

I wonder if you could set up a test scenario that demonstrates what you're seeing that's causing you to doubt intuitions.

AFAIK sensors are based on the detected object's origin, not its nearest surface tangent to the sensor ray. In contrast, llCastRay() tries to use surface intersection (but for some Havok-known shape that's not bounding box and seems to sometimes deviate from the collision envelope). This all may have nothing to do with what you're seeing, though.