Is the rotation bug insurmountable?

It's been around for quite some time so I'm starting to think it is.

Which rotation bug are you referring to Ingrid? I certainly know of the one where you manually change the values on the "Object" tab and you have to update them in a certain order to get the effect you want. Without searching, could you give me a brief summary?

Is it where you delete the script from a rotating object, but it keeps rotating? Or am I delusional and that bug doesnt exist?

Possible reference to when an object is rotated manually, then position is selected, you reposition it, then it rotates partially back to the original position. This also can happen when you close edit.

Isn't that caused by packet loss?

It can also be caused by entering a rotation that's invalid. The client will sometimes try to display it, but when the rotation value makes a round trip to the server and back, it gets corrected back to a valid rotation, which can sometimes be quite a ways away from the invalid one you enter.

There's also the thing where you enter, say, 0,180,0, and it corrects it to 180,0,180 (I think?). That's not a bug! Those two rotations (assuming I'm right on that specific example) are exactly the same, in practice. The reason it's corrected is that internally, the rotation isn't stored as an x/y/z rotation, it's stored in an internal format that's much easier to work with. Changing your rotation like this is exactly equivalent to changing "720 degrees" to "0 degrees". One's redundant, and a computer program needs to work with a "canonical" value when faced with synonyms.

That's the one!

Lol! I even understood that! I always understood it intuitively, as a builder, but this is the first time I ever heard it explained in programming terms.

coco

Ah, I was right on the (0,180,0) -> (180,0,180) thing... except, there is actually a bug related to this:

1. create a prim
2. go into the edit window, click in the Y rotation box, and type 180, and press enter

What it does is set to 180,180,180... the reason for this is because you're telling it "0,180,0)", which is redundant, and should be "reduced" to (180,0,180). So it tries to do that, but you're sitting in the Y rotation box still with 180 there, so it leaves that unchanged. It's as if (180,0,180) was already there and you clicked on the 0 and typed 180 and hadn't pressed enter yet. For added fun, hit enter again, and it flips to (0,180,0), and it'll keep flipflopping between (0,180,0) and (180,180,180) every time you press enter, because both of these are redundant values.

I know I've reported this in the past. This is a pretty tricky thing to deal with from a programming sense. I guess what it should do is correct the Y rotation box out from under you, but even that can be pretty jarring.

Anyway, the end result of this is that it's often not a good idea to manually type rotation values in (although I try to do it all the time). For one thing, they're not intuitive... it's a rotation around the X axis, a rotation around the new (after X-rotation) local Y axis, and then another around the new Z axis... that can be very difficult to visualize. It's far better to use local axes and the grid and rotate using the rotation-handles. If you still want to, say, enter a rotation of "180 degrees around the Y axis" (because a rotation that simple is easy enough to visualize), you should clear all of the rotation boxes to 0, and then put your cursor in the Y rotation box and type 180, and then get your cursor out of there completely. Click in the x-size box or just click another prim or something, but don't press enter. Then the rotation will set to what you mean.

nim, i believe that is a primitive setting like particles which is only toggled on by the script, and then no longer needs a script to continue doing its thing