Very messy rotation hack - please help

I struggle with rotations
I run a small fleet of boats around the mainland continents, my current script works but I have always thought that there must be a tidier solution.

Instead of using vehicular angular motor I use llRotLookAt, called at regular intervals.
The script reads the next waypoint from a notecard and works in global cooridinates.
I have found that moving in a negative x direction (West), the boat rolls...badly..and my poor passengers are left looking for lifejackets.

My solution, found elsewhere in these forums was to clean up the rotation, but to do so I have had to convert from quaternion to eular and back again - not very tidy.

directionToPoint()
{
    vector axis = < 1.0,0.0,0.0 >;                                    //which axis to point at waypoint
    currentGlobalPos = llGetRegionCorner() + llGetPos();            //current position in global cords
    destGlobalPos =  nextWaypoint;                                  //position of next waypoint in global cords

    rotation target = llRotBetween(axis, destGlobalPos - currentGlobalPos);
    
    //Naty hack starts here
    rotation cleanedRot = target;
    vector cleanedVec = llRot2Euler(cleanedRot) * RAD_TO_DEG;
    cleanedVec.x = 0;                                               //scrub out the lazy roll
    cleanedVec.y = 0;                                               //scrub out the lazy roll
    cleanedRot = llEuler2Rot(cleanedVec * DEG_TO_RAD);
    llRotLookAt(cleanedRot, 2, 3);                                 
}


Any alternative solutions would be greatly appreciated

CODE

That looks pretty good. All I did was clean it up some and normalize the vector:

directionToPoint(){
	vector axis = < 1.0,0.0,0.0 >; //which axis to point at waypoint
	currentGlobalPos = llGetRegionCorner() + llGetPos(); //current position in global cords
	rotation target = llRotBetween(axis,  llVecNorm(nextWaypoint - currentGlobalPos));
	vector cleanedVec = llRot2Euler(target) * RAD_TO_DEG;
	cleanedRot = llEuler2Rot(< 0, 0, cleanedVec.z> * DEG_TO_RAD);
	llRotLookAt(cleanedRot, 2, 3);
}

Works better this way and you do not need to switch between rot and euler:

directionToPoint(){
	vector axis = < 1.0,0.0,0.0 >; //which axis to point at waypoint
	currentGlobalPos = llGetRegionCorner() + llGetPos(); //current position in global cords
	currentGlobalPos.z = nextWaypoint.z; //cancels elevation change
	rotation target = llRotBetween(axis,  llVecNorm(nextWaypoint - currentGlobalPos));
	llRotLookAt(target, 2, 3);
}

Yeah, you have to do something like that, because llRotBetween does not provide a complete description of the rotation between two vectors. More or less, it provides a rotation correction to move the axis, but the angle is not preserved the way you would think.

Basically, imagine you have a rotisserie chicken on a spit (Mmmm...). The vector represents the way the chicken is pointing via the spit. You can then "point" the chicken wherever you want, but you can't "spin" the spit (because the rotation of the spit in either the starting or the end position is not encoded into the vector, so the rotation calculation just makes an assumption about it being essentially "locked". The chicken could start right-side up, but end up upside-down after the rotation is applied, since llRotBetween doesn't have a clue about how to "spin" the spit.

Dang, now i'm hungry for BBQ

Thank you Jesse that works perfectly - a very concise solution.

Thank you Talarus for explaining why its needed - the chicken on a spit is a wonderful analogy - made it very clear.

Now if anyone can provide a hint as to how I can raise the bow at speed, without doing the nautical equivalent of a "loop the loop" ............................

This should also work:

// If you wanted to use a different axis for "forward", make this a
//    rotation that will point that axis to the  East (along the global
//    x-axis) and also orient the object so "up" is up.
rotation STARING_ROT = ZERO_ROTATION;

currentGlobalPos = llGetRegionCorner() + llGetPos(); //current position in global cords
vector dir = nextWaypoint - currentGlobalPos;
float phi = llAtan2(dir.y, dir.x);
rotation targetRot = STARING_ROT*llAxisAngle2Rot(< 0.0, 0.0, 1.0 >, phi);

How the heck are you using llRotToTarget? It's got F32's for variables, and I can't fricken set F32 as a variable type >_<

Which function is throwing an error?
llRotTarget or llRotLookAt? Also please keep it in one thread so we do not have to bounce around trying to figure out what you are refering to.

For llRotLookAt the strength & damping values should both be between 0.0 & 1.0

"For non-physical objects, good strength values are around half the mass of the object and good damping values are less than 1/10th of the strength. For physical objects, this function behaves more like llMoveToTarget, where increasing the strength or tau seems to slow the rotation. Good values for physical objects range between .2 and 1 for both parameters. Asymmetrical shapes require smaller damping."

For llRotTarget the error is in radians and is easier to enter as one of these values:

PI
TWO_PI
PI_BY_TWO
degValue * DEG_TO_RAD

Caveat:

"Note: to make scripts run faster, instead of using the DEG_TO_RAD command to convert angles, use the following, PI = 180 degrees, PI_BY_TWO = 90 degrees, TWO_PI = 360 degrees, other useful angles PI/4 = 45 degrees, 3*PI = 270 degrees, PI/3 = 60 degrees, PI/6 = 30 degrees."

Finally found the chart I was looking for. This is from a mirror of the original wiki and is not included anymore:

http://www.cheesefactory.us/lslwm/radian.htm

Yeah... I've been scripting for too long, getting the function name for llMoveToTarget and llRotLookAt mixed up. It was meant as llRotLookAt, but it was answered in another thread. Was just SL pointing to the wrong thing.