|
|
|
Hurm.
OK. Behavior changes will break things, especially when "wrong" behaviors are left in place for so long. The question I need answered is : will it keep working the 1.27 way, or will it be reverted? Because if I add the fix in, it will cause the "fixed" script to break if the behavior is reverted to 1.26 behavior. What's the plan? This needs to be resolved soon, or there will be no good resolution. Either we have to say "behavior changed, old scripts are broken, but now it works this way and will keep working that way," or we have to go back to the old behavior and document that. Note that Rob Linden asked the following question in September 2007:
<i>Are we past the point of no return with this? I.e. is there now too much content that relies on the broken behavior for us to change it now?</i> If that question was asked (with Lex Neva saying "probably yes") *two years ago*, it's probably too late to change the behavior now....! So are we saying 1.27 fixes SVC-93?
-Create a cube.
-Drag a copy. -Link the cubes. -Give each face of the child-prim a different color. -Add this script: rotation rot = <1, 0, 0, 0>;
default
{
touch_start(integer total_number)
{
llSetPrimitiveParams([PRIM_ROTATION, rot / llGetRootRotation()]);
}
}
-Touch the child-prim. Observe: the child rotates to it's new orientation. -Rotate the whole object a bit. Observe: the child-prim rotates to the same orientation relative to the root-prim. So this is still the way to set the local orientation. ======= Second Life 1.23.4 (123908) Jun 11 2009 15:16:56 (Second Life Release) You are at 302567.1, 279176.1, 401.0 in Egglebury located at sim7580.agni.lindenlab.com (216.82.36.188:13001) CPU: Intel Core 2 Series Processor (2401 MHz) libcurl Version: libcurl/7.18.1 OpenSSL/0.9.8j zlib/1.2.3 And this script always sets the child-prim to the same world-orientation:
rotation rot = <1, 0, 0, 0>;
default
{
touch_start(integer total_number)
{
llSetPrimitiveParams([PRIM_ROTATION, (rot / llGetRootRotation()) / llGetRootRotation()]);
}
}
Just like in SVC-93. Still confused as to what changed in 1.27
Did (rot / llGetRootRotation()) work in 1.26? Odd if so-- because it did work without llGetRootRotation(). Indeed, I'm not sure how it could work both with and without that, except at one specific rotation.
In any event, behavior did change. If there is a way to write it that uses both, I can update my script, and try to inform as many people as possible who have it.... However, before I start doing that, I want to make sure that things will stay the new way and not be reverted. I don't think the behavior of setting rotations changed – a lot of content would break then (including some of mine, which seems to work fine, and has code to work around SVC-93). I can't reproduce. Is there anything else which might produce the behavior you observe?
I tested Prospero and Troy's Presentation Screen on Aditi, I used two screens, one unmodified and one where the laser pointer is modified to include the division by llGetRootRotation. On Ahern where it is still 1.26.4 both lasers react the same and stay rotated with the screen. On Morris where it is 1.27.0 the lasers react differently, the unmodified one does not rotate correctly, only the modified one stays rotated with the screen.
So it seems on 1.26.4 it works with and without the division by llGetRootRotation() and on 1.27.0 it only works with the division by llGetRootRotation(). 1.26.4 tests done on: Built with MSVC version 1400 You are at 255424.8, 256526.5, 35.1 in Ahern located at sim3002.aditi.lindenlab.com (216.82.49.228:13000) 1.27.0 tests done on: Built with MSVC version 1400 You are at 255423.9, 256497.7, 35.5 in Morris located at sim3004.aditi.lindenlab.com (216.82.49.230:12035) Harleen – thank you for doing that test! It does indicate that the behavior change in 1.27 has something to do with local rotations. It also means that I can fix it for 1.27 without (much) fear that the fix will cause it to break in a future version.
Of course, this does mean that everybody who has a current version of the object now has a broken one... |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Open
Showstopper
Positioning & rotating of linked objects changed in server 1.27
Quote:
If you must set a child prim to a local rotation "rot" using PRIM_ROTATION, use this:
llSetPrimitiveParams([PRIM_ROTATION, rot / llGetRootRotation()]);