Strange client-side rotation without llTargetOmega

Hello!

I recently scripted a swing set and rotating door which use physics for movement, but turn physics off when not in use.

Everything works fine with them except for one thing: When an agent first comes up to these objects in-world, if they are not in use, they often appear to be rotating on the client. (This occurrence is not consistent, of course, from client to client. It seems to mostly affect low FPS clients.) Of course, this stops if the client right-clicks on the rotating parts, or if some other agent starts using the objects. The really weird thing? I'm not using llTargetOmega. At all. (And after turning physics off with these objects, I do a llSetPos and llSetRot to get them back to where they started.)

Any ideas what's going on here?

(I've got a swing set and a couple rotating doors set up on Ginko island, for the curious.)

If you ever used llTargetOmega on the object while testing or whatever, that setting might still apply. It doesn't get cleared out just because your script stops using it. Even resetting a script in the object would not clear that setting since the setting lives with the object, not in the script memory space. This is similar to the hovertext that sticks around if you have ever called llSetText.

To clear any previous llTargetOmega setting, you would have to add a script that sets it to 0. Or create a new object and transfer your scripts to that.

I see this all the time. I'm not entirely sure what the casue is, but any object that has been physical-ised can end up doing a lazy rotation, most often but not always around its Y axis, after physics is shut off.

It seems to be some sort of object update "thing", as clicking the object, changing active groups on your avatar, or anything else that updates objects around your view will stop the rotation.

You can also force the client to update an object by (re)setting the color of one of the prim faces.

Thanks for all the good advice!

Zeno: At no point in the past had I used llTargetOmega on the objects, so there shouldn't have been a residual setting.

But... I think I might have fixed this problem for the majority of the time (I've yet to see this lazy rotation again, so far.) After stopping movement, un-physical-izing the object, etc., I've added a call to llTargetOmega which sets a zero-rotation target. (Which makes sense, I suppose. If un-physical-izing the object can occasionally cause a residual target omega... deliberately resetting this to zero should take care of the effect, eh.)

If I notice any more lazy rotation, I'll try resetting the color of a face, eh. Still, it would be nice not to have to do this. So... where do I go to report this bug, eh?

It happens often to my vehicles and to the AutoTrebuchet in Burning Life land. It seems that the client will sometimes continue to apply physical movement prediction to objects even though they're not physical anymore. This has to do with how physical objects' movement is sent to clients I think:

Physical object's acceleration, velocity and position updates are sent at discrete times, and the client interpolates this data to render a "smooth" movement. Apparently if the object stops being physical the client still interpolates over a few periods, simulating non-existent movement.

When you interact with an object, it forces a refresh of its position, so it "springs" back into place on your screen, even though on the server it never actually moved.

I hunted all over the place for this thread, and I'm already using trick of setting my llTargetOmega rotation to zero in order to circumvent the problem, however I noticed that a couple of my vehicles would still attempt a bit of a rotation every now and then, any suggestions beyond setting a 10 second timer that will remove itself after it runs?

Hmmm... well, the llTargetOmega hack detailed above seems to have cured the problem for most of my objects. But then, they never rotate with any huge angular velocity. (Rotating doors and swingset is mostly where I use this kind of movement.)

The single after-the-fact timer event might work; Please let us know if you come up with anything more elegant, eh!