Changes to llGetRot() or llGetLocalRot()?
|
|
Jillian Callahan
Rotary-winged Neko Girl
Join date: 24 Jun 2004
Posts: 3,766
|
09-05-2005 04:20
Just tried out one of my vehicles in the preview and the wings and canopy now behave oddly... I'm using the following to figure the local rotation I need to move the child prim using llSetPrimiveParams (so I can move and rotate at the same time) rotation LocalRot(rotation localrot)
{
rotation LocRot = localrot / ( (ZERO_ROTATION / llGetLocalRot()) * llGetRot());
return LocRot;
} I'm a bit too tired right now to describe exactly what the new and unwanted behavior is, suffice to say the prims position correctly but the rotations are wrong unless the root prim is unrotated. Please help? |
|
Nathan Stewart
Registered User
Join date: 2 Feb 2005
Posts: 1,039
|
09-05-2005 06:22
You should have a chat to cubey, he's having the same problem with his vehicles too, i had wondered why my little typing keyboard showed in a different position than before, but on some of his vehicles things like the rocket flames appear in the wrong place etc
|
|
Jillian Callahan
Rotary-winged Neko Girl
Join date: 24 Jun 2004
Posts: 3,766
|
09-05-2005 11:45
Looks like the problem may be in llSetPrimitiveParams.
Now to see if it's that it does a local rotation or a global based on context (called from a child or root prim) or if it's just broken.
|
|
Nathan Stewart
Registered User
Join date: 2 Feb 2005
Posts: 1,039
|
09-05-2005 13:35
Ok i've been running between agni and siva, and i think i might have found the problem, but i think its going to be a bug that has been fixed for 1.7.
In 1.6 a rotated root prim in a link set when using llsetprimativeparams in a child prim it wouldnt be the value you had given it, ie
llSetPrimitiveParams([PRIM_ROTATION, <0, 0, 0, 1>]); on a rotated root in 1.6 isnt even/square in 1.6
now in 1.7 using that value gives the correct rotation in a child prim
I havent tested any with llgetrot or llgetlocalrot, i'll start on that, but as far as setparams go, set position still seems like the behavior in 1.6 in that if you rotate the root prim it doesnt position it to the co-ords
Edit: After a bit more testing using setprimparams, the rotation is very weird in 1.6, if you set the rotation as 0,0,0 then it actually copies the rotation of the root prim, no matter if you want it to be flat and square at 0,0,0
|
|
Jillian Callahan
Rotary-winged Neko Girl
Join date: 24 Jun 2004
Posts: 3,766
|
09-05-2005 19:31
From: Nathan Stewart Ok i've been running between agni and siva, and i think i might have found the problem, but i think its going to be a bug that has been fixed for 1.7.
In 1.6 a rotated root prim in a link set when using llsetprimativeparams in a child prim it wouldnt be the value you had given it, ie
llSetPrimitiveParams([PRIM_ROTATION, <0, 0, 0, 1>]); on a rotated root in 1.6 isnt even/square in 1.6
now in 1.7 using that value gives the correct rotation in a child prim
I havent tested any with llgetrot or llgetlocalrot, i'll start on that, but as far as setparams go, set position still seems like the behavior in 1.6 in that if you rotate the root prim it doesnt position it to the co-ords
Edit: After a bit more testing using setprimparams, the rotation is very weird in 1.6, if you set the rotation as 0,0,0 then it actually copies the rotation of the root prim, no matter if you want it to be flat and square at 0,0,0 I'm sorry, but that doesn't match my observations at all... so I'm confused. What is the proper way to figure the local rotation from a global if one is going to use llSetPrimParams to rotate a child prim? Seems llSetRot is behaving the same, BTW. LINDENS!!! What's going on here? Where's the warning this was (a) a bug fix and (B) that a behavior so many use is going to change?? This breaks too much! |
|
Nathan Stewart
Registered User
Join date: 2 Feb 2005
Posts: 1,039
|
09-05-2005 20:06
Ok been working on this all day,
llGetRot and llGetLocalRot seem to be reporting the same values for both 1.6 and 1.7 now the but, in 1.7 you can edit the root prim and rotate it via the numbers and it doesnt mess with the others, while in 1.6 it does. But i dont think that will affect many.
What i do think it is, is the changes in the way llSetPrimitiveParams is dealing with rotation, and perhaps any maths previously used to make the old system work.
|
|
Nathan Stewart
Registered User
Join date: 2 Feb 2005
Posts: 1,039
|
09-05-2005 21:50
I totally agree things have changed and its not documented. I've created a test script to diagnose alot of data, being 5am im a bit tired to write it all out at the moment but basically if you use llgetlocalrot in the child prim and the root is rotated it will work kinda like this intended rotation 45deg x axis, root prim is rotated 12 degrees then it will rotate the child prim the difference 33 degrees im guessing that works on all axis, but not had time to test. if you use llgetrot then it just passes the rotation off 45 intended is 45 on the child prim i think this script should work, what the results chatted should be the same in 1.6 and 1.7 if both are setup the same, this is placed in the child prim with the root prim rotated.
default
{
touch_start(integer total_number)
{
vector eul = <45,0,0>; //45 degrees around the z-axis, in Euler form
eul *= DEG_TO_RAD; //convert to radians
rotation quat = llEuler2Rot(eul); //convert to quaternion
rotation quat1 = llGetRot() * quat; //using llGetRot
rotation quat2 = llGetLocalRot() * quat; //using llGetLocalRot
rotation quat1a = llGetRot(); //using llGetRot
rotation quat2a = llGetLocalRot(); //using llGetLocalRot
rotation quat3 = quat / ( (ZERO_ROTATION / llGetLocalRot()) * llGetRot());
// llSetRot(quat3); // Change quat 1/2/3
llSetPrimitiveParams([PRIM_ROTATION, (quat3)]); // Change quat 1/2/3
llSetPrimitiveParams([PRIM_POSITION, <1, 1, 1>]);
llSay(0, (string)(quat)); // Quat
llSay(0, (string)(quat1)); // GetRot Value * Quat
llSay(0, (string)(quat2)); // GetLocal Value * Quat
llSay(0, (string)(quat3)); // LocalRot Value
llSay(0, (string)(quat1a)); // GetRot Value
llSay(0, (string)(quat2a)); // GetLocalRot Value
}
}
|
|
Nathan Stewart
Registered User
Join date: 2 Feb 2005
Posts: 1,039
|
09-06-2005 08:26
Ok narrowed down further, from what i can see llsetprimativeparams and llsetrot are now working locally and not taking the rotation of the root prim into factor when rotating itself In 1.6 if the root prim was set at x axis 15 and you use this then it adds 15 to the intended movement of 45 In 1.7 it doesnt matter what x y and z are for the root rotation its child rotation will be 45 degrees, or whatever set in the script.
default
{
touch_start(integer total_number)
{
vector eul = <45,0,0>; //45 degrees around the z-axis, in Euler form
eul *= DEG_TO_RAD; //convert to radians
rotation quat = llEuler2Rot(eul); //convert to quaternion
// llSetRot(quat); // dis. this or the next
llSetPrimitiveParams([PRIM_ROTATION, (quat)]); // dis. this or the prev
llSetPrimitiveParams([PRIM_POSITION, <1, 1, 1>]);
}
}
|
|
Cubey Terra
Aircraft Builder
Join date: 6 Sep 2003
Posts: 1,725
|
09-06-2005 10:03
I have no idea what the change is that they made, but it affects llSetRot and not just llSetPrimitiveParams. Almost all of my vehicles are broken in 1.7. So far the only workaround I can see is to tell poeple not to rotate their vehicles at all, and they'll work fine.  Can LL please let us know what's happening? Is this considered a bug in 1.7 or a "fix" to llSetRot that breaks all kinds of other things? Is it going to return to the 1.6 behaviour, or do I have to rescript all of my vehicles for 1.7 (something I doubt I'll have time to do)?
_____________________
C U B E Y · T E R R A planes · helicopters · blimps · balloons · skydiving · submarines Available at Abbotts Aerodrome and XstreetSL.com 
|
|
Kelly Linden
Linden Developer
Join date: 29 Mar 2004
Posts: 896
|
09-06-2005 10:16
If it broke existing content it is a bug*.
* We will explicitly say if we are intentionally breaking content. This is rather rare, and we don't like to do it.
_____________________
- Kelly Linden
|
|
Strife Onizuka
Moonchild
Join date: 3 Mar 2004
Posts: 5,887
|
09-06-2005 12:02
/me pokes kelly "what about the unreported change to llRequestInventoryData in 1.6 that broke content?"  Couldn't you simplify that function (at the start of the thread) as:
rotation LocalRot(rotation localrot)
{ //take the local rot and reverse rotate it the total rot, then rotate the desired rot that much
return localrot * (llGetLocalRot() / llGetRot());
}
_____________________
Truth is a river that is always splitting up into arms that reunite. Islanded between the arms, the inhabitants argue for a lifetime as to which is the main river.
- Cyril Connolly
Without the political will to find common ground, the continual friction of tactic and counter tactic, only creates suspicion and hatred and vengeance, and perpetuates the cycle of violence.
- James Nachtwey
|
|
Jillian Callahan
Rotary-winged Neko Girl
Join date: 24 Jun 2004
Posts: 3,766
|
09-06-2005 16:39
From: Kelly Linden If it broke existing content it is a bug*.
* We will explicitly say if we are intentionally breaking content. This is rather rare, and we don't like to do it. Oh thank the gods. Now, is this considered high enough priority to keep 1.7 off the main grid until fixed? *smiles warmly, looks pleadingly* From: Strife Onizuka /me pokes kelly "what about the unreported change to llRequestInventoryData in 1.6 that broke content?" Couldn't you simplify that function (at the start of the thread) as:
rotation LocalRot(rotation localrot)
{ //take the local rot and reverse rotate it the total rot, then rotate the desired rot that much
return localrot * (llGetLocalRot() / llGetRot());
}
Uhm... I am not sure. (Or are you being nice and telling me it would be by asking a question?  ) I have really started to "get" rotations, but I have not yet mastered them by any means. |