Sensor Detector

Hi Again-

Sorry if this has already been suggested. If it has, please consider my post as support for the original suggestion.

I was thinking about a sensor detector. The basic idea is that an object that has been "touched" by a sensor would know. Or at the very least, could know.

Thanks for reading-
Ivan

This is an interesting idea, however, I can see a few problems.

If the sensor is scanning for type AGENT, do the avatars behind the AGENT get notified they've been scanned? This could lead to a LOT of spam in certain areas, and get really annoying for things that use llSensorRepeat() for things like local area avatar scanners.

Also, if a griefer's SCRIPTED object type senses its being scanned... it would have time to change it name and position before you could have a chance to track it at the coordinates or by name to delete it.

Regards,

-Flip

Well, I'd imagine that they'd only get notified if they were running scripts to detect whether or not they're being detected by a sensor.


You could always ding it by key... but then, I suppose, it could always just rez a new instance of itself and then die. Mmm... I love arms-races.

One problem with this is that it would probably be rather laggy. It's not like a sensor is actually 'pinging' anything actively, like a radar IRL does; I imagine it's more akin to looking things up in a database someplace. So a function to detect this would have to wait for something to query its database entry, then ask whatever's querying it if it's a sensor. Hmm. Actually, I'm just babbling, because I have NO idea how server-intensive something like that would be. I'll shut up now.

This defeats the whole point of sensors. Not that sensors are awfully useful compared to a more RDBMSish approach to data acquisition...

Ah-buh?

How so?

RDBMS - Relational DataBase Management System... or just database for short.
Sensors are kinda useless. Actually, anything restricted to a small portion of SL space is at best unoptimal. The 96m range means you can't even scan a full sim horizontally, let alone vertically, and the 16 object limit is particularly crippling in a world where you are typically surrounded by hundreds or thousands of objects.
I would prefer to read a list of objects or agents with a more SQLish approach... I mean, they have to be stored somewhere, give us the raw list, dammit.

That IS kinda odd, isn't it Eggy. I mean, stuff like llGetLandOwnerAt() doesn't have a range; it can scan anyplace in the entire sim. Of course, it's not looking at objects on the asset server or whatever, just the dirt under our poor avie's feets.

I guess sensors work the way they do to give the illusion of a real space, or something. Or maybe there's some arcane performance issue involved that's way over my head.

We were asking about the "defeat the purpose" comment. How so?

Thats the general idea. A Sensor Sensor that is instantiated in the same manner as the standard sensor, and would trigger a "scanned" event in the current state if it were being scanned. A filter could be implemented (scanning object name, key, whatever) to reduce the noise and focus only on those scans you wanted.

It'd be awesome if scanning worked in a similar manner to messaging - at least in the sense that messaging uses a channel. Itd be great to isolate background scans to a certain "frequency". Sure, itd be great if there were a somewhat better system in place, but I'm trying to work with whats there.

As for griefers, that isn't my primary concern. I'm not a child, I don't behave like one, and I have ideas for tools to make the SL ideas I have easier to implement in a quality fashion.

-Ivan

How about a sensor sensor sensor to detect when your detection was detected?

LOL, yes but then of course the griefers among us just add sensor sensor sensor sensors to detect when thier detection detected your detection.....

.... I Think I will go lay down for a bit.

.. or possibly post snickering hyperbole in response to an honest suggestion that would benefit responsible builders.

As I see it:
llSensor is "Active".

llSensorSensor (or whatever you want to call it) is "Passive".

the sensor event is comparable to "touch" and even "collision", so why not extend the analogy?

An example use -

Create invisible "goggles" object that has a standard sensor in it, maybe a continous sensor, short range. Attach the object to a users head, or eyes, so that it scans in front of them. Create an object, like a robot, or a dog or a person or whatever. Add a sensor detector to it, filter for ownership or whatever criteria you desire, and you have an object that "knows" when a user is looking at it, and can turn its head in response.

Sorry for being prickly.
Ivan

hehe, if you want to tell if someone is looking at you, run a sensor and get their rotation then calculate the line of site and see if it's in your general direction.

I don't think a sense sensor event would be any worse than a collision event. but I can't see it really being necessary, and if we start stacking up events like those eventually the will be a problem.

sensor(integer n)
{
     integer i;
     vector det_pos;
     vector look_vector;
     float focus_offset;
     key in_line_of_sight = NULL_KEY;

     for (i = 0; i < n && in_line_of_sight == NULL_KEY; i += 1) {
          det_pos = llDetectedPos(i);
          look_vector = llRot2Fwd(llDetectedRot(i))

          // Uses the dot product of the look direction unit vector and the vector from the detected object to you, to calculate the closest point to you on their line of sight, and the distance from that point to you.  IE,  how close does their line of sight pass.
          focus_offset = llVecMag((look_vector * (look_vector * (llGetPos() - det_pos))) + det_pos - llGetPos());

          if (focus_offset <= 1.0)  {
               in_line_of_sight = llDetectedKey(i);
          }
     }

     if (in_line_of_sight != NULL_KEY) {
          llSay(0, "Stop looking at me, " + llKey2Name(in_line_of_sight) + "!");
     }
}

This is untested, but the principal should be sound. Just hope I didn't make any big math oopses or syntax errors

It occurs to me the previous might not be exactly what you want, as it might produce falls positives at close ranges and not register unless their mouselook crosshair is right on it at long distance.

The following gets the arc offset of their line of site, rather than the distance their line of site passes at.

// Globle Constant
float field_of_view = 0.524;     // (PI / 6.0)

sensor(integer n)
{
     integer i;
     float focus_arc_offset;
     integer in_line_of_sight = FALSE;

     for (i = 0; i < n && !in_line_of_sight; i += 1) {

          // Uses the dot product of the look direction unit vector and the normalized vector from the detected object to you, to calculate the arc between their line of site, and the line from them to you.  IE, how many radians or degrees away from you are they focusing.
          focus_arc_offset = llRot2Fwd(llDetectedRot(i)) * llVecNorm(llGetPos() - llDetectedPos(i));

          if (focus_arc_offset <= field_of_view)  {
               in_line_of_sight = TRUE;
          }
     }

     if (in_line_of_sight) {
          llSay(0, "Hey " + llKey2Name(llDetectedKey(i)) + ", I know you can see me!");
     }
}

field of view is set to PI / 6 (30 degrees) which is half the standard sl camera's field of view. This means that anything that is within the arc of PI / 6 is in the persons field of view.

So the above sensor essentially tells the closest person who can see you on thier screen (assuming there's nothing between you).

This is actually a simpler faster piece of code.

Dont worry about it .... just joking around, No offence intended.

A sense of humour isnt a requirement anyway

LeSeul

I have one - I just get defensive about my ideas. Then feel bad about it later. =)

Thanks!
Ivan