Talk:LlTargetOmega
Moved from the article
Note: Currently llTargetOmega is not performing properly, especially when involved in an avatar attachment. Several "work arounds" have been published, none of which provide consistent results. Severl JIRA reports have been filed over periods of several months. Linden Lab has reported looking into the issue, but thus far the problem remains. llTargetOmega cannot currently be relied upon to rotate avatar attachments properly, and exhibits inconsistent results on non-attached objects.
- The comment provides no actionable information and lacks citation; it does not belong in the article. A full description with workarounds should be posted into the Notes section (with a possible refrence to the notes section from the func_footnote) and the jiras you refer to should be added to the bugs table in the article. -- Strife Onizuka 05:36, 25 February 2008 (PST)
Scripts and Manual editing via UI
I was playing about with the root rotation of a 2 prim object the child of which had a target omega set. While actually editing the rotation (by grabbing the colored rings) the child was wobbling all over to try to set the correct rot. As soon as the ring was released the child stopped updating and set its target omega to whatever it decided it should be (bearing in mind the mine field that is rotation). I'm not sure if anyone cares that much but I thought I should comment on my findings. I wonder (but am a bit too busy to test) if editing root rot via a script also messes with the target of a child etc.? *shrugs* -- Eddy (talk|contribs) 01:46, 20 July 2009 (UTC)
It seems that attached rotation has a speed limit.
It doesn't make any difference to the attached speed of rotation if I increase the rotation speed of a child and then attach the object even after the increase is observed when not attached. Thus I conclude that attached children have a speed limit. What's the word on the street? -- Eddy (talk|contribs) 00:17, 23 July 2009 (UTC)