Rotation problem with physics?

[Helium Loon]

I've run into a problem, and it's only half-scripting related.....

 

I've got a multi-prim object that is being rezzed by another.  After it is rezzed, I set it physical, and set buoyancy up.  Everything works fine....except it rotates to an odd angle.

 

I've tried everything to get it to rotate to a normal angle, but it seems determined to go to that angle as it's 'default' rotation.....and I've tried adjusting it from a manual rez and putting a new copy into the rezzing object, but no go.

 

Any ideas on what could be causing it, or how to fix it?

 

 

[Trevor Hinterland]

My guess is that it's rotating to the zero rotation of the root prim.  (The prim you linked to the object last).  Having to correct rotation errors with scripts can get enormously confusing especially if you do additional rotations once it's rezzed so the best way is to make sure you keep your prims (unrotated when rezzed) unless absolutely necessary.

If you don't want to unlink your object to change the root prim you can always rezz another prim (without rotating it) and link it on to the object as the last prim.  I know this solution won't work for everything, especially the more complicated structures with multiple rotations and offsets but you could try this first.

[Dora Gustafson]

It is not clear to me if you apply any rotation to the physical object.
If you are not you can try to limit how the object can rotate by using:
llSetStatus(STATUS_ROTATE_X | STATUS_ROTATE_Y | STATUS_ROTATE_Z, FALSE);
you don't have to apply it on all three axes, see the wiki

[Helium Loon]

I tried unlinking all the prims (only 6), and everything is set to the default (ZERO_ROTATION).  There aren't any rotations set beyond the ZERO_ROTATION that is passed in during the llRezObject().

 

After the physics/buoyancy are set, it rotates OFF from zero.  I can't find any explanations.  All the prims (including the root prim) in the linkset are all set to zero rotation.  I don't think the sit target is affecting it.  I've tried modifying the sit target location, and it doesn't seem to have any effect on the rotation it ends up at.

 

 

[Helium Loon]

Nope, no additional rotations.  However, I had forgotten about being able to restrict the rotations....that may be an interim fix, though I'd still like to find an answer to WHY it is happening.....

 

[Trevor Hinterland]

It's probably not this but it can happen.  Has the object that you are rezzing it from been rotated ?  If it has and you are using the rezzing object as a reference for the rotation then I believe it might be rotated relative to the rezzer.  In that case you either need to keep the rezzer at zero rotation or llget the rotation of the rezzer and pass it as the rotation parameter when rezzing the object being rezzed.

 

[Dora Gustafson]

Have you tried to make it phantom?
Bounding boxes may collide and make your object rotate.

[Rolig Loon]

 

---

Dora Gustafson wrote:

Have you tried to make it phantom?

Bounding boxes may collide and make your object rotate.

---

That would be my guess too, Dora. I have also sometimes had a newly-rezzed physical prim drop just a little bit before buoyancy catches hold. That could make an object collide when it shouldn't have.  I have tried rezzing as non-physical, sleeping for a half second or so, doing llSetBuoyancy, and then finally making the object physical.  I know that buoyancy isn't enabled in non-physical objects, but I have convinced myself that setting it first helps. 

 

[Les White]

This should work.

Where offset is the desired offset of the rezzed object from the root and angle is the desired relative rotation to the root (in degrees)

llRezAtRoot("yourObjectName",llGetPos() + (offset * llGetRot()),ZERO_VECTOR, llGetRot() * llEuler2Rot( angle * DEG_TO_RAD),0);

[Void Singer]

you can set bouyancy in advance, but what you might want to try is setting it non-physics before rez, give the region a moment to get the correct bounding structure, before going physical.... my guess is that there is a cut/sliced prim in there that would be intersecting (or nearly so) if it were not cut/sliced.