• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: SVC-54
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Andrew Linden
Reporter: Heather Goodliffe
Votes: 49
Watchers: 12
Operations

If you were logged in you would be able to see more operations.
2. Second Life Service - SVC

llTargetOmega doesn't update unless object is interacted with by an AV

Created: 17/Mar/07 07:32 PM   Updated: 10/Apr/08 03:35 PM
Component/s: Scripts
Affects Version/s: 1.19.0 Server, 1.20.0 Server
Fix Version/s: 1.20.0 Server

Environment: SL Sim
Issue Links:
Duplicate
 
Relates
 

Linden Lab Issue ID: DEV-3895
Linden Lab Internal Branch: havok4-3


 Description  « Hide
Attempting to trigger llTargetOmega from a link message, I found that the object will not start moving until I edit and let go of the object, or I force an update by sending an llSetPos with a slight offset to it's current position.

root object script:

integer MSG_GO_NUM = 1810;
string MSG_GO = "GO";
string MSG_STOP = "STOP";

string msg = MSG_GO;

default
{
touch_start(integer total_number)
{
llMessageLinked(LINK_SET, MSG_GO_NUM, msg, NULL_KEY);

if (msg == MSG_GO)

{ msg = MSG_STOP; }

else

{ msg = MSG_GO; }

}
}

script in child prim to apply llTargetOmega to:
// STATIC
integer MSG_GO_NUM = 1810;
string MSG_GO = "GO";
string MSG_STOP = "STOP";

// GLOBAL
integer go = FALSE;
string msg = MSG_GO;

