What do I (and others) need to vote on to get llTargetOmega to work?

Okay, it seems that llTargetOmega() is all kinds of useless at the moment for things that don't spin continuously. Friend of mine made some kind of comment like "we could flip a coin for it" about an event coming up. Me, being a habitual scripter, thought immediately it would be quaint to actually script a simple one, the idea being that you click it to "spin", then click to stop, and it randomly picks heads or tails and will set a picture accordingly. Might make it more complicated later.

Anyway, here's the script:

default {
    touch_start(integer x) {
        llTargeOmega(<0.0, 1.0, 0.0>, 40.0, 1.0);
        state spinning;
    }
}

state spinning {
    touch_start(integer x) {
        llTargetOmega(ZERO_VECTOR, 0.0, 0.0);

        if (llFrand(1.0) > 0.5) llOwnerSay("Heads!");
        else llOwnerSay("Tails!");

        state default;
    }
}

That's the basics. However, when it stops, it stops where it is, it doesn't reset to it's actual location. "Fine" I think to myself, and throw a few llSetRot() calls in there, and it makes no difference.

So am I to believe that llTargetOmega(ZERO_VECTOR, 0.0, 0.0) is actually setting up an unstoppably unmoving rotation now?

Anyway, what I'd like to know is what in the heck I should be voting for in order to get llTargetOmega fixed for once? All I see is tons of reports not going anywhere that are a mix of being declared fixed when clearly they aren't, or which are just being plain ignored. llTargetOmega() has been buggy for so long it isn't funny anymore, it pretty much needs a team dedicated to it at this point to just re-write the damned thing because it's made up now of so many patches and bits of tape I'm not even sure it's powered by anything resembling programming code!

I think llTargetOmega was originally a bit of a hacked-in function to let people do smooth, continuous, client-side rotation of non-essential items, without trying repeated calls to llSetRot (which would be hideously laggy!). In that sense, it's doing it's job fine... lets you do a quick'n'dirty client-side rotation, and that's it. Sure, it's unpredictable, but that will always be a problem unless you use solely server-side rotations.

As such, I don't think it's likely to be "fixed" in the sense you describe, because it's been widely used for a long time, and implementing the new features would likely break anything that's already using it.

Besides, it's hardly a massively important feature. Dedicating a whole team to it when there's bigger fish to fry right now probably ain't gonna happen!

it only spins on the client side.

I love proving this wrong... I have a few fun spin, flip, and roll projects... Especially a set of physical gears driven by a single llTargetOmega scripted gear. I rez it often in NCI Kuula and people love to find ways to make it explode. (^_^)y

I discovered quickly to not use it to rotate vehicle tyres

llTargetOmega used to work fine, in that when you stopped the effect the object in question always, invariably appeared to jump back to its actual server-side rotation so what the client saw matched server-side reality. And starting llTargetOmega again always, invariably started the effect afresh from the actual resting rotation.

That doesn't happen any more. Not only does an object which has been stopped after a period of llTargetOmega often not return to its resting state visually, but if you edit such an object the edit window often reports that the actual in-world rotation of the object has changed! At the same time though, calling llGetRot in the object will report that it has not moved at all (as it should not have). llTargetOmega seems to be operating in some twilight zone, in some instances, where what is supposed to be a purely client-side effect is no longer, and has partially "real" effects on the rotation of objects that leave a residual disconnect between what the server sees and what the client sees.

Haravikk: I wish I knew the answer to your question, but all I can do is validate that it indeed is a real problem for which one would hope a real solution exists. You'd think so since it worked fine a year or so ago.

The answer is actually a simple one, once you understand how llTargetOmega works.

1) The assumption is that the object is not physical. I'll explain why in a moment.

2) llTargetOmega is ONLY (let me repeat that for emphasis: *ONLY*) on the clientside, UNLESS the object is physical.

3) Since it is only on the client side, the server representation of the object does NOT rotate at all. That means it remains at the same rotation throughout the operation of llTargetOmega.

