|
|
|
|
|
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). 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 { 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. 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") { llTargetOmega(<0,0,0.1>,-1.25*PI,1.0); } 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:
» http://blog.secondlife.com/category/beta-test-grid/ @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. 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. @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); 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); & | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Another way to force an update is to call llSetText().