Don't click here unless you want to be banned.

## LSL Wiki : llTargetOmega

HomePage :: PageIndex :: RecentChanges :: RecentlyCommented :: UserSettings :: You are crawl809.us.archive.org
llTargetOmega(vector axis, float spinrate, float gain)

Sets target omega. Makes an object rotate smoothly, without "choppy" steps.

axis is a vector describing the axis the object will rotate around. For example, <0,0,1> will rotate the object around the Z (vertical) axis.¹
spinrate is the rate at which the object will spin (rotate) around the given axis (in radians per second).
gain is the strength of the spin, which only has an effect on physical objects. However, it still must be non-zero for non-physical objects.

NOTE: Currently llTargetOmega() is not performing properly, especially when involved in an avatar attachment. llTargetOmega cannot currently be relied upon to rotate avatar attachments properly, and exhibits inconsistent results on non-attached objects.
--Concerning HUDs, llTargetOmega() works without any problems.

This function can be used in a child link (in which case the child will rotate locally around its own center) or in a root link, in which case the entire linkset will rotate around the root's origin. (As used in the planets thing in the main grid's welcome area here). See also this forum note.

Beginners are often confused about the difference between this function and llSetRot. llTargetOmega makes the object SPIN with the specified angular velocity. llSetRot just turns it ONCE to face in a particular direction.

Notes:
• The rotation speed is based on the axis vector multiplied by spinrate, so it is a good idea to normalize (see llVecNorm) the axis vector or spinrate won't act like radians per second. For example, consider llTargetOmega(<0,0,1>,1,1). Then (<0,0,2>,1,1) would rotate twice as fast, (<1,1,0>,1,1) would rotate llSqrt(2); times as fast.
• When the object is physical it interacts with the physics engine² and is frequently updated.
• When the object is physical llTargetOmega affects the local axis of rotation.
• When the object is non-physical llTargetOmega effects the global axis of rotation
• When an object is non-physical (the more common use) the effect is simulated purely on the client ("client-side") and not the server (this rotation "state" is sent once). No updates, other than the start of rotation, is necessary so it reduces the server and network overhead, but means the object will not actually move according to the server; it just moves to the client. This can be confirmed with llGetRot. This also means:
• *This quirk appears to be no longer present in SL v1.13. Could LL or another party confirm?* Selecting the object in edit mode will show the object as the server sees it.
• Avatars will collide with the object's bounding box as it was before rotation began. It is a good idea to phantom larger objects so avatars won't bounce into things they can't see.
• The start of rotation is not synchronized, so not everyone will see the same thing. At some time the object may appear to be rotated, for example, 45 degrees from its initial position to one person, yet 60 degrees to someone else.
• *This quirk appears to be no longer present in SL v1.13. Could LL or another party confirm?* Calling llTargetOmega again will rotate the object from the original position, not from where it looks like it is at the moment of the call.
• *This quirk appears to be no longer present in SL v1.13. Could LL or another party confirm?* Other scripting calls that force a client data update of the object will seem to reset the effect (physically moving or changing the properties of the object will cause the object to stutter/twitch instead of rotate freely/smoothly).
• To disable a previous llTargetOmega() call, do this: llTargetOmega(ZERO_VECTOR, 0, 0);
• A nonzero gain with a zero spin_rate causes the object to try to stop all spin, rather than simply cancelling a previous llTargetOmega() call.
• When stopping llTargetOmega() in a HUD, the position of the prim will be the exact same as when llTargetOmega() was called.
• If there are other forces applied to a prim together with llTargetOmega(), (using llSetForce), use llTargetOmega(-llGetOmega(), 0., 1.) to cancel spin. Note that the gain must be non-zero, but not necessarily 1.

¹: To get a rotation around a specific axis no matter how the prim/object is rotated, use llRot2*(llGetRot()) (where * is "Up", "Fwd", or "Left") for the axis. Note: the llTargetOmega script will have to be recompiled/reset if the prim/object is rotated while running or it will no longer rotate around the specific axis correctly.
²: It seems easy to oddly launch things this way, though. Be careful with this combination.

This article wasn't helpful for you? Maybe the related article at the LSL Portal is able to bring enlightenment.

Functions | Dynamics | Rotation
Comments [Hide comments/form]
What unit is spinrate measured in?

