rotating a tube that's on end

I have a script I'm going to put in public domain that includes the Lex's sit target code and stays in the object after you've set the sit target. It allows changing anim on shift-arrow.

Now I want to add changing direction on arrow key (rotating the whole seat) as an option.

On a cube, it works fine if the cube is oriented normally. But if the cube is rotated 90 degrees so that a different axis is vertical, rotating on a different axis doesn't have the result I expect.

I'm using this code to adjust the object rotation:

adjust(float amt)
{
    rotation rot = llGetRot();
    vector euler = llRot2Euler(rot);
    string axis = llGetObjectDesc();
    if (axis == "x") {    
        euler.x += amt;
    } else if (axis == "y") {
        euler.y += amt;
    } else if (axis == "z") {
        euler.z += amt;
    }   
    llSetRot(llEuler2Rot(euler));
}

How come it only works when the axis is z?

Thanks!

Hmmm.
I'd guess that the value of 'axis' is neither x, y, nor z, so the last choice is used by the IF statement.
When you open the cube's properties, there are two fields, the name and the description.
You're querying the description. I'd also guess that description has to be exact...that is, equal to 'x', lower case, with no extra spaces before or after.

Now why would I do a silly thing like that? Of course I have the axis set to the text my script expects. And I can set it to x, y, or z and get different behavior. When the object is oriented normally, I get exactly what I expect.

This script is for anyone to stick in any object -- surely results will vary. If the description doesn't match the script doesn't take controls for rotate left & right keys. When I get it working I'll probably change it to find strings like "axis=x" anywhere in the description.

I'm testing with objects exactly aligned on one of the 3 major axes and it doesn't give the results I expect, so the problem is not an unaligned axis.

I notice that when rotating on one of the axes, odd things happen as the object approaches and crosses zero rotation: as it hits center, continuing to click on the same key causes it to toggle back and forth between zero rotation and one "click" of rotation, and I have to use the opposite key to keep going (after which the keys are backwards until I approach zero and flip again). I presume this is related to converting between euler and quaternion.

Is this the well known "rotation bug"? I've heard that mentioned but don't know the details. Or am I just grossly oversimplifying what Euler representations mean?

I would do the rotations in quaternions.

This will always rotate around the global z axis even if x and y do not have 0 rotaion.

sayRotation () {
    vector vr = llRot2Euler (llGetRot());
    vector vrd = vr * RAD_TO_DEG;
    llOwnerSay ((string) vrd);
}



adjust(float amt)
{
   rotation rot = llGetRot();
   rotation r = llEuler2Rot(<0,0,amt * DEG_TO_RAD>);
   llSetRot(rot * r);
}



default
{
    state_entry()
    {
        llSay(0, "Hello, Avatar!");
    }

    touch_start(integer total_number)
    {
        llSay(0, "Touched.");
        adjust (5);
        sayRotation ();
    }
}
CODE

Thanks Ed! Can't wait to try it!
hmmm, multiplying a rotation to rotate ... /me scratches head, wishes he'd paid more attention in math classes ...

You're my hero Ed. Thanks!