SitTarget() with rotation on X- or Y-axis = mess? :/

Simple experiment.

* create a cube. make sure its rotation in world is 0, 0, 0 so it doesn't add any extra complications. set its sit target to <0, 0, 0.001>, ZERO_ROTATION ... rotate the cube 30 degrees around X axis.
* create another cube. also make sure it's not rotated in world, set its sit target to <0, 0, 0.001>, llEuler2Rot( <30 * DEG_TO_RAD, 0, 0> )

now, when you switch sitting between both cubes, you'll easily notice while the first cube puts avatar where it's expected (i.e. merely rotates them 30 degrees) ... the other cube shifts position of avatar in a wild manner. The larger the angle of sit target rotation, the larger is that offset ... although one would expect the avatar to wind up in the same spot and at the same angle in both cases.

this odd behaviour happens also with rotation of sit target around the Y axis. Only rotation around Z axis behaves as expected, i.e. doesn't move avatar around.

Does anyone have some idea why it happens, and is there some ways to counter it? At the moment chalking it up to a bug because it doesn't make sense for such shift to appear :<

Because the formula for converting a rotation into a euler rotation is HORRIBLY complicated.

Nah that's not it really i think... i put the euler code in the rundown so it's easy to see the rotation is the same in both cases, but same thing happens if you copy directly rotation value of first cube into rotation parameter of sit target of the second cube... which skips the whole silly euler thing altogether :<

edit: i could understand the shift to appear if the sit target was set at distance from prim, middle point as that could imply that --silly as such approach would be-- the avatar is rotated first and then moved by offset value from the prim centre... but for such thing to appear when there's practically no offset from centre point is well, puzzling.

No, the way to rotate avatars on sit targets is very complicated, that is, to do it right so no matter how you rotate the object the sit target rotation computation takes that into account and properly orrients the avatar (assuming you want the prim rotated and the avatar sitting strait up, as would be useful for designing chairs) is very complicated. I had a whole thread on it and gave up trying to understand how to fix the iisue of if I rotated and object with a sit target that worked, picked up the object, re-rezzed it (on rez reset), and then sat on it, the rotations were off.
Of the couple of people who supplied code snippets to make it work right, niether code snippet worked, and I gave up trying to understand euler rotations and quadertions (ior whatever the heck they're called).

Two issues are going on here. One's a bug in the sit-target system, as far as I can tell, and one's a weirdness with avatar animations.

First the latter. The default sit avatar animation includes some offsetting... what this means is that when you're sitting with your knees bent at a 90 degree angle, your actual avatar position is approximately the length of your thigh above your knees. So let's dissect what happens in your two examples.

In the first example, your avatar sits on the cube at nearly dead-center and zero rotation, and then it appears to offset from its actual position in the negative X and Z directions as a result of the sit animation. Finally, the entire cube is rotated, bringing the avatar with it.

In the second example, your avatar sits on the cube at nearly dead-center, and it's rotated 30 degrees around the X axis. THEN it's offset due to the sit animation, which moves it some in its NEW negative X axis and some in the negative Z.

As you can see if you smack your brain with a hammer enough, those two aren't the same... it's that implied translation of the avatar during the sit animation.

So to counter this and figure out what's going on, make an animation that glues your avatar down and doesn't move the avatar at all. Stop the default sit animation and play the glue-down animation instead. In that case, then, both of your examples should put the av in the same position and rotation.

But they don't.

That's where the bug in SL comes in. I've had a really hard time nailing this one down, but it seems like sometimes, depending somehow on whether there's any rotation in the X, Y, or Z axes in the sit target, the avatar will be offset some in a couple of axes. It's never very much, and it doesn't relate in any way to how far away the sit target is from the center of the prim. Seifert Surface and I spent an hour or two trying to nail down exactly what is happening, and we failed. This means I wasn't really able to make an automated sit-target system that really would have been nice :(