Rotation problem - get attachment to point properly

I have a prim that orients toward my camera vector when I click on it, which works perfectly, using this code:

llSetPrimitiveParams([PRIM_ROTATION, llRotBetween(<0.0, 0.0, 1.0>, llGetCameraPos() - llGetPos())]);

However, when I attach the prim, this code no longer works properly and the prim rotates at odd angles.

I've spent 2 days reading through rotations on the wiki, talking to people in the scripters group, and playing with rotation functions and I've gotten absolutely nowhere.

What do I need to do to make this work properly, and can someone explain *why* the proper code makes it work properly?

it's adding the proper rotation, but applying it to the Av's reference rotation....

what you need to do is get the global rotation of the av, subtract out the av's local rotation, and then apply your rotation

details here:
http://wiki.secondlife.com/wiki/LlSetRot

Uh... at least so far, I've not had much luck following instructions.

Maybe there's some shortcut I'm missing (for example, I'm not sure what "the av's local rotation" is ), but I think it's considerably more complicated.

First, there are limits (oft mentioned here) to the precision of this whole endeavor. These have to do with the relationship between the avatar as animated and the agent in the sim. The script runs on the sim, so has no way of knowing what the animation has done to the agent. This causes (among other problems) the inability to know the global position of an attachment point as seen (as animated) on the viewer. (See for the last time this came up here.) I guess for a specific, static pose, one could measure this manually with a couple of prims in the editor.

Attachments can also be offset from their attachment points in the editor, and those offsets can matter for proper orientation to close-in camera positions in this application.

Attachment points also have reference rotations (maybe this is the "av's local rotation" ); an unrotated prim will be oriented very differently on the spine, for example, than on the stomach, and the rotation set in a script is applied to that rotation as well as the avatar's global rotation. I don't know where these rotations are to be found in a table (nor returned from a script), but maybe I've just overlooked it. Again, for a specific attachment point, one can find this manually in the editor.

(Incidentally, one thing that makes the cited llSetRot() wiki passage difficult to understand is that it's trying to concisely explain the mess that is ... which is sorta orthogonal to the complexities of attachment rotations, I think.)

So, if there's an easy way to do this, I'd be pretty happy to know about it--so far, my attempts at doing it "the hard way" that I think I understand haven't been very successful.

=)
thanks Qie, I've not actually played with this aspect yet....

my understanding or the issue:
the attachment would need to get it's global(sim) rotation, and then correct for that in the "point to"... but avatar(or even specific attachment point) rotation is inaccessible... and the av's rotation always returns ZERO_VECTOR (because it isn't stored by the server
do I have that right?

I've seen a "balancing act" done by the creator of MechMind Virtual Keyboard, in which it rebalances the keyboard (a cylinder) based on the attachment point (usually a body spot) but that balances to the avatars z-axis and not the sim z-axis....

any possibility of working around this by having the attacment rez either the pointer (making it immune, but ultimately unconnected ), or a reference object (to get the rotational difference) ?? or is it even possible to compare the rotation with the av always returning ZERO_VECTOR?

the further complication seem to be that the rezzed pointer/object wouldn't be able to get the attachments global position, because it returns the av position, and even with a table of offsets for varios attachment points STILL wouldn't account for any animation of the av, excecpt maybe a zero offset pelvis attachment (I think that's the center for av position), so it'd HAVE to be independant... and broken on no-build land

oye that is a mess

PS sry Geuis, didn't realize the whole of the issue

if you can tolerate not crossing sim boundries well, how bout putting a follower in it instead of attaching it?

How about if your pointer rezzes a follower prim (invisible/phantom) to move to the camera pos, and then the attachment (now a sphere) points at it with tapering particles?