It's not revolutoins per second, it doesn't *seem* to be radians per second...
-- NeoRebus (2004-07-18 17:22:39)
nevermind, it is radians per second. :)
-- NeoRebus (2004-07-18 17:36:14)
it works for non-physical children in 1.5.12, but it appears to not work for physical objects. So no spinning tires yet :(
-- CaoimheArmitage (2005-01-11 05:12:14)
Child prims can be rotated, but re_rezzing has problems. However, there is a simple workaround:
http:forums.secondlife.com/showthread.php?t=17799&highlight=llTargetOmega
-- ZenoConcord (2005-07-17 20:01:30)
That link is here. (Ending itallcs.)
-- CatherineOmega (2005-07-17 22:25:54)
Instead of setting the alpha to the current alpha, doing a llWhisper seems to do a similar job of triggering the client-side rotation. But that simple workaround was not quite enough. I also had to unlink and relink the prim that I was trying to rotate, and even then, it didn't always work reliably.
-- ZenoConcord (2005-07-19 19:51:22)
Could you use this to make a prim wave back and forth, by changing the spin every few seconds, or would it drift too much?
-- ResunaOddfellow (2005-08-16 10:23:42)
Any update to the function will cause it to reset to the original position, so, no, it won't "wave back and forth"--smoothly anyway.
-- EepQuirk (2005-08-24 22:22:01)
If you really would like to have the rotation change direction, you must compute the approximate amount the object has rotated due to the effects of target omega. The object should then llSetRot to this computed rotation before calling llTargetOmega again, reversing the movement. JeffreyGomez is someone to ask about the math behind this.
-- ChristopherOmega (2005-08-27 03:01:05)
Eep, I merely intend to keep technical accuracy on this Wiki, you've done nothing but destroy it by locking pages and attacking others.
-- IceBrodie (2005-08-27 05:07:52)
Ice, you apparently did remove useful, relevant information. If you felt it was inaccurate, perhaps you should first add a comment about that before deleting someone else's contribution.
-- ZenoConcord (2005-08-27 20:00:42)
Reorganized and added some information. It'd be nice if someone double-checked my additions.
-- IoneLameth (2005-12-18 14:21:47)
Im not sure if this is relevant anymore, but I think this may be a decent implementation of the "math" I talked about in my previous comment:
```float lastCall = -1; // To avoid destroying the value of llGetTime by calling llResetTime.
targetOmega(vector axis, float spinrate, float gain) {
spinRate *= llVecMag(axis); // To compensate for normalizing.
axis = llVecNorm(axis);
if (lastCall != -1) // If we were spinning...
llSetRot(llAxisAngle2Rot(axis, spinRate * (llGetTime() - lastCall)));
llTargetOmega(axis, spinrate, gain);
lastCall = llGetTime();
}```
Im assuming nothing calls llResetTime in the rest of the script, all calls to llTargetOmega are replaced with targetOmega, and that nothing forces the object to update. Its probably going to be a very rough approximation, since non-physical llTargetOmega calls are done completely client-side, and the math is taking place server-side.
Note: I havent tested this in-world, so it may not work at all.
Good luck with it! :-)
-- ChristopherOmega (2006-02-12 11:51:27)
Actually, it DOES infact go in radians per second. Remember, a full circle in radians is essentially -pi to pi, and llTargetOmega(<1,0,0>,1,1); ) appears to go around once roughly every 6.3 seconds. To prove it, try this.
llTargetOmega(<1,0,0>,6 * DEG_TO_RAD,1); it will spin around a full rotation exactly once every minute. Could be useful for second hands on clocks. Speaking of which, I've found a way to give the illusion that llTargetOmega is syncronized across clients, but's going to be tough. Also, it seems that the decimal accuracy on llTargetOmega is not good enough to make a real time minute hand. Does anyone know the floor for how slow a rotation can be?
-- LuccaKitty (2006-06-05 16:09:53)
In Version 1.11.3 (1)
Changing the spinrate and the gain and then calling llTargetOmega again will not rotate the object from the original position anymore. It does seem to snap back to a position it was in a fraction of a second earlier. Changing the axis and calling llTargetOmega again does start rotating the prim from the orginal position again.
-- FransCharming (2006-08-11 06:37:53)
In Second Life 1.13.0 (8) Nov 28 2006 17:36:26.

PREVIOUSLY, when I wanted to reset to the rotation to the original rotation I simply set spinrate = 0 in llTargetOmega. This no longer works. I attempted to implement what FransCharming suggested by "changing the axis", but either this has changed or I did not understand his meaning fully. WHAT DOES PRESENTLY WORK IS:
```// Before beginning rotation

rotation quat=llEuler2Rot(DEG_TO_RAD*<270,1,270>);
//set 1 degree off desired final rotation.
//Can put in rotation coordinates; I keep in degrees for illustration.
llSetRot(quat);
llTargetOmega(<0.0, 0.0, 1.0>, -PI/2, 1.0); // start spinning

// When stopping rotation

rotation quat=llEuler2Rot(DEG_TO_RAD*<270,0,270>); // desired final rotation
llSetRot(quat);
llTargetOmega(<0.0, 0.0, 1.0>, 0, 1.0); // stop spinning```
-- StophLongully (2006-12-01 14:16:00)
I have noticed strange effects with llTargetOmega recently where under certain circumstances it will be an non-physical yet still affecting physical objects!
-- NexiiM (2007-01-07 02:37:11)
I'm having problems in that sometimes I can get target omega to stop, and other times I cannot. It seems to be inconsistent. Has anyone had odd behavior with trying to get something to stop spinning?
-- DedricMauriac (2007-03-30 23:37:20)
Okay, I'm seeing some weird stuff with llTargetOmega. I've been working on some steampunk stuff, and I have a sawblade hand and a gatling gun hand. They both use the same script. The sawblade hand has the script in a child prim, the gatling gun script has the script in the root prim. I have commands to turn the spinning on and off, and I know that it is reaching the llTargetOmega command, as I have some debug llOwnerSay commands after them.

Basically, what I'm seeing is that llTargetOmega always works in a child prim, even if you cross sim lines or teleport. However, when the script is in the root prim, if I cross a sim line or teleport, the llTargetOmega command stops working. I have to edit the gatling gun to get it to work again. And yes, I'm using StophLongully's trick to get it to work properly in the first place. Can anyone else confirm this behavior?
-- mo-76-0-27-36.dyn.embarqhsd.net (2007-04-03 10:05:35)
I can confirm Dedric's observation.
Stopping spinning works very inconsistently and for what Im working on just now, often not at all.
:-(
I note in the body a number of comments along lines of "*This quirk appears to be no longer present in SL v1.13. Could LL or another party confirm?* " - at least in the case of a child prim, I can confirm at least the first two of these.
-- PatchLamington (2007-04-05 02:47:46)
ps This bug appears to be in the client only... the call to stop rotating with llTargetOmega has no apparent effect... but logging out then back in shows the object as the server sees it.
-- PatchLamington (2007-04-05 03:07:59)
StophLongully's trick for stopping spin is not working for me on 14.1. However if you set spin rate to a very low value (say 0.0000000000000001) it will appear to everyone that it stopped. If the math is done right by the client (but don't rely on that :P) it would take about 11 million years to make a full rotation :)
-- MerothJunge (2007-04-14 04:00:34)
Stoping rotation and setting to some default value in 1.15.0 (2):
When you check the rotation of object using llGetRot(), it is not affected by end-state caused by llTargetOmega() (although you can see the values in the edit form). Trying to llSetRot() to the same value does nothing (probably optimalization on server side). The trick is you have to set rotation to different value and then to the desired value.
```llTargetOmega(<1.0, 0.0, 0.0>, 0.0, 0.0); // stop the rotation
llSetRot(<0.1, 0, 0, 1>);  // some bogus value
llSetRot(<0.0, 0, 0, 1>);  // desired rotation```
-- ip-89-102-143-242.karneval.cz (2007-05-08 23:57:37)
none of these tricks work for me in 1.18.3.4RC, can't get objects to start and stop no matter where they're linked, whether physical or not. will do some testing when i have time.
-- user-5444e7af.lns2-c11.dsl.pol.co.uk (2007-09-18 14:01:31)

-- Can somebody please delete this stupid spam?

--
-- c-67-191-214-56.hsd1.ga.comcast.net (2007-11-06 17:38:21)
Attach a comment to this page: