Difference between revisions of "Talk:LlGetLocalRot"
m |
Void Singer (talk | contribs) m |
||
| Line 8: | Line 8: | ||
: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. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 18:15, 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. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 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.<br/>-- '''[[User:Void_Singer|Void]]''' <sup><small>([[User_talk:Void_Singer|talk]]|[[Special:Contributions/Void_Singer|contribs]])</small></sup> 22:09, 14 May 2012 (PDT) | |||
Revision as of 21:09, 14 May 2012
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)