default
{
link_message(integer sender_num, integer num, string msg, key id)
// touch_start(integer num)
{
// if (sender_num == 1 && MSG_GO_NUM == num)
// {
if (msg == MSG_GO)

{ llOwnerSay("Starting"); llTargetOmega(<-1, 0, 0>, 2, 2); // add this line to make it work // llSetPos(llGetLocalPos() + <0.001, 0.0, 0.0>); msg = MSG_STOP; }

else if (msg == MSG_STOP)

{ llOwnerSay("Stoping"); llTargetOmega(<0, 0, 0>, 1, 1); // add this line to make it work // llSetPos(llGetLocalPos() - <0.001, 0.0, 0.0>); // adding this line does not help // llSetPos(llGetLocalPos()); msg = MSG_GO; }

// }
}
}

Note that the work around is to force an update by slightly adjusting the local prim position.
Without the update to the position, the target omega will not show on the client until an AV interacts with it by "editing" it and then letting it go.



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Lex Neva added a comment - 18/Mar/07 09:00 AM
I HATE this bug.

Another way to force an update is to call llSetText().


FaceAfkh Malaprop added a comment - 07/May/07 01:56 PM
I did some testing on this when working with changing targetomega on an avatar attachment back in Jan 2006 (long standing bug :/). I guess it's a wider child-prim issue rather than just an attachment issue. Anyway, in case it's useful as a simple test case, here's what I found:

------------------------------
float rate = 0.0;
default
{
touch_start(integer total_number)

{ rate += 2.5; if (rate > 10.0) rate = 0.0; llOwnerSay("rate = " + (string) rate); llTargetOmega(<0,0,1>, rate, 0.1); }

}
------------------------------

I put this script in a prim and tested it rezzed on the ground, where it works as expected - touching it cycles the rate from spin from stopped to fast in steps (0.0, 2.5. 5.0, 7.5, 10.0 -> 0.0, etc), then back to stopped.

  • When attached to an avatar, beginning with the stopped state, touching it reports the rate increase to the owner, but the speed doesn't change.
  • When attached to an avatar, beginning with an already-spinning state, it rezzes spinning at the start rate, but touching it does not change the rate (reports continue as normal). However, when the rate cycles around to 0.0, it does stop. Further touches have no visible effect (though continue to report rate changes).
  • As reported, just right clicking on the prim while attached to the avatar makes everything work as it should until the prim is detached from the avatar. Note that you don't need to edit it, merely select it.

I've not yet checked to see if the sim is sending updates as needed (probably try SLProxy).


Beezle Warburton added a comment - 01/Jul/07 01:06 AM
Possibly related?

Andrew Linden added a comment - 30/Jul/07 11:46 AM
I assigned this bug to me. This looks like a simulator "interest list" bug and I suspect I've already fixed it in one of our internal code branches.

Bloodsong Termagant added a comment - 19/Aug/07 08:40 AM
i was asked to review my experimental results in issue MISC-1099
https://jira.secondlife.com/browse/MISC-199

as of 1.18.1 (2) Aug 3 2007 (tested Aug 19 2007) these are the new results:

test 1 - unlinked prim: rotation starts and stops as expected

test 2 - linked as child before script applied: rotation starts. does not stop.

test 3 - linked as root before script applied: rotation starts and stops as expected.

test 4- linked as child AFTER script applied: rotation does not start.

test 5- linked as root AFTER script applied: rotation starts and stops as expected.

test 1 a – test 1 worn: object will not start rotation (until dropped)

test 2 a – test 2 worn: object does not stop rotation

test 3a – test 3 worn: does not start rotation until dropped.

test 4a – test 4 worn: object starts spinning upon being worn. does not stop, even when dropped.

test 5a – test 5 worn: object will not start/stop rotation until dropped.

conclusion: well, something got fixed, because prior to this child objects WOULD start and stop spinning IF the script were dropped in when they were not linked. (thought not if they were linked first.) now child objects are borked both ways. which is more consistent, at least!


Bloodsong Termagant added a comment - 19/Aug/07 08:41 AM
gah, i forgot to mention...

my test script IS using llSetText to attempt to force viewer updates. these are not working.


mathieu basiat added a comment - 27/Aug/07 02:59 AM
I have a similar issue with linked prims and llTargetOmega, but these will actually start to slow down or even stop as i am watching them. Touching them or editing them will cause them to act as expected...this started 3 or 4 months ago.

Zen Zeddmore added a comment - 23/Sep/07 09:09 AM
TargetOmega Has not been working at all on my system for a couple of months. Neither in a single prim nor linked prims, nor with a touch_start event to triger it.
I wonder if I might have done this to myself by messing with debug settings (please tell me how to undo.)
I have verified that it works for Other Peoples systems. I created a targetOmega scripted object and set it to run. For the other person it ran fine, but for me nada.

eren padar added a comment - 04/Oct/07 04:57 PM
This is a verified CURRENT bug, and easily verifyable:

default
{
state_entry()

{ llTargetOmega(<0.0, 0.0, 1.0>, PI, 1.0); }

touch_start(integer total_number)

{ llTargetOmega(<0.0, 0.0, -1.0>, PI, 1.0); // reverses the direction llSleep(3); llResetScript(); }

}

Attach the prim to an avatar. Touch it. Detach the prim and wear it again. Sometimes it works, sometimes it doesn't. llTargetOmega is borked... and it's a recent bug development. Apparently from the above posts, it's a new manifestation of a prior bug that seems to have not been properly corrected.


Debbie Trilling added a comment - 08/Oct/07 09:52 AM
Can confirm that this is still the case.

Simple on/off swtich in a Control Panel communicates by llMessageLinked to stop/start llTargetOmega within a child prim.

A llSetText, added in an attempt to force an update, confirms that the instructions are being properly received by the child prim.

A touch to start the rotation works fine and text shows "Rotation On".

However, when a subsequent touch is made in an attempt to stop the rotation, the child-prim continues to rotate. The text shows "Rotation Off".

However, significantly, when showing "Rotation off", if you now log off and back in again, the prim is correctly not rotating; this log on/off presumably forcing the update.


kaylan draken added a comment - 15/Oct/07 11:56 AM
i used this script and the bug is still there ((
I Hope they solve it soon.

link_message(integer sender_num, integer num, string str, key id)

{ llSay(0, str); //for test only if (str=="Rotate Off") { llTargetOmega(<0,0,0.1>,0 , 0); }

if (str=="Rotate On")
{
llTargetOmega(<0,0,0.1>,-1.25*PI,1.0);
}


Andrew Linden added a comment - 15/Oct/07 01:29 PM
The repro recipe above is fixed in Havok4 as far as I can tell.

The original recipe also breaks in Havok4, I was able to witness it broken today. I'm going to fix this in Havok4 this week and see how hard it would be to backport a fix for the original problem to the main codebase. It if is easy and clear I'll do it, otherwise the fix for this would roll out when Havok4 does (a month? two? I'm not sure).


Andrew Linden added a comment - 16/Oct/07 09:12 AM
I just checked in a fix for this in the Havok4 project. I'm looking into whether it can be back ported.

Andrew Linden added a comment - 22/Oct/07 11:42 AM
I just checked in the fix for Havok4, for real this time. I also checked in a fix in our main 'maintenance' branch. Dunno when that will trickle into the main released codebase, but it is on its way.

Dedric Mauriac added a comment - 29/Nov/07 09:07 PM
Oh my god. I just confirmed that your fix works on the beta grid. I've been having this problem for over a year now.

Ilana Debevec added a comment - 11/Dec/07 08:58 PM
Almost 2 months since this was 'fixed internally' and it's STILL not to the main grid? Is this anyway to run a railroad??!?

Coyote Pace added a comment - 17/Dec/07 09:22 AM
I just ran into this for the first time today – the bug is still present at this date, for both SL 1.18.5.3 and Windlight FL 1.18.5.75173 and SL Release Candidate 1.8.6 (RC1). When the spinning child prim is stuck (not rotating when it SHOULD be), just right-clicking on it is enough to get it moving. But once stopped again (via link messaging, as above) it will again refuse to start normally with llTargetOmega.

Torley Linden added a comment - 21/Dec/07 12:17 PM
@Ilana and Coyote: This fix is on the Havok4 Beta Grid, not the "main grid" yet. Eventually, it will be, and I understand how eager you are. For more news on our Havok4 Beta, please see:

» http://blog.secondlife.com/category/beta-test-grid/


Ilana Debevec added a comment - 24/Dec/07 01:43 PM
@Torley -

I'm well aware it's on the Havok4 Beta grid and that's the problem.

back on 22/Oct, Andrew Linden said "I just checked in the fix for Havok4, for real this time. I also checked in a fix in our main 'maintenance' branch. Dunno when that will trickle into the main released codebase, but it is on its way"

that was TWO MONTHS AGO. TWO MONTHS for a fix, that apparently is good enough for the main branch code, to be implemented.

TWO MONTHS!?!?!?!

Give me a break hun, I spend hours dinking with scripts to get them to behave because of this and the fix is lounging somewhere?

TWO MONTHS????

Not TWO MONTHS to fix, but FIXED and still not implemented after TWO MONTHS????

Why?


Andrew Linden added a comment - 27/Dec/07 08:19 AM
Yes, I had commited my fixes into the maintenance-3 branch which was merged into the release codebase a while ago. I just checked a recent release sandbox and found the code snippet I had added which should have fixed the problem, which I had tested myself, and which had passed QA under the internal item DEV-3895.

So... I don't know why this would still be broken today. Ilana, you're welcome to re-open this issue. I'll ask Dan to doublecheck DEV-3895 and re-open that the bug still manifests.


Ilana Debevec added a comment - 29/Dec/07 09:37 PM - edited
@Andrew -

Well I just checked one of our 'devices' that had the 'set text hack' to make them work.
Took out the hack and they quit working properly.

If you contact me in world I can show you/give you code/etc.. for the problem..

Now, here's a funny tidbit to add to this...

I copied our device with the hack in it, took them out for 'clean' code and tried it.. it worked.
However, when I took the device to inventory and re-rezzed it, it failed. This does not happen
with the 'hack' in the code.


Ilana Debevec added a comment - 10/Jan/08 03:21 PM
@Andrew

did you find something that would give you a lead? I'm still waiting if you want to see a broken example..


Talarus Luan added a comment - 17/Jan/08 03:01 PM
OK, it SEEMS to be better now, though at times in child prims, it still will not stop.

In addition, if you llSetRot() after turning off llTargetOmega, be sure to set it to a different rotation first, then to the correct rotation, because if it is at the correct rotation already, then no update will be sent to the viewer, and the object/prim will still be in whatever rotation is was on the screen when the spin was stopped. Remember that llTargetOmega does NOT change the rotation of the object/prim as far as the SCRIPT / SIM is concerned; it is still at the same rotation it always was, whether it is spinning or not.


Talarus Luan added a comment - 01/Feb/08 07:07 PM
Gads. Not again.

OK, with the new 1.19 server code update (on Havok 1 sims), this is now BROKEN again. Child prims will NOT stop spinning no matter what I do.

PLEASE fix this and LEAVE it fixed. Put COPIOUS amounts of "TOUCH THIS CODE AND THE SERVER WILL IMPLODE" comments around the code to keep people from re-breaking it.


Scotti Xeno added a comment - 01/Feb/08 10:42 PM
We're running Havok4 Beta Server 1.18.6.78103 here and I see this problem on an object of mine that uses llTargetOmega right now. the llSetText work around fixes it on our server.

tenebrous pau added a comment - 03/Feb/08 02:29 AM
Does anyone know a work around for when you're using llTargetOmega in child prims? The llSetText frig doesn't work in child prims of a linked set.

Ilana Debevec added a comment - 03/Feb/08 02:07 PM
@Andrew, it's been a month now that I can demonstrate both a clumsy workaround and a broken version of this at any time you're interested to see that IT ISN"T FIXED!

Kenbro Utu added a comment - 03/Feb/08 04:13 PM
I use a swinging script that utilizes llTargetOmega. I was able to restore it to working order with the llSetText "fix" but this is not an acceptable resolution as it causes an obvious jerking motion in an otherwise extremely smooth swinging effect. My script is used in the root. I too would love to see this resolved as an alternative to replacing all with a dubious fix. I have only had this problem since the 1.19 update also.

Coyote Pace added a comment - 04/Feb/08 11:43 AM
@tenebrous - in case someone else wonders the same thing: a workaround for a rotating child prim is to move it just a hair in on local Z axis, or whatever vector is perpendicular to the plane of rotation, immediately after starting the llTargetOmega. That seems to set it off. (A hair == 0.005m in my code, but that's probably overkill.) Then I move it back when the llTargetOmega turns off.

But it's possible that just moving it a bit and then immediately back again, upon start of spin, might work too – I never checked.


Talarus Luan added a comment - 04/Feb/08 08:04 PM
@Coyote: that "workaround" rarely works. I have never been able to get either llSetText, llSet(Local)Pos, or llSetRot to work as a workaround to this bug. It may work for a few people, but the point of the JIRA is to get a FIX that works all the time for everyone.

Coyote Pace added a comment - 05/Feb/08 08:41 AM
@Talarus Luan - I am well aware of the point of the JIRA. Thanks for the reminder, though.

Harleen Gretzky added a comment - 06/Feb/08 07:32 PM
The workaround works as long as you change the text in llSetText every time the llTargetOmega is changed.

Andrew Linden added a comment - 07/Feb/08 09:21 AM
A fix for this has been rolled out to SL proper, and the current (undeployed) state of the Havok4 preview has fixed "all known update problems with TargetOmega". So, I'm going to mark this as "fix pending".

rudolf cleanslate added a comment - 08/Feb/08 11:36 AM
Andrew, everything works again as advertised. For me, its a wrap !

Andrew Linden added a comment - 08/Feb/08 11:57 AM
From what I understand, there is still a broken mode for llTargetOmega() state updates in the current Havok4 deploy, and there is a fix for it ready for the next update, however the details of how it was fixed is different from the current Havok1 1.19.0 simulator. Therefore, this should remain in "fix pending" until we're sure that it is fixed in Havok4, which will eventually replace Havok1 everywhere. Someday.... No really! Maybe even this year.

Scalar Tardis added a comment - 10/Feb/08 06:14 AM
I've run into the same problem tonight, where I still have to select the object for llTartgetOmega to update, even after the DEV-8718 fix mentioned in the Feb 7, 2008 blog post.

Here's a solution I have come up with, that appears to have no side effects. Stop all motion and immediately apply it again with the direction you want, with no sleep between commands:

llTargetOmega(<0,0,0>,0,0);
llTargetOmega(<-1,0,0>,2,0.2);

This works properly on my freestanding nonphysical control panel linkset, though I've not tested it with a worn linkset.

Tested under the latest Havok4 Beta Server 1.19.0.79349 and Second Life Server 1.19.0.79368

Code for my control panel indicator, that updates its rotation speed when sent a link message:

float numpow;
default
{
link_message(integer sender_num, integer num, string str, key id)
{
// Is the linkmessage a command for this object?
if ( str == "SetXRotationSpeed")
if (num == 0)

{ // Stop all motion and hide indicator object llSetAlpha(.05, ALL_SIDES); llTargetOmega(<0,0,0>,0,0); }

else

{ // Show indicator and update rotation speed numpow = (float)num/5; llSetAlpha(1.0, ALL_SIDES); // Solution to llTargetOmega bug: llTargetOmega(<0,0,0>,0,0); llTargetOmega(<-1,0,0>,numpow,.2); }

}
}


Bryndyn Burton added a comment - 03/Apr/08 06:16 AM - edited
I'm sorry to say that this problem has still not been fixed, even in the latest server release (1.20.0.83892) and viewer release (1.19.1 (4)). I have a complex dance machine product (non-physical object) that spins with llTargetOmega in ways that are controlled by a user, and through spinning, gets dancers to move with it. The spinning feature used to work in prior server releases but stopped at some point during server 1.19 (don't know exactly when, it was reported to me after the fact by some of my customers). Apparently a fix was rolled out by LL and installed, because it did begin to work again. However, it failed to function properly in Havok4 beta sims. Now with the latest release, it fails to function properly everywhere.

I have tried Scalar Tardis' solution above, and it does not work for me The only way I can get llTargetOmega to update the visible rotation is to interact with the object (i.e., get a pie menu, escape).


Grim Bracken added a comment - 03/Apr/08 03:12 PM - edited
It's baaaaack...

Second Life 1.19.1 (4) Apr 2 2008 11:59:37 (Second Life Release)

You are at X, Y, Z in Sasha located at sim4244.agni.lindenlab.com (63.210.157.148:12035)
Second Life Server 1.20.0.83892


Ubit Umarov added a comment - 04/Apr/08 10:17 PM
My script can stop rotation, but then it can't make it rotate again, no matter what i do. Sugested hacks, aren't a nice solution, and in fact don't seem to work in my case. All worked fine not long ago, before recent server and clients updates.
current server: Second Life Server 1.20.0.83892

Azadine Umarov added a comment - 08/Apr/08 10:01 PM
Current status: After getting everything back to working in Huineng and Scamp I find that all llTargetOmega scripts in Huineng had stopped entirely. The drag-copy workaround that I documented under SVC-1461 continues to work to reactivate them.

Oddly enough, objects in Scamp that had spontaenously returned to normal function are now again dormant. However, their clones made after the 1.20 server roll-out (Second Life Server 1.20.0.83892) continue to rotate away as they have since I reactivated them. Same cannot be said for items drag-copied in Huineng, however. Both functioning and non-functioning items left as is in Scamp.

Current System details:

Second Life 1.19.1 (4) Mar 28 2008 13:54:38 (Second Life Release Candidate)

You are at 285192.9, 274195.6, 141.1 in Scamp located at sim2512.agni.lindenlab.com (216.82.18.9:13005)
Second Life Server 1.20.0.83892

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
OpenGL Version: 2.1.7412 Release
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.14287 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 19/41404 (0.0%)
Viewer Digest: ac25c6e3-27a9-1803-2a18-aa375a450beb


Azadine Umarov added a comment - 08/Apr/08 10:08 PM
Please forgive the redundacy – details copied from SVC-1461:

Azadine Umarov - 02/Apr/08 07:20 AM - edited
Unsure whether it's a server or viewer bug at this point, but I notice that very simple Z-axis llTargetOmega scripts seem to have have become non-functional immediately after the update to Second Life Server 1.20.0.83683. However, the repro is problematic, as using an identical script on a standard cube in the same region DID have the expected behavior. Also, fairly complex scripts that rely heavily on the llTargetOmega function in a different region seem to have suffered no ill effect and may even be running more efficiently since the update to the Server software. (I spoke too soon on this. The same bug propagated to Huineng within 24 hours of this report, and the same workaround detailed below managed to address it, for the time being, at least.)

One of the scripts that is not working in a long-standing object is:

default
{
state_entry()

{ llTargetOmega(<0.,0., 0.5>, (PI/6.0), 0.5); }

}

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.

Azadine Umarov - 02/Apr/08 07:20 AM - edited

Unsure whether it's a server or viewer bug at this point, but I notice that very simple Z-axis llTargetOmega scripts seem to have have become non-functional immediately after the update to Second Life Server 1.20.0.83683.

However, the repro is problematic, as using an identical script on a standard cube in the same region DID have the expected behavior. Also, fairly complex scripts that rely heavily on the llTargetOmega function in a different region seem to have suffered no ill effect and may even be running more efficiently since the update to the Server software. (I spoke too soon on this. The same bug propagated to Huineng within 24 hours of this report, and the same workaround detailed below managed to address it, for the time being, at least.) One of the scripts that is not working in a long-standing object is:

default
{
state_entry()

{ llTargetOmega(<0.,0., 0.5>, (PI/6.0), 0.5); }

}

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.

Azadine Umarov - 02/Apr/08 07:52 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 - 02/Apr/08 07:52 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 - 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 - 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 - 06/Apr/08 09:01 PM - edited
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 SVC-1910 a region restart may be sufficient to correct the problem in affected items. So far, none of the items restarted have stopped rotation in any way unrelated to the intended actions expressed in their scripts.

Azadine Umarov - 06/Apr/08 09:01 PM - edited 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 SVC-1910 a region restart may be sufficient to correct the problem in affected items. So far, none of the items restarted have stopped rotation in any way unrelated to the intended actions expressed in their scripts.

Azadine Umarov - 08/Apr/08 09:23 PM
While I agree that there is overlap between this issue and SVC-1910, that issue has become so full of confusion and complaint as to be nearly unreadable. That issue has also morphed to include complaints about the general class of "rotation scripts" (whatever those might be). As that issue is too vague to be useful and contains precious little in the way of solid repro information of description of any specific bug, I'm respectfully reopening this issue in its present form. I concede, however, that what is now reported here might not be the same as what was originally described by IBME Swindlehurst in the original report.


Andrew Linden added a comment - 10/Apr/08 03:35 PM
This bug is fixed. I cannot reproduce it using the initial repro recipe script at the top. This bug, as described, does not relate to other llTargetOmega bugs.

Incidentlally, the reason llTargetOmega is such a buggy feature is that TargetOmega+static_objects is an egregious HACK to how the code is supposed to work so there is a lot of special-case code sprinkled about that tries to catch and handle the TargetOmega+static_objects weirdness.

Despite its HACK implementation, people really do love it, and don't mind the fact that the collidable shape of the objects in question don't actually rotate.