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.

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.

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 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 also means:
• 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.
• 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.
• 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 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.

---

Functions | Dynamics | Rotation