Talk:LlGetLocalRot

Shouldn't the "if the script isn't physical" remark be removed? Because first of all, a script cannot be physical, and secondly, this function does work normally when the object or prim is physical. So unless there is a good explanation for the remark, it should be changed to something meaningful or otherwise removed? Pentasis Adamczyk 22:41, 28 May 2010 (UTC)

Sounds like a hold over from the original documentation (we used it as a boot strap but it contained errors). I'll remove it. -- Strife ^{(talk|contribs)} 05:52, 29 May 2010 (UTC)

Doors

Is there actually a script that still works if you turn the parent object around? I've got the case right now where I'll turn the object 90°, and the door then spins clockwise instead of sideways (different axis). I've tried different scripts now and they all have similar issues. I want to make it easy for my users in case they turn their furniture with doors. Since I don't really understand rotations, I don't want to have to write a script which detects which way an object is facing and then adjusts the axis accordingly - there has to be an easier way! Eleonore Chevalier 12:10, 13 May 2012 (PDT)

Yes but it's hard to do right. Especially if you don't want to configure each script manually. Rotation drift (an unavoidable limitation) is something you really have to combat with doors, as they will be opened and closed a lot. Drift that amounts to a 100th of a degree per iteration pretty soon is visible. -- Strife ^{(talk|contribs)} 18:15, 13 May 2012 (PDT)

The script on the main page of this article will track properly, relative to the parent, regardless or which way the parent object is rotated. Since it operates in the local frame, with mirrored rotations, drift should not be apparent even after several hundred uses. If it is (because of the parent also frequently changing rotations) it can be edited back into position without resetting the script and will function correctly. similar scripts using an offset for the center coupled with a move in position should have the same protections.
-- Void ^{(talk|contribs)} 22:09, 14 May 2012 (PDT)

It does. The only thing my other scripts didn't have are the ZERO_ROTATION / gRotDoorSwing part. Could you explain that to me mathematically? Eleonore Chevalier 11:08, 15 May 2012 (PDT)

(gRotDoorSwing = ZERO_ROTATION / gRotDoorSwing) inverts the rotation used to rotate the door and saves that value back to the rotation. The script works like this: You click the object, the script rotates the prim local to it's current rotation a certain amount. When you click the script again, it takes the prim's current rotation and applies the inverses rotation of what it applied before (in theory) returning it to where it started (ymmv). By literally inverting the offset each time, you avoid having to have an if statement and a global variable to keep track of if the door is open. It's a clever solution. -- Strife ^{(talk|contribs)} 21:06, 15 May 2012 (PDT)

mathematically zero-rot / rot == <-rot.x, -rot.y, -rot.z, rot.s> (ie. change the signs of the x/y/z elements), at least it should be (I have no idea how it's implemented internally). Another equivalent operation is flipping the sign of the .s element. Visually, if you take a ball and put two dots anywhere on it, label them A and B, the angle between them and the direction from A to B is your rotation, and that mathematically is like swapping A and B (giving you the same angle but opposite direction). Even if the example is not the literal case, any drift will quickly quickly damp to zero (constrained to +/-1 at the 6th decimal place in 32bit floats) negating accumulation of errors long before it's visibly apparent at scale.
-- Void ^{(talk|contribs)} 16:16, 20 May 2012 (PDT)