Silly rot issue

I can't believe I've never encountered this, but I just haven't played with rotation much.

I cannot get a prim to rez another prim at a specified rotation value. (Not an attachment, just a rezzed prim). Both are sculpties. I've tried a few things, but I'm probably missing a normalization step.

It seems to me that
llRezObject("Object B", < position >, < 0.0, 0.0, 0.0 > ), llEuler2Rot( < rotation values from build menu > ), 0);

should work, but it rezzes the object at the right position, and a repeatable but wrong rotation.

Now, the object to be rezzed from inventory has a zero rotation, BUT the object containing the script is at a non-zero rotation, so I attempted to normalize for that by setting the llRezObject rotation to the difference between llGetRot() and the desired end value, but it didn't work either. I tried a few other things ... explicit conversions to quaternions before calculating the difference, etc.... nogo.

Do I need to be very careful about local vs. global coordinates, or something like that?

Try llRezAtRoot?

try

llRezObject("Object B", < position >, < 0.0, 0.0, 0.0 > ), llEuler2Rot( < rotation values from build menu > )*llGetRot(), 0); 

It rezzes objects using a global rotation, so if your avatar is facing a different direction, it will still be the same rotation globally, but won't be the same facing towards the avatar.

If that's not the issue, I think some more details about the problem may be necessary.

Neither object is an attachment. The object containing the script is already rezzed, and is attempting to rez the 2nd object on touch. The 2nd object rezzes correctly, except that its rotation is wrong.

I'm taking the target rotation off the build menu rotation numbers ... hmmm ... Talaras, should I check to be sure that the build menu is in "world coordinates" instead of local?

I'll also try your code, Innula, and look at llRezatRoot. Thanks much for the ideas, so far!
.

Oops. I read that and still thought "attachment". <.< Must have attachments on the brain today.



They should be the same for a whole object. The rotation for the object is the same as the rotation of the root prim, script-wise. However, I am not so sure that is true for the build editor values. What I would recommend is putting a script in your object and get the scripted rot values directly:

default {
    touch_start(integer piDetectedCount) {
        llOwnerSay((string)(llRot2Euler(llGetRootRotation())*RAD_TO_DEG));
    }
}

Then set the object's rotation and touch it to get the value. Use those values instead of what the viewer tells you.

PS: Just had a thought.. are you converting the values in the HUD to/from radians?

YOU WIN THE CAR!!!

A little multiply by DEG_TO_RAD fixed it! Thank you!

----

Other details: The location numbers I got from reading rotation via script were the same as in the build menu (+-360), which is reassuring.

The multiply by llGetRot() was not necessary.

Didn't need llRezAtRoot, each being a single prim ... but good to realize the distinction for later projects.

Thanks, all!

Hehe. I do that a lot myself. Usually, I catch it before compile time, but once in a while, it sneaks through my eyeball check and I scratch my head for a bit before the magic "duh" moment hits.



Aye, though, actually, the rotations are always "normalized" to +-180 with llEuler2Rot(). If you use 180-360, it will often re-normalize the values to +-180, which sometimes flips the other coordinate axes, too. That, or it will flip the rotation itself by 180 degrees on one axis.