I'm pulling my hair out here. I just want one axis of rotation.

Ok, I am pulling my hair out trying to isolate the avatar's rotation around the X axis... Seems that I can't JUST get that axis. I don't know why, and I've been trying to figure it out. Maybe I have gotten the rotation before and applied it wrong, I am not quite sure.

But it should be a simple thing... I want to access the rotation like you do on a prim, as X, Y, and Z axis. I know how to use RAD_TO_DEG to get the rotation to a degree format, but it seems like all rotation are affecting each other, so isolating them is next to impossible.

Anyhow... I just want the avatar's X rotation, so I can apply it to a prim. It seems straight forward, but I can't for some reason manage it in SL.

When you use euler rotations the order matters, so don't do that
Use 'rotations' instead.
Look at this tiny script, it may help you along:

default
{
    touch_end(integer n)
    {
        llSetRot( llDetectedRot(0));
    }
}

it will rotate the containing prim just like the avatar that click it.
Happy scripting

That really doesn't help at all, because that still doesn't eliminate the the Y and Z components of the rotation. I don't need the prim turning side to side, only going up and down.

What if you told us about what you are doing? I am pretty sure someone in here has a better solution than what you can do with a rotation around the X axis
Besides: an avatar is never rotated around the X axis if not in mouselook or part of a linkset

Well, maybe I have the wrong axis... The verticle. I'm bad with rotations in here... I'd just rather see the matrices...

Anyways, here's the deal, I need to apply the avatar's verticle rotation to a prim... so that the cannons on a ship will rotate up and down. Kind of how a tank's cannon swivels up and down while the turret itself swivels side to side? It's not just one piece that turns.

OK.... Let's try getting directions straight. On a freshly-rezzed prim, or one that you have set ZERO_ROTATION on, the X and Y axes are perpendicular to each other in a horizontal plane and are aligned with the global axes. The X axis is marked red, the Y is green. The vertical axis, the blue one, is the Z-axis. Normally, when someone talks about "verticle [sic] rotation," they mean rotation around the Z-axis, the way an ice skater spins on the ice. The cannons on a ship might swivel around the Z-axis too, as you're trying to aim them at different targets around you. When you talk about them swiveling "up and down," though, that's not around the Z-axis. It's around some axis in the horizontal plane -- the X-axis or the Y-axis if you plan ahead. SO, what are you asking? Do you want to know how to make a canon turn like an ice skater so you can aim it, or do you want to know how to make it go up and down?

In NORMAL axis, X is around your field of view, Y is up and down, and Z is side to side. When it comes to SL, that doesn't always seem to be the case when you say sit on something, or deal with a prim that is attached to another prim, or to the avatar... It causes me MUCH confusion.

It SHOULD be the Y axis, in your description.

Second Life convention:

x points forward
y points to the left
z points up

Make a thumbs-up/hitch-hiking sign with your right hand and point your thumb in one of those directions. The direction your fingers curl will tell you what a (positive) rotation about that axis will do.

We're getting closer, anyway. "Up and down," the way you're describing it, could be X or Y or any other axis in the horizontal plane. At least now we know it's not Z. It sounds like you're getting three frames of reference mixed up. A prim has three orthogonal axes, always shown as red, green, and blue. The world has its own axes (east/west, north/south, and vertical). And you've added a third frame that has nothing to do with an object, but concerns our camera angle. That frame also has a vertical axis, an axis in the plane of the screen itself, and an axis perpendicular to the screen.

Forget the camera system. That's just going to mess with your head. If you want to rotate around the object's Y axis, first you need to know which direction it's pointing relative to the global axes. llGetRot() will give you that information as a quaternion. To rotate the object around the global Y axis alone, you need to create a rotation vector with zero change in X and Z, convert it to a quaternion, and multiply that by the result of llGetRot(), like so .....

integer y; // This is the angle in degrees that you want to rotate by
rotation yrot = llEuler2Rot(< 0,y*DEG_TO_RAD,0>);
rotation newrot = llGetRot() * yrot;
llSetRot(newrot);

If you want to rotate around the object's own Y-axis instead of the global (north/south) axis, then you use llGetLocalRot() instead....

If you're still confused, do a close reading of . All this and more is spelled out there.

I got the part about rotating about the Y (which for this prim is actually the X it turns out because of how it is facing on the prim), but what i need to do is to get the Y variable out of the avatar's rotation (which IS the same as the camera in mouselook), to knwo how far to rotate by.

Ah... I see why you were getting "the avatar" into it. You really do care about the camera angle. So try using llGetCameraRot(). The problem now is that your camera is not centered on the object, so you'll have to correct for the camera's offset as well as its rotation. This is where I start to get a headache. Given the time of day and the nasty heat, I'm going to step aside and let a wiser and cooler head take it from here.

Yeah... this is where my headache came from. I've tried every way under the sun, even some I figured would fail, just to see if it worked. I still have nothing >_<

OK... I haven't headed out the door yet, but almost. Still thinking ...... It may be easier than I thought before. Try this....

integer y; // This is the angle in degrees that you want to rotate by
rotation yrot = llEuler2Rot(< 0,y*DEG_TO_RAD,0>);
rotation newrot = llGetCameraRot() * yrot;
llSetRot(newrot);

Time to go home. ::Keeps fingers crossed::

Sometimes it's better to try not thinking about it too hard. Throw away all of the math and pick an axis, any axis and throw a number at it, maybe 45 degrees or so and see what happens. If there is no change then pick a different axis. A couple of minutes and you will know which axis to use and have a rough idea about how much you need to move...............

He wants to change the elevation without changing the azimuth.

Assi-what?

No, I need to Get, not Set... is the problem. Setting is easy, getting is hard. For some reason when you get a rotation, one axis will change if you rotate in the other axis... I don't know why. It seems like it would be straight forward to get the axis, but it's been multiplied or something...

Again GET, not SET is my problem here...

I have the cannon rotating correctly to a point, but it goes wonky when I turn the ship, or I turn the camera (without turning the ship) it's just so screwy...

This may not be the answer you are looking for, but play with this script for a while. It may give you an idea or two. Stick it in a prim and click on it as you change your camera angle. Try looking due east, due north, etc. and then mess with azimuths in between....

default
{
    state_entry()
    {
        llRequestPermissions(llGetOwner(),PERMISSION_TRACK_CAMERA);
    }

    touch_start(integer total_number)
    {
        integer perm = llGetPermissions();
        if (perm & PERMISSION_TRACK_CAMERA)
        {
        rotation camrot = llGetCameraRot();
        vector camvec = llRot2Euler(camrot) * RAD_TO_DEG;
        llSay(0, "Camera rotation is " + (string)camvec);
    }
    }
    run_time_permissions (integer perm)
    {
        if (perm & PERMISSION_TRACK_CAMERA)
        {
        rotation camrot = llGetCameraRot();
        vector camvec = llRot2Euler(camrot) * RAD_TO_DEG;
        llSay(0, "Camera rotation is " + (string)camvec);
        }
    }
}

Ok, this is what I have right now as far as getting and setting. It works in some rotations, but not others... like the X and the Y keep switching places as I rotate.

float getFacing(rotation rot)
{
    vector fwd = llRot2Up(rot);
    return llAtan2(fwd.y, fwd.x);
}

rotation rot = (llList2Rot(llGetObjectDetails(RECORD, [OBJECT_ROT]), 0)) / llGetRootRotation();
            float Y = (getFacing(rot) * RAD_TO_DEG);
            vector ROT = < Y, 0.0, 0.0>;
            llOwnerSay((string)ROT);
            if(ROT.x > MAX_ROT)
                ROT.x = MAX_ROT;
            else if(ROT.x < MIN_ROT)
                ROT.x = MIN_ROT;
            rotation TURRET_ROT = llEuler2Rot(ROT * DEG_TO_RAD);
            llSetLocalRot(OFFSET_ROT * (TURRET_ROT));

In the main vehicles script I also have this, as I think this may be important after some experimentation.

llSitTarget(< 0.0, - 0.5, - 1.7>, llEuler2Rot(< 90.0, 0.0, - 90.0> * DEG_TO_RAD));

llSetVehicleRotationParam(VEHICLE_REFERENCE_FRAME, llEuler2Rot(< 90.0, 0.0, - 90.0> * DEG_TO_RAD));