|
|
|
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:
------------------------------ } 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.
I've not yet checked to see if the sim is sending updates as needed (probably try SLProxy). 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.
i was asked to review my experimental results in issue
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! gah, i forgot to mention...
my test script IS using llSetText to attempt to force viewer updates. these are not working. 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.
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. This is a verified CURRENT bug, and easily verifyable:
default 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. 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. 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") 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). I just checked in a fix for this in the Havok4 project. I'm looking into whether it can be back ported.
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.
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.
Almost 2 months since this was 'fixed internally' and it's STILL not to the main grid? Is this anyway to run a railroad??!?
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.
@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:
@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? 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. @Andrew -
Well I just checked one of our 'devices' that had the 'set text hack' to make them work. 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. @Andrew
did you find something that would give you a lead? I'm still waiting if you want to see a broken example.. 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. 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. 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.
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.
@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!
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.
@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. @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.
@Talarus Luan - I am well aware of the point of the JIRA. Thanks for the reminder, though.
The workaround works as long as you change the text in llSetText every time the llTargetOmega is changed.
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".
Andrew, everything works again as advertised. For me, its a wrap !
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.
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); 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; 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); } } 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 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) 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 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
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) CPU: Intel Pentium 4 Northwood (3049 MHz) Please forgive the redundacy – details copied from
Azadine Umarov - 02/Apr/08 07:20 AM - edited One of the scripts that is not working in a long-standing object is: default } 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) CPU: Intel Pentium 4 Northwood (3049 MHz) 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 } 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: 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 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 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 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 Azadine Umarov - 08/Apr/08 09:23 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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
llTargetOmega doesn't update unless object is interacted with by an AV
Another way to force an update is to call llSetText().