llTargetOmega woes

[Rolig Loon]

I have an annoying puzzle.  I have written a fairly simple script that, among other things, changes the rate of llTargetOmega rotation of an object at random times.  Usually it works.  Every few times, though, the rotation stops completely and the only way I can restart it is to right-click on the object.  That always solves the problem, but I can't stand around right-clicking every time it stalls.  Speed doesn't make a difference.  It's just as likely to stall when it's spinning fast as when it's spinning slowly, and it doesn't make any difference whether the object is speeding up or slowing down.  It's the change in llTargetOmega that makes it stall.

• I have tried using SLPPF with PRIM_OMEGA instead of llTargetOmega itself.
• I have tried deliberately stalling llTargetOmega ( with llTargetOmega(ZERO_VECTOR, 0.0,0.0) ) before making the real change.
• I have tried applying a few degrees of llSetRot to jog it.
• I have tried the llSetText trick.
• I have also tried some imaginative cursing.

None of that works.  Only right-clicking.  Any clues?   Any cures?

ETA:  OK, this is a viewer issue of some kind.  If I TP out of the sim and back, the objects are spinning just fine ... not stalled.  So it's not a scripting problem.  :smileysad:

[LepreKhaun]

Definitely a viewer issue and along the same lines to what happens when you change a texture animation; sometimes it stops, often it stutters and every once in awhile it'll update smoothly.

 

No workaround that I'm aware of for either.

[Rolig Loon]

Thanks, LepreKhaun. That's pretty much what I concluded. I tried a couple of different viewers last night, including Linden Lab's current V3, which I avoid habitually.  The problem is there with all of them.  Unfortunately, this puts a dent in a client's project.

Two parts of the problem interest me.  First, if I grab the code that I'm using in a timer event now and drop it into a touch_start event instead, the llTargetOmega never fails when I switch speeds. That is, I can change speeds "manually" without trouble, but a timer can't do the same thing reliably.  Second. of course, is the fact that I can't cure the stall without either right clicking or teleporting away from the sim.  I have a feeling that if I could understand the first problem, the second one would be irrelevant.

 

[Rolig Loon]

Ooo!  Wait, WAIT!  Hold the phone.....  I think I have a solution, thanks to a clue that Maddy McMasters gave me.  I said that I had tried deliberately stopping llTargetOmega with llTargetOmega(ZERO_VECTOR,0.0,0.0>, but that it hadn't worked.  I just tried adding a one second delay before restarting llTargetOmega again.  That DOES work.  :smileylol:

From this, I conclude that it's not enough to just whack llTargetOmega upside the head and tell it to stop when you're about to change speeds.  You have to give it time the think about it too.

[Ela Talaj]

You should file a JIRA on it, Rolig. Sequential llTargetOmega() did not use to require delays between them and seems this problem appeared very recently ( I had it too). Most prolly a server bug which doesn't send update to the viewer on rapid rotation changes, introduced in one of the recent server updates.

[Yingzi Xue]

That's exactly what I was going to suggest, a delay to allow catch-up.  Good work finding the solution.  I had a script recently that uses llRemoveInventory to clear a prim's contents.  I found that if you don't put a delay between cycles it will miss some items.  I was able to find success with .2 delay, but I decided to give it wiggle room and made it .5 instead.