4) When you stop llTargetOmega, it stops at the position where it is at on the *client*. Since the server has no way to know where it is on the client (let alone on multiple clients), it leaves the *actual* rotation alone, which is still what it was before you called llTargetOmega. Thus, you have an inconsistent state where the client(s) and the server don't agree on the actual rotation of the object.

5) Setting a rotation on an object will not send an object update to the client UNLESS the rotation differs by more than ~6 degrees in any axis from the current rotation known by the *server*.

6) Thus, if the object is set to ZERO_ROTATION, then you call llTargetOmega to spin it, then later call llTargetOmega to stop spinning it, and then call llSetRot to set it back to ZERO_ROTATION, the object will not rotate back to ZERO_ROTATION, since, as far as the server is concerned it already *is* at ZERO_ROTATION, and therefore, there is no need to send an update to the client(s).

The solution (I know you've been waiting on this, sorry ) is to llSetRot to some rotation which is more than 6 degrees off both the object's initial rotation, and the final rotation you desire, then rotate it back to the final rotation.

Yes, I have spent FAR too much time agonizing over all of the quirks of llTargetOmega, especially during its "buggy" phases. :-/

PS- In case you are curious, the reason that the server doesn't send an update packet automatically after you tell llTargetOmega to stop spinning is because it would break wings, swings, etc, that use reversing llTargetOmega calls to simulate reciprocating movement.

heyas;

correct me if i'm wrong.... but that doesn't really explain why zeroing out target omega FAILS to make the thing stop spinning on the client's viewer. well, except the part about not sending a target omega update to the client right away. which sounds like crap, because if it doesnt send target omega updates right away, how do the wings/swings go from forward to back at the right time?

anyhow, talarus, that's fascinating and useful information there!

but lltargetomega is still broken. you DID used to be able to set a target omega rotation and have something spin, and then set zero target omega to have it STOP spinning. personally, i dont care WHERE it stops, just the fact it fails to stop altogether is annoying.

Yeah, I wasn't aware that they had broken it to stop spinning yet again. It's been an off-again-on-again break/fix with that issue.

Actually, I just checked, and it appears that, at least for my existing spinning objects, they do indeed stop spinning when llTargetOmega(ZERO_VECTOR,0.0,0.0); is called. Not sure why it's not working for you, though. Is it intermittent?

I'm seeing the same odd effect as Anti: After doing an llTargetOmega spin and stopping it and doing an llSetRot (a 135 degrees change), calls to llGetRot and llGetLocalRot seem to think it's at the proper final rotation, but it's vistually off by 10 degrees or more, and the Edit Window also shows it off by 10 degrees or more.

What's more, I found that this doesn't happen for a single-prim object, but it does happen if it's a child prim doing the rotating.

There are ways around the problem.
Some events like floating text changes force the client to update.

I know about the trick to call llSetText to force updates... and used it. The problem is still there: a visual disconnect between what llGetRot (and llGetLocalRot) tell me and what I see on my screen.

I did another experiment using llSetLocalRot only, without any llTargetOmega calls. The visual disconnect went away. This means the problem is being caused by llTargetOmega.

I sent an example scripted object to Carl, illustrating the issue with the visual disconnect. He fixed it by changing the order to:

llTargetOmega(rot_vec, omega, 1.0); //Start rotate effect

llSleep(rot_time);

llTargetOmega(ZERO_VECTOR,0.0,0.0); //Stop rotate effect

llSetLocalRot(new_local_rot);

llSleep ( 0.1 );

llSetText("Dummy Text",<1.0,1.0,1.0>,1.0);

whereas the original had the llSetLocalRot before the second llTargetOmega. The second llSleep isn't necessary to prevent the visual disconnect - it seems to prevent a visual bounce at the end of the rotation. You can set the alpha of the hovertext to 0.0 also (invisible).

Thanks Carl!