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.

---

Eren Padar

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)

I'm not seeing any in the client source... -- Strife ^{(talk|contribs)} 14:12, 31 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)

Although I am not truly afraid I had the same feeling looking at that first line that I had when I first started to try to write scripts. A dark empty space opening up in my head that needed to be filled. Jaw dropping "uh?". But I am going to enthusiastically get stuck in soon. I need to get some more lsl under my belt first. I would like though to take this opportunity to say how good it feels to have your support and rather (it seems) warm pat on the back of encouragement. Thanx Strife. It means a lot to me (I spend a lot of time alone and it's good to ... well you know. Thanx). C language family "Here I come" -- Eddy ^{(talk|contribs)} 12:33, 3 August 2009 (UTC)

Confused about the provided example

<lsl> //Rotates very slowly around a sphere's local Z axis .... Good for making a globe that rotates around a tilted axis

default {

   state_entry()
   {
      llTargetOmega(llRot2Euler(llGetLocalRot())*(llEuler2Rot(<90,0,0>*DEG_TO_RAD)),0.1,0.01);
   }

}</lsl> I used a variation of this in a child prim and got some very interesting, but not usable results. I'm then told that this method is unnecessarily laborous, as llTargetOmega already relates relatively to local root. Which as it turned out, it did, and I could settle for simply: <lsl> default {

   state_entry()
   {
       llTargetOmega(<0.0, 1.0, 0.0>, 1.0, 1.0);
   }

} </lsl> However, I'm new at scripting, and I don't understand rotations very well, did I misunderstand the example? -- Kessalta Blackburn 05:33, 19 February 2011 (PST)

Root prims (if memory serves) when rotating, do not utilize the local rotation to modify the direction of rotation. That is to say, if you put your second script in a root prim, it would *always* rotate around the global Y axis. Child prims on the other hand rotate around their local frame, not the global frame. The example script allows for a root prim rotation to mimic the how it works on child prims. -- Strife ^{(talk|contribs)} 21:12, 21 February 2011 (PST)