|
|
|
IBME Swindlehurst made changes - 07/Feb/08 08:31 AM
Harleen Gretzky made changes - 07/Feb/08 12:27 PM
Harleen Gretzky made changes - 07/Feb/08 12:27 PM
Harleen Gretzky made changes - 07/Feb/08 12:27 PM
Harleen Gretzky made changes - 07/Feb/08 12:27 PM
Harleen Gretzky made changes - 07/Feb/08 12:28 PM
Azadine Umarov made changes - 02/Apr/08 07:20 AM
Azadine Umarov made changes - 02/Apr/08 07:22 AM
Azadine Umarov made changes - 02/Apr/08 07:28 AM
This doctored snapshot shows the workaround. Not that the Shift-dragged copies of the problem items continue to seem to resist efforts to recompile the contained llTargetOmega scripts. This may be more a feature than a bug, though, considering it may also break many spinning "For Sale" signs presently in use on ad farm and other lots?
Azadine Umarov made changes - 02/Apr/08 07:52 AM
Azadine Umarov made changes - 02/Apr/08 08:04 AM
I reopened this as a server-side or service issue (and using the arguably inappropriate issue here) because all the usual workarounds that seem to commonly address the issue, and are documented in comments to VWR-5303, do not seem to work for the items I found and describe in my other comments. Perhaps this is simply a side effect of the Havok-related fixes that are mentioned in the discussion of this related VWR issue? Will leave this here for now unless I hear a cogent reason to fold it into what seems to be a related but not a duplicate issue.
Azadine Umarov made changes - 02/Apr/08 08:07 AM
The issue you are describing seems to be
Harleen Gretzky made changes - 06/Apr/08 06:24 PM
Azadine Umarov made changes - 06/Apr/08 08:25 PM
Azadine Umarov made changes - 06/Apr/08 08:28 PM
Follow-up: The affected items shown in the jpg attachment above (tgtomega_odd_002.jpg) appear to have started moving again as of 6 Apr, possibly due to some resolution of other grid problems or a restart of the region. As mentioned in
Azadine Umarov made changes - 06/Apr/08 10:07 PM
While I agree that there is overlap between this issue and
Azadine Umarov made changes - 08/Apr/08 09:23 PM
I can confirm the same problem, and the same temporary "fixes", working for the region Honawan. I haven't investigated it thoroughly (since I don't pay Linden USD 170/month for me to be doing the work they obviously don't have the competence to do) but after making a "restart" of multiple items, it seems that large, root or single prim items with the llTargetOmega axis aligned with one of the world axis (i.e. <1.0, 0.0, 0.0>, <0.0, 1.0, 0.0> and <0.0, 0.0, 1.0>) keeps spinning longer than small, child prim items with the llTargetOmega axis not being aligned. Four individual 0.5x0.5x0.5 meter child spheres with the LSL line
llTargetOmega(<0.0, -0.5, 0.866025>, 0.628319, 1.0); "died" after only 5-10 minutes again, while a 10.0x10.0x10.0 meter root sphere with the LSL line llTargetOmega(<0.0, 0.0, 1.0>, 0.628319, 1.0); is still spinning after more than an hour. I don't know if this is of any help. Oh, and (after feeling compelled to waste some more unpaid time doing Linden's job) I can confirm this is obviously a viewer issue, since everything rotates OK with viewer 1.19.0(5) but not with 1.19.1(4). So, I seriously suggest throwing the 1.19.1 back to the alpha/release candidate status, which it obviously never was mature enough to leave, considering all the other screw-ups with it as well, and offer something that works as the standard viewer instead. And yes, I am royally pissed over all the extra time and efforts Linden's incomptence cost me. Magnuz, you have my personal thanks for confirming this, and providing some solid info, unpaid and frustrating as it was. My remaining comments, some of the probably misguided in the extreme, follow yours under
 default
{ state_entry() { llTargetOmega(<0,0,1>,1,1); } } *FIXED* Second Life 1.19.1 (4) Apr 2 2008 12:03:24 (Second Life Release) You are at 260130.0, 248374.4, 30.7 in Hazzard County South located at sim4301.agni.lindenlab.com (63.210.157.205:13005) CPU: Dual i386 (Unknown) (2000 MHz)
James Benedek made changes - 10/Apr/08 06:27 AM
As explained in
Magnuz Binder made changes - 10/Apr/08 07:06 AM
Andrew Linden made changes - 10/Apr/08 03:15 PM
I tried the shift-drag workaround. A weird thing happens. It fixes the rotation problem in the ORIGINAL prim. The newly copied one remains still. I've done this with half a dozen single-prim objects and it's worked each time. Let's see what happens after a few hours or days!
I want left one point more clear,
When you shift-drag one object, the copy is left on the original place and the original object is dragged. Also I see that llTargetOmega stopped to work after the last change applied over the 1.20 server!! Assigning to Kelly Linden since he was working on a possible fix for this.
Andrew Linden made changes - 18/Apr/08 02:56 PM
Phli Foxchase made changes - 25/Apr/08 03:33 AM
Phli Foxchase made changes - 25/Apr/08 03:33 AM
To: tallbear platypus - 11/Apr/08 05:07 AM
I tried the shift-drag workaround. A weird thing happens. It fixes the rotation problem in the ORIGINAL prim. The newly copied one remains still. I've done this with half a dozen single-prim objects and it's worked each time. Let's see what happens after a few hours or days! --------------------------------------------------- That is because when you drag a copy, you are actually dragging the original, and leaving the copy behind. So the one left in the original position, has a new UUID and behaves as if just rezzed. As an adjunct to this issue, I find some accounts running Vista 64, Nvidia cards can not see any rotations, where XP user with Nvidia can see it. DRD Also, take an object using llTargetOmega that you do not see rotate, make it physical, and it will rotate. Not suggested as a fix, not practical, just showing that this is just llTargetOmega when only client side function is used.
DRD
Sue Linden made changes - 13/Nov/08 12:12 PM
Sue Linden made changes - 13/Nov/08 04:54 PM
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Major
llTargetOmega stopped working after an upgrade to servers (first reported 1/30-1/31/07?); Revisited 2 Apr 08
One of the scripts that is not working in a long-standing object is:
default
{ llTargetOmega(<0.,0., 0.5>, (PI/6.0), 0.5); }{
state_entry()
}
This is also the script that I copied into a simple cube in the same region (Scamp) and parcel, and which worked immediately as expected. Have tried all the reset and "recompile" options I could think of on the non-working item, methods that have generally worked in the past to "jumpstart" items whose (non-physical) TargetOmega, client-side rotation had stopped.
Observed with the following configuration of viewer/server/hardware/region:
Second Life 1.19.1 (4) Mar 28 2008 13:54:38 (Second Life Release Candidate)
You are at 285198.8, 274194.1, 141.1 in Scamp located at sim2813.agni.lindenlab.com (216.82.19.56:13004)
Second Life Server 1.20.0.83683
CPU: Intel Pentium 4 Northwood (3049 MHz)
Memory: 1023 MB
OS Version: Microsoft Windows XP Service Pack 2 (Build 2600)
Graphics Card Vendor: ATI Technologies Inc.
Graphics Card: RADEON 9700 PRO x86/SSE2
OpenGL Version: 2.0.7058 WinXP Release
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.14128 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 109/307575 (0.0%)
Viewer Digest: ac25c6e3-27a9-1803-2a18-aa375a450beb
The region where there had been no sign of these issues was Huineng, at various locations featuring "kinetic sculptures" that rely on considerably more complex scripts featuring heavy, randomized use of the llTargetOmega function. However, the same phenom appears to have propagated to those regions within 24 hours or less. Will provide script source code to Linden representatives on request if they might help pinpoint the source of these seeming inconsistencies, but the scripts are long and for the present, at least, proprietary (written by myself). Since they also stopped in the same way an ultra simple version stopped, there would seen to be no reason to examine the much more complicated scripts, as they too were eventually stymied by what seems to be a related process.