Why is Sensor So Whacked?

these just do NOT work for me.

last time, i tried to make a marshmallow sense any SCRIPTED object and search the name for the word 'fire.' i had goofy results with that, total failures to find fires anywhere. all kinds of crap.


so the other day, i made a lance, and i wanted to see if it hit someone. i know the armor stall lance can 'sense' when it hit someone or something. (i dont know exactly how, of course.)

so i put a sphere on the tip of my lance that was .5 meters in diameter. at least, i would EXPECT that if i put a range of .5 (or .25, really) on my sesor, that this sized sphere would accurately represent the size of the sensor range. ha ha. right.

and i pointed the sphere forward, because it says it uses the front end of the prim to calculate the arc. not that i used an arc of less than pi (all around), becuase my marshmallows couldn't find a fire in front of me half the time and found it BEHIND me the other half of the time.

so im wearing this lance, and i point it at my friend's head. my friend's head is in the sensor sphere. do i get any senses? noooooo. (yes, im using llsensorrepeat and looking for AVATARs.)

but then guess what! i turn aroud 180 degrees, until the sensor is about 5 meters or so away from my friend, behind me... lo and behold it starts sensing! i swing it back towards her, it stops. i turn away, it starts again.

so now i walk away until it stops. i then back up towards my friend until i get where it was sensing her before. does it sense? of course not!


can ANYBODY explain sensors so they make freekin sense???? argh!

First thing to mention... for the lance thing, use volume detect rather than sensors. Chances are (if you coded it right) it *did* detect the right thing... it was just slow to respond. A sensor is only good for periodic checks, because it's slow, inaccurate (time-wise), and can cause a LOT of lag if used too much. (EDIT: just re-read your post... a sensor wouldn't actually work at all for your lance, because sensors only detect position, not volume, and an avatar's position is defined at its feet, not its head).

There are lots of other issues that can affect sensors though. I've never had any problems with the purposes I've used them for anyway, such as tracking general avatar movements across a sim, or shutting-down a device when nobody is in range to use it.

Feel free to post a bit of code though, and we can take a look.

I didn't test this, but I think sensors in attachments will act as though they are located at the avatar's center (pelvis), and will also sense other avatars' position to be their centers. Sensors are also oblivious to animations.

I think that's why most swords use a 2-3 meters sensor with a narrow cone.

You are correct. They point in the direction that the avatar is facing, too. The actual attachment, how it's shaped, where it is attached and so on is irrelevant to the operation of the sensor.

Further than that I can't say what the problem is here without being able to see the script, really.

I'd use something on the lines of

default
{
    state_entry()
    {
        llVolumeDetect(TRUE);
    }

    collision_start(integer number_detected)
    {
        string target = llKey2Name(llDetectedKey(0));
        string position = (string) llDetectedPos(0);
        llSay(0, "I have just hit "+ target + " at "+ position);
    }
}

as a basis, but I am not sure if this is what you have in mind.

Since animations of an AV is client side an attached object with a sensor would have know idea which way it is facing in-world which is why everything is based off the AVs root position and rotation. Remember what one person may see is not what someone else might see when it come to an animation.