Rotation issues in 1.81

Has anyone else been haiving issues with rotation behavioral changes in 1.81. I have an object thar doesllRezObject of 4 other objects that in turn rotate and orient themselves using llLookAt it worked perfectly prior to 1.81 and now I am probably going to have to go back and redo (cover your eyes if you are squeamish) the quaternion math to correct this , sigh

What do they do now?

randomly one of the 4 rotates to "look" in the wrong direction.

lol, careful you're giving your alts away .

Seriously though, does it always rotate wrong in a predictable manner, or in a certain range of rotations? What vectors are you using for lookat?

Also, llGetRot() in attachment vs. the visible avatar rotation (around Z) seems to be off by some 30 degrees in 1.8.1

it's been that way since sometime in 1.5 or 1.6. One of those versions increased the slop the avatar model has in realigning itself with the direction you're facing when you turn.

Heather is my sister so its no biggy
As far as as the rotation issue I started looking at it and I am completely confused now. It seems completely haphazard sometimes its only one of them sometimes its 2 sometimes all 4 work fine. If there was any consistency to it I could fix it easily, as it is, I am going to go shave my head; it hurts too much pulling out my hair over this. Wasn't looking for an answer here I was just checking if anyone else was having problems. Took me several days to learn quaternions and to get it to work and just frustrated - guess I'll take product off the market until I sort it out - sigh

Edit and oh while I'm at it Heather is the sweet one I'm the one with 20 guns that threatens to go Linden hunting when things like this happen

I've noticed some rotation issues in 1.8.1, though not what you're refering to.

When entering rotational values by hand, everyone knows that certain combinations of value are not liked by the system... The system changes all three values to a "new" set of values that mean the exact same thing, but are a more direct representation of the quats that the system thinks in.

Well, every since 1.8.1, I've noticed a *very* frustrating bug: If you change one value to the point where it causes all three values to change, the three values change... except the one you just entered. It changes last. So the other two values change, and it sees the value you just entered... and thinks that that value is a 'new' value again (as near as I can tell), and changes the other values /back/ to what they used to be. In other words, no rotation actually occours.

It's very much like working in packet loss, and thats what I thought it was at first... except that no problems exist with positioning or scaling, just rotation, and the problem only happens if I try to enter the rotational values by hand in the edit window... Drag-rotating doesn't produce this error.

It's possible that part of the same bug is causing your problems.

I've also notice some odd rotation qwirks. If I rez an object in edit, then touch another object, the original rotates 90 degrees along the X axis. Let me give an example:

Rez a piece of artwork. Click another piece to check z so that both can be set to same height. The first will rotate 90 degrees along the x axis. If it's rotated back, it will stay and the effect will not happen again.

Just a little weird.

i had some wonky rotation experiences today. it was only on one item i rezzed and i used numerics to get perfectly straight. i do this allllll the time and had done it today on two other pieces, however this one went haywire. trying to set rotation numerically resulted in my entries being replaced by wacky random numbers and my picture sitting on wall in a squirelly fashion. i ended up having to set it by eye. if it happens again, i will do a bug report.

OK resolved it myself - evidently was taxing the processing power of the server- I put a delay between the last stage where I got current rotation and did a series of euler etc...calucations and the llSetRot and the problem went away, maybe LL added additional overhead in 1.81 because never happened prior to it but anyway issue resolved so can soothe cranky customers who dont like straightening chairs themselves
now to add the automatic table clearing and dishwashing functions (not kidding - I HATE doing dishes)

1. Set X to 90... item faces wrong way, that's OK.
2. Set Y to 180, it should face front, it does! Great!
3. I click on a different attribute and... waitaminute, Y is back to 0 again.
4. Goto 2.

It also happened another way a few times, with X=270 and the object facing the right way, but upside down.

I have noticed things like this before, and not just recently. I think sometimes it's an update issue (if the coordinates or rotation components revert to some previous value) and others it's a gimbal lock issue (if changing one component alters the others.)

From what I've read, quaternions are immune to gimbal lock, but the editor uses Euler angles (as it should, since we aren't all mathematical geniuses) & is apparently susceptible to gimbal lock.

From what little I remember on the subject, gimbal lock is a situation where one component is at some particular angle (90 degrees?) relative to another, such that changing one component results in an equal and opposite change in the other, negating the change. I'm probably wrong on some detail of that, but it matches what I've observed. It doesn't happen very often, so you have to poke the editor in just the right way to get it to happen.

Yeah, I've noticed it before, buuuuut... I've noticed it *constantly* since 1.8.1

I don't understand the technicalities or the terms used... but I do understand I'm having this same problem.

It works fine when manually rotating stuff dragging the ball, but actually inputting figures does go screwy.

Lewis