Rotations now not working correctly

Ok, rotation is now all messed up. This is both a building and a scripting issue, but since the scripting issue is frustrating me the most, I'll report it here.

It seems that certain rotations wont work anymore.

Take the following snippet of code (For reference, the door is at -180 on the Y axis before this executes)

llSetRot(llEuler2Rot(<0,-135,0>*DEG_TO_RAD));
llSetRot(llEuler2Rot(<0,-90,0>*DEG_TO_RAD));
llSetRot(llEuler2Rot(<0,-45,0>*DEG_TO_RAD));
llSetRot(llEuler2Rot(<0,-0,0>*DEG_TO_RAD));

The first three commands do nothing. The final one works, but of course, it doesnt look right now. The same is true, in reverse, when you try to open the door.

Or, take this code (Used to rotate part of a sliding door in my office, a child prim in a linked set:

vector open = <0,0,300>;
vector close = <0,0,360>;

rotation Inverse(rotation r)
{
r.x = -r.x;
r.y = -r.y;
r.z = -r.z;
return r;
}
rotation GetParentRot()
{
return Inverse(llGetLocalRot())*llGetRot();
}
SetLocalRot(rotation x)
{
llSetRot(x*Inverse(GetParentRot()));
}


default
{
state_entry()
{

}
on_rez(integer ignored) { llResetScript(); }


link_message(integer sender_num, integer num, string str, key id)
{
if(str == "open"
{
SetLocalRot(llEuler2Rot(open*DEG_TO_RAD));

}

if(str == "close"
{
SetLocalRot(llEuler2Rot(close*DEG_TO_RAD));

}
}
}

That works fine.

But on the opposite half of the door, where the only difference is that open and close are instead

vector open = <180,0,300>;
vector close = <180,0,360>;

It no longer works.

Mind you, these have been working fine prior to this patch.

Further details.

Its not just ignoring the rotation. in that first example. Its skipping entire sections of code.

The full code block that should run when I click on it is...

llShout(chan, "lightsoff";
llShout(chan, "smallin";
llSetRot(llEuler2Rot(<0,-135,0>*DEG_TO_RAD));
llShout(chan, "largein";
llSetRot(llEuler2Rot(<0,-90,0>*DEG_TO_RAD));
llSetRot(llEuler2Rot(<0,-45,0>*DEG_TO_RAD));
llSetRot(llEuler2Rot(<0,-0,0>*DEG_TO_RAD));

And assume that there is an equivilant, but exactly inverse, series of commands in the open statement.

It will go to the last llSetRot, and skip every command before that. The lights wont turn on/off, the runway (the largein and smallin commands) wont extend, etc.

Also, in the child prim rotation example I posted, the first time it tried to rotate it, it rotated the prim to 180, 0, 180. I troed to unlink and re-link, and the prim will now NOT move. (It's not locked, before you ask). Changing the rotation manually will NOT rotate it.

Yet more (and potentially more frustrating) news:

My door works fine...

In every sim...

Except the sim I created it in. Abbotts.

Thinking this was some issue with lag (Abbotts is fairly laggy as of late), I took it to the laggiest sim I know... Gualala.

It worked fine there.

Ok, now whats going on with abbotts, is I guess now the question...

Abbotts has been acting wierd for at least a week. I haven't had scripting issues, but I have had cache issues that were verified by Char Linden.

Yes, it has been. But these doors were working fine just before the patch.

LOL, you have all sorts of problems that only affect you, or the sim you are in, or your av, etc. etc. You should use an alternate av so the system doesn't do causeRandomErrors = true; when it detects you.

Something with rotations is fubared after the update -- it's affecting building and rezobject as well to my knowledge - I'll do a few tests after work tonight and see if I can further narrow it down.
You're not alone -- I've had emails from 8 people so far..


Siggy.

this is also possibly effecting sit rotations. I have a passenger transport jet and all teh sit targets are strange rotations because I put them on strange prims to save prims. Works fine when you get in. used to work fine all the time. Now suddenly I cross a sim boundry and I'm sitting the wrong direction.

(someone should atleast say that now you can have a rotation of 90 degrees on y and it's actualy 90 degrees and not 89.98; so the patch isn't all bad ^_^)

Not true.

I get the imprecise rotations as much, if not more, now, than I did before the patch.

i haven't had much time to play with it :-/

I have this same issue with a rotating door on a vehicle. It worked fine until the 1.4.6 patch.

And Reitsuki isn't the only one that seems to keep running into weird problems. I just stopped talking about them because it would be a full time job.

Rickard, I've had the same problem with my avatar getting re-seated the wrong way on zone change since my first vehicle 2 months ago. In other words, I don't think its related to this patch, but it could be. When that happens I also lose control, or the controls get reversed (???) even if there's no facility in my code for reversing the controls. I also get knocked out regularly at zone changes, even without full parcels, corners, or high speeds.

Kelly Linden told me the weird readouts in the Rotation edit boxes in the build tools are just output problems and not the actual rotation of the prim or set...

- Flyte

The bug is in Euler<->Quaternion conversions.

vector conv(vector a)
{
    return llRot2Euler(llEuler2Rot(a*DEG_TO_RAD))*RAD_TO_DEG;
}

llSay(0,(string)conv(<0,0,180>));
//says <-180,0,-180>

and it appears that when you edit an object and set it's rotation that it goes through the same server side library.

Personal besides the extra precision i don't think they ever should have changed how rotations work. With the change in range from -180->180 to 0->360 they introduced a strange bug into the interface where you get funny characters in y when you step up z with the arrows (which locks the objects rotation).

(this might be my fault; a sub version or so back i sent in an object thats rotation when fed to llRot2Euler caused a math error)

Or set the rotation of your object (how is by your choice - this gem hooterkia's both in edit mode and via llSetRot, RezObject, or any other method you care to try) to <0,0,180>.

The result will flip you around the z axis 180, then around the x axis 180... and your edit box will tell you the rotation is 180,0,90 -- which I don't think is right either

Till next time, sit on a prim and rotate! -- I'll be taking a scripting break until...... next update I think.

Siggy.

Oh, and I almost forgot -- the workaround:

rotate as per normal to 179.99 and not only will it work, but your edit box will tell you it's 180.00
(I think I can safely lose that .01 degree presision for the sake of it working).

hehe Happy rotating!

Siggy

I'd rather not fudge it.

rotation llEuler3Rot(vector v)
{
    v/=2;
    float ax=llSin(v.x);
    float aw=llCos(v.x);
    float by=llSin(v.y);
    float bw=llCos(v.y);
    float cz=llSin(v.z);
    float cw=llCos(v.z);
    return <aw*by*cz + ax*bw*cw,
            aw*by*cw - ax*bw*cz,
            aw*bw*cz + ax*by*cw,
            aw*bw*cw - ax*by*cz>;
}

It does give slightly different answers then llEuler2Rot but the answers are accurate to 4 or 5 places after being converted back to Eulers.

The main difference between the functions is that my function will return results with opposite signs on all the values (which evaluates to be exactly the same thing).

i don't totaly understand quaternions but this article helped a bunch.

http://www.gamedev.net/reference/articles/article1095.asp

This post is relesed into public domain.