llTargetOmega woes :(

I was playing around with llTargetOmega last night and found that it's differed vastly from when I used it last in 1.13 and documented the changes then:


Even after deleting the script containing the llTargetOmega() command the object is still spinning

The object's actual server side rotation is being effected even though this is on a non-physical object.

This only seems to happen to me when llTargetOmega is in a child prim.

Yep, I can mostly confirm that. I'm not sure if llTargetOmega is purposely a persistent object attribute (like floating text and particles, remaining after the script that initiated them is removed) but that appears to be the behavior *most* of the time. There are plenty of reports of llTargetOmega objects stopping at arbitrary times too, so one shouldn't necessarily count on that behavior.

As to the server-side rotation... I haven't tested this, but it's been reported that if you check the rotation of such an object via a script that chats llGetRot, the "real" server-side rotation has never changed, and the collision box is right where it was, etc. BUT checking the rotation manually with the edit tool makes it *appear* that the server-side rotation is different. So it's a very odd situation, where the edit tools are actually misreporting the rotation, giving a result that is in line with the visual appearance but differs from the "real" rotation.

Perhaps LL is to be applauded for implementing quantum indeterminacy into SL, since the act of observing the rotation (and the choice of measurement tool) alters the results

Some have had luck nailing down this stuff by doing something inobtrusive that still forces a prim update from the server, such as llSetText, once the TargetOmega effect is done doing its thing. Again it's not something I've tested, but seems reasonable and worth trying.