llRotLookAt with non-phys prims/objects

Newbie scripter playing with rotations. I actually understand quaternions (thank you spacecraft attitude dynamics courses -- I *knew* I'd use you someday) but am having a devil of a time getting objects to rotate the way I want.

llTargetOmega() results in a great, smooth, controlled rotation, but if I want to change the rotation mid-stream w/ any precision I think I'm out of luck. Since it's client-side, I can't set a target rotation (llRotTarget) as the server doesn't know it's rotating. Using timers is a no-go, as they seem to be way too imprecise in their interval.

Using llSetLocalRot()/llSetRot() works but produces choppy results (again the timer interval problem and/or the delay associated w/ the call). Not to mention setting a timer to go off often enough to even come close to smooth motion seems like a lag-tastic idea.

llRotLookAt() w/ llRotTarget() seemed like my savior, except I really don't want to go to all the hassles involved in making my object physical. The entry on the LSL wiki would lead me to believe llRotLookAt() works on non-phys objects too. It indeed does work for me, but with one problem -- I don't seem to be able to control the rate/damping of the rotation (neither the strength nor damping params in the fcn call have any impact on the motion I observe) and the rotational motion I get is WAY too fast.

Is this just the way it is, or am I missing something? I know I've seen better results than I seem to be able achieve in swings etc out there (non-phys even). Any advice?

I see what you mean about llRotLookAt(): for non-physical objects, it seems to move just like llSetRot(), regardless of the strength and damping arguments, the wiki's cheerful "whether or not it looks good" notwithstanding.

Because llSetRot() sleeps the script for 0.2 seconds after each call, I suspect the smoother rotations you've seen in-world for non-phys objects are the result of multiple little slave scripts inside the object, running in parallel under link_message direction of a master script. Don't know if llRotLookAt() also sleeps the script; if not, a tight loop of those in little increments approaching the desired rotation might look reasonable. Of course either of these would be, as you say, "lag-tastic."

I've had a fair amount of luck doing something like this:

1. llTargetOmega()
2. llSleep() a carefully calculated amount of time
4. llTargetOmega() off
3. llSetRot() to the rotation that I expect the object APPEARS to be at now


Sometimes the sleep is inaccurate, and sometimes step 4 seems to be ignored for a few seconds (!), but generally, this results in a smooth transition between two rotations at whatever speed I want.

Hey, thanks Lex and Qie -- I'm pretty certain one of the ideas you mentioned (or maybe some hybrid) will get me where I want to go.

I believe one example in particular I saw that exhibited fairly smooth motion does indeed use slave scripts; I just had never thought of that so didn't know what I was looking at when I saw several scripts in the object. "Multithreading" like that opens up a whole new world of LSL fun! (not to mention all kinds of potential trouble I could get myself into -- I'll _try_ not to inadvertently take down any sims with lag bombs.... lol).