Please llRotLookAt me

[Rolig Loon]

Every time I think I have llRotLookAt figured out, it turns out that I don't.  All I want to do is point a physical object's local +Y axis at a detected agent.  It seems to me that I ought to be able to do it with

llRotLookAt(llRotBetween(<0.0,1.0,0.0>, llVecNorm(llDetectedPos(0)),1.0,0.4);

in a sensor event, but the object doesn't rotate at all.  Have I messed up llRotLookAt again, or should I be looking at something else? 

[Innula Zenovka]

Try

 

 llRotLookAt(llRotBetween(<0.0,1.0,0.0>, llVecNorm(llDetectedPos(0)-llGetPos())),1.0,0.4);

 

or, if you want to constrain the rotation to one axis, try something like

 

      vector detected = llDetectedPos(0);      vector pos = llGetPos();      llRotLookAt(llRotBetween(<0.0,1.0,0.0>, llVecNorm(<detected.x,detected.y,pos.z>-pos)),1.0,0.4);

 

As is so often the case with rotations, I don't really understand why I need to use llVecNorm(target_pos - my_pos) there other than that's the way it works, but I'm hoping someone can explain why that's the right thing to do.

[Void Singer]

llRotBetween returns a scaled rotation, so if one term is a unit vector, it works out better if both are, hence the use of llVecNorm (ETA: it's not technically required, it should work without it, but it's a safety measure, and some people have reported oddities w/o it)

the  reason for (targetPos - myPos) is so that the rotation returned is relative to you, rather than the region corner (the point at the center of the two point given is assumed to be zero)

the order matters for applying it to get a result too. llRotBetween is (from, to), so reversing the terms reverses the direction traveled

[Innula Zenovka]

Thanks.  I hadn't realised that the reason  I subtract my position from my target's postion is to make the rotation relative to me rather than the region corner, but now it all makes sense.    

[Rolig Loon]

Ah... of course.  I forgot that I was dealing with a relative position.  I knew it was something simple.  Thanks, Innula.