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)
- Check the viewer source is all I can say, it's likely to be a client limitation. -- Strife (talk|contribs) 09:39, 26 July 2009 (UTC)
I don't know how to do that. -- Eddy (talk|contribs) 20:19, 29 July 2009 (UTC)
Actually lolled and almost wept a little. I wonder if I'll ever know what you were looking at. I've seen references to source code around the jira and on the web and it looked like a cross between lsl and the stuff written in the dubug box. If I were to want to understand it what language should I learn? It seems that there are so many different languages all used for different things, is there a "daddy" language? -- Eddy (talk|contribs) 22:43, 31 July 2009 (UTC)
- C++, http://svn.secondlife.com <-where the source code can be found. -- Strife (talk|contribs) 10:50, 2 August 2009 (UTC)
Thanks Strife (I say that a lot but really do mean it). I actually started quivering when I came back to say thanks. When I first looked at moding my first freebie scripts I had to ask for help to change the color of some particles. I guess if I start learning C++ I'll be back to that stage again. I haven't fully understood lsl yet. I'm scared. -- Eddy (talk|contribs) 18:00, 2 August 2009 (UTC)
"C++ (read as "C Plus Plus") is a statically typed, free-form, multi-paradigm, compiled, general-purpose programming language." *slumps* -- Eddy (talk|contribs) 18:09, 2 August 2009 (UTC)
- It won't be as hard as you think. Once you have some grasp on one programing language its easier to learn another. And you are in luck, LSL and C++ have a common ancestor, C, they all have a very similar syntax. LSL could be your gateway to the entire family of C style languages (there are many). Just keep in mind that C++ and LSL both have their quirks, and they aren't going to be the same. -- Strife (talk|contribs) 11:37, 3 August 2009 (UTC)