Vector Help: Coming or Going?

I want to have a couple of sensor arrangements: one a hollow cube, and the other a flat panel. It's set to llVolumeDetect(TRUE), and I have the collision event set up. I only want it to trigger in one direction, though, and that's where I'm running into difficulty. In the case of the cube, I want it to trigger if the person is approaching the center; in the case of the panel, I want it to trigger only on one side, regardless of orientation. I've read the docs on the vector functions and operators, and tried a few things, but I'm not getting it. Could some wise soul set my feet upon the right path?

llDetectedVel() might give the script a pretty good chance of guessing whether the collider is coming from the desired direction.

You can use something *like* the following:


I say *like* because it is untested and probably wrong, but the idea is to calculate the dot product of the object's velocity vector with the direction vector to the object, and return TRUE if that value is greater than zero.

I'm very tired, and I probably got it a bit wrong, but hopefully that will prompt someone to test it and provide the correct code?


.

Here are a couple of useful functions for determining whether a detected object or avatar is in front of or is facing the sensing object.



Don't know if either of these will be helpful for you, but I'm posting them on the off chance.

.

I get a type mismatch with this. I have no clue why; it makes no sense. I even tried breaking it down:

vecMyPosition = llGetPos();
vecVelocity = llDetectedVel(0);
vecPosition = llDetectedPos(0);
vecDiff = vecMyPosition - vecPosition;
intIsApproaching = vecVelocity * vecDiff;

It gives the error on the last line.

OK, the Facing function gave me a solution for the cube sensor. I had to modify it, as the avatar's direction of movement is what I'm looking for, so it becomes:

(vecAvVelocity * (vecMyPosition - vecAvPosition)) > 0;

Which kind of actually makes sense to me, sort of, so maybe I'm starting to get some idea of how this spatial stuff works! (And which, now that I look at it, is what you first suggested; I simply omitted the boolean operation there. I still don't understand why I got a type mismatch, though, since the dot product of two vectors is an integer, isn't it?)

Now to work out the flat sensor, which I think I can get.

Technically the dot product of two vectors is a float, actually. I was using an integer variable because of the " > 0" part making that expression into a boolean.

I would have made that last line into:

         intIsApproaching = (vecVelocity * vecDiff) > 0;

Sounds like you got it working, though, yay!!!



.

Doh! I knew that. OK, I know my forehead-bashing board is around here somewhere....

OK, for the flat panel, I *think* I understand conceptually what I want to do, but implementing it hasn't gone well.

If I have a phantom prim with zero rotation, and walk through it along the Y axis, I can get the velocity and check delta-Y to see if it's positive or negative, thus indicating which side the collision occurred on. And if the prim were never rotated, that would be fine. But if it is, it seems to me I should be able to convert the rotation to a Euler and subtract it from the velocity, and that should give me velocity relative to a zero rotation. But it doesn't.

Any suggestions?

Maybe try using llRot2Left(llGetRot()) to get the vector for the local Y axis. I don't know if it'll work if you directly convert it to a euler, because a rotaion expressed as a euler is... the rotation around all 3 axes? *brain explodes* Anyway, I usually use llRot2xxx to find out which way a prim is facing. That works for me, and I haven't tried to figure out the math beyond that

I've played around with rotations a bit with my dart launcher and "Auto Targeting Box of Doom" and, for something useful, a single-prim object that can be used as Horizontal Blinds, sliding door, skylight, etc. - the blinds "shrink up" to the Top Center of the object, regardless of how it is rotated, so it can be used as a sliding door on a hole on the side of a slanted hill, even.

Divide the velocity vector by the object's rotation... that will basically rotate the velocity vector so that it's on the object's local axes. If the velocity vector went straight forward along the object's X axis, you'll have a vector that says, forward along the X axis.

Division.

I knew I was on the right track, just the wrong math. Remove the rotation from the equation, so that velocity is relative to a zero rot.

Excellent! Thank you! And thanks to everyone who provided input.

Daylight come and me wan' go home.