llSitTarget: WTF?

Here's the code:

        vector rot = llRot2Euler(llGetRot());
        rot /= DEG_TO_RAD;
        rot += <90,90,0>;
        rot *= DEG_TO_RAD;
        rotation ROT = llEuler2Rot(rot);
        llSitTarget(<0,-0.15,-.25>,ROT);

That worked for a chair. I copied that code into a chair that was the same prim, but had a more complex script in it.
The rotation was off. So I started from <0,0,0> on line 3 and worked until I had what I needed.

        vector rot = llRot2Euler(llGetRot());
        rot /= DEG_TO_RAD;
        rot += <0,0,-90>;
        rot *= DEG_TO_RAD;
        rotation ROT = llEuler2Rot(rot);
        llSitTarget(<0,-0.15,-.25>,ROT);

Then I picked up the chair (replacing the broken one) and re-rezzed it.
The rotation was off. I fixed it again, starting with <0,0,0>
I got <180,0,90>
WTF!?

Did some testing. The code works for an object until you rotate it and re-rez the new rotation (meaning that rotating it has no effect unless you pick it up and re-rez).
Why? What am I doing wrong?

I'm not sure what's going on here, but I'm not following what you're trying to do with the rotation math there. Adding Euler rotations MIGHT work, but it's not the best way to combine two rotations. Also, I would suggest multiplying by RAD_TO_DEG rather than dividing by DEG_TO_RAD. That's exactly the same thing, but multiplying by RAD_TO_DEG makes it a lot more clear what you're doing.

Here's how you'd add on a rotation to the existing rotation:

        vector rot = llRot2Euler(llGetRot());
        rot *= llEuler2Rot(DEG_TO_RAD * <90,90,0>);
        llSitTarget(<0,-0.15,-.25>,rot);

With that out of the way, it's early in my morning, and I'm not exactly following what you're saying is going wrong. If this doesn't fix it, maybe someone else can come and take a shot at this.

The LSL docs aren't very helpful in trying to create sit targets on rotated prims (i.e. completely and utterly lacking).
I'll try that and see if it works.

Well, it's a wiki. So I hope that when you find a working solution to this little problem, you'll be sure to add your method to the wiki.

I'll be sure to do that. I'm just saying that it hasn't already been done and llSitTarget rotation problems aren't new. There's a solution for teleports, why not chairs?

People have done it before, it's just that once you get a basic grasp on quaternion mathematics, it's obvious. Most publicly available poseball scripts have this feature already. The vast majority either use another users script or know a bit of quaternion math.

I would say that if converting quaternions to degrees, adding something to the amount in degrees, and then converting back to quaternions doesn't work then surely there's something wrong with the quaternion conversion functions (eg, they are making bad assumptions somewhere?)

Thats not how Eulers work. You cannot just add rotation to one gimble without it effecting the others. Eulers work by first applying the X rotation, then the Y, then the Z. If you change either the X or Y, it will effect the result of the later rotations (set an object to <20,0,0> and hold down the Z rotation down button, see how it rotates; now set the object rotation to <0,0,20> and hold down the X rotation down button, and see how it rotates differently). This is one of the reasons why Eulers suck.

Quaternion combining doesn't have this problem. Sure Quaternions are difficult to master, but it's worth it.

I finally got around to using this code, and it isn't working. Or at least, I don't know how to replace the <0,90,90> in such a way as to get a good rotation. I tried various combinations, but because a single 90 rotated in two directions at once I can't figure out what to do to rotate aroudn the Z axis 90 degrees clockwise (looking down).
As for Quaternions, I've not only never heard of them, I can't figure out how to use them. *Looks at Wiki* Ok, I left cosines and stuff behind a long time ago (last used them in calculous, and there real numbers were shoved through it). I can't follow what the h*** a Quaternon is.

Don't try to imagine them, they represent a point on a 4-dimensional sphere.

Which Z axis do you want to rotate it around? The objects Z axis or the global Z axis? (before you ask, yes it does matter, you probably want local axis).

This code will rotate around the global axis.

   rotation rot = llEuler2Rot(DEG_TO_RAD * <90,90,0>) * llGetRot();
 llSitTarget(<0,-0.15,-.25>,rot);
   

This code will rotate around the local axis

   rotation rot = llGetRot() * llEuler2Rot(DEG_TO_RAD * <90,90,0>);
 llSitTarget(<0,-0.15,-.25>,rot);
   

Global (I refer to axis as global unless I say otherwise ("The object's X axis". I'll steal those lines and use 'em when the grid comes back online.

oh btw, i mixed up the two scripts, i can never remember which order of operations does what.

oh btw, i mixed up the two scripts, i can never remember which order of operations does what.

Yes, I know about the gimble lock problem. But what I mean is that no-one forced LL to use just a bare Euler rotation as the only thing to which quaternions can be converted in order to manipulate them in a way that makes sense. For example, they could have instead used llRot2EulerSequence(rotation rot) which returns an ordered list of Euler rotations that exactly reproduce the quaternion when applied. Making bare Euler rotation the only option when they know that doing so removes information required to reproduce the quaternion just seems awkward!

I've tried looking around for help files on quaternions but they all basically come down at some point to "this is how they work, this is the problem they solve, but we will not mention why they were designed that way or how they solve the problem, just trust us that they do" and I like to know that kind of thing None of them will let me learn to look at a quaternion and work out what rotation it represents..