|
|
|
[
Permlink
| « Hide
]
Harleen Gretzky added a comment - 09/Feb/08 08:15 PM
Maybe sometimes it is too close to another prim/object/avatar when physics is being turned back on, an error will occur if a prim/object is made physical but is within 0.1m from another prim/object/avatar or the ground.
Indeed, but when this happens the physics property turns auto-off. With this bug (even if if occours because of the object intersecate another one) you cannot turn on the physics on that object anymore, you can move it in the air (via editor), you can isolate it from the rest of the prims etc, it doesn't turn into a physic object ...never.
It does have the "hand" icon on moseover it (when the physics is enabled), apparently you can "grab" it, but it stays stuck there in place. Now i have a "cube" into my land.. at middle air with physics on and it act as a normal primitive with no physics. I had to rewrite completely the engine to get avoid of this bug (limiting the number of times i turn on/off the physics), hoping that it will have a reliable life... but this doesn't solve the problem, i just "posticipate" when it will happens again (from hours to maybe days...), it will stuck first or late (until it gets solved by LL). After limiting the amount of times i disable/enable the physics i've had the object "surives" for two days, so the problem now passed from hours to days... but it still there. Two days are not acceptable for my "business"... if it were a week or so i may wait until a proper fix, but i cannot place that thing for sale now since the customer would be annoyed to rez the object each day (it's a free roaming pet, that is supposed to roam indefinitively into your parcel).
Further update: to being able to have it working while a fix will be provided, i've managed to remove the whole enabling/disabling physics routine from my script on purpose, stabilizing the object using the force vectors... and surprise? The bug is still there! Now the obejct took a bit longer to get "stucked" but in the end it entered again into a irreversible "no-physical" state. The only part where i may enabling disabling it, is to have the object "unstuck" if he's actually intersecating another object:
if (llGetStatus(STATUS_PHYSICS) == FALSE) { llSetStatus(STATUS_PHYSICS, TRUE); } this condition would happens rarely (or it is supposed to be). Since a "simple" (no scripted) object with physical on would survive indefinitively (i had ball bouncing around for weeks...) i guess that this bug must be related to some precise conditions. I'm currently using this functions (if they may help the debugging): llMoveToTarget() The object being initialized with this properties: llSetBuoyancy(0.0); The "cube" i've left on the SIM affected by this problem, returned to have a working physics flag on it (now ticking it would let it falls on the ground normally), but it must be considered that the SIM has been restarted so the (temporary) fix may be introduced by the restart itself.
I've now left again the same script running (the one that got stuck after several hours), so i need a couple of days to check if the bug is solved... and if it is, the solution is not documented into the latest H4 release notes. Two consideration: i cannot publish (not pubblically) the script i'm using, since it is used into a commercial product, but i may write a simple one to reproduce the bug. Second, if the bug (eventually) is resolved with H4, what about H1? The product is on the market, i cannot type into the instructions: this would not work on havok1.... since everyone else is using H1 right now. Anyway... stay tuned, i'll let you know soon. It happened in less time than expected.... the object is now stuck in the air without the possibility to enable the pysyics anymore (via SLS or even manually via the editor). I can provide object coordinates if someone (LL) cares to check.
I know that some objects will have their STATUS_PHYSICS bit set FALSE in Havok1. This happens when the object causes a mini-deep-think – blocks the physics engine for a few seconds or longer but not long enough to actually crash the simulator. This is not so much a bug as a mis-bug (a feature that is actually bug-like in its behavior). However, as far as I know it does not happen on Havok4.
If you have an object that has its STATUS_PHYSICS bit set FALSE in Havok4 then that would be a real bug. The fastest way to get it fixed is to drop a copy on my profile so I can test it out. Otherwise, post detailed instructions on how to manufacture the object, and post a copy of the script here. I know the auto-off physics feature to prevent a SIM crash (i didn't known that's not happening anymore with H4 really), anyway the problem here isn't having it disabled.. but have the object physics disabled "forever" whenever the property is on or off.
I've dropped you a copy of the obejct inworld, so you can check yourself. As along the content of the script is not needed (not needed to figure that the bug exists) they would be needed to figure why this bug is occuring, to give out a full perm script then (if it's need, and if you cannot retrieve the script yourself from the asset server with "god" privileges or whatever) i've to ask who actually own the property of the script (i did the script for a third party). I cannot publish it here, indeed. PS: i've developed a second object that doesn't uses llApplyImpulse(), but just MoveToTarget() and llRotLookAt()... and it "survived" for more than 1 day now, if it doesn't get stuck i may only guess that the problem is with the llApplyImpulse() feature. I've found the "light" here... and it's not a good news for me, since this is gonna disrupt a great part of thw work did for that object. The bug appears under a particular circumstance: when you change the childs attributes of childs primitives while the physics in on. In details:
Soon after (it may be minutes... or hours) of fine running: the physical object still physical, the body parts are moving; the bug appears and the object turns into a irreversible no-physical state (physics on, but no physics). The problem seems to affect only the root primitive: if you unlink the object all the childs will fall to the ground (because of the physics) apart the root primitive. I know that this pourpose (having a moving parts) is accomplished via llSetLinkAlpha in many cases (the you link all the moving parts to the object and you need only to show em) but since it is a physical object and i have limited number of prims linkable, i cannot waste em, so i need to move the original prim. I don't know why this is happening, probably it gets "confused" by so many prim position, size and rotation issued togeter on separate childs in a short timeframe (it may be 0.5 seconds) so they get queued... anyway the obejct just stop to works in the end. Hi, since i've provided enough informations (inworld) about this bug (the title isn't anymore true, since the problem is related to moving a child prim within a physics linkset) may i have an update on this? What i'm asking, if possible isn't the resolution itself but:
I'm asking this, because i've to reply to who committed me these script. So i have to decide if we can release the script (and the product) "as is", if we must wait for the fix, or if we can tweak more the script to have it working until you resolve it. Kelly Linden is currently working on this.
This will be fixed in the next update after today's.
What was happening was a weird combination of a race condition and some generally weird behavior. The bunnies would get frozen by the RCCS (runtime collision control system), and then because of a weirdness in how shape changes happen would get stuck in a limbo state where they were frozen but not being tracked by RCCS. Which means they would never un-freeze. I've made two changes:
To be clear, that the bunnies (or any other physical object) would freeze when physics performance gets real bad is not a bug and is a feature of havok4 - that is a piece of the magic that makes havok4 more resilient. However once sim performance recovers the bunnies (or other objects) should become physical again (and in this case they were not). I would agree with the magic of Havok4.. but what about Havok1? (the bug hits H1 in the exact same way > wihout disabling the physics flag), this fix will be deploied on H1 as well? Since the products here are for the mass market and they all have H1 indeed.
Thanks for the fast resolution anyway. No, this fix will not be rolled out to havok1 for a few reaons.
1) We believe the Havok1 bug was fixed as part of the transition to havok4 (essentially that the case that caused it before just doesn't exist in havok4) I confirm the bug has been resolved with the latest H4 rollout. The "pets" are running solid from a week already. Thanks for the effort.
Thank you Vittorio for verifying and closing!
 Since Havok 4 I am having this problem randomly. Objects that are physical with llMoveTarget get permanently disabled. I think it is when a region restarts but I cannot confirm this, because the same objects running in a different region may work fine for days. My floating barrels near the Linden Calleta InfoHub work well for the most part. Its not like one barrel will stop, all of them stop and become disabled. I also had a llTargetOmega object stop spinning and become totally broken. I'm going to monitor regions more closely.
blaccard i suggest you to fill a entry for a differente bug, beside the title, this bug was very specific and related to linkset changing their shapes (moving childs) while the physics were enabled, causing the physics being disabled as property (not option) on the root. This bug has been resolved, your problem seems very different.
PS: i do have currently running different vehicles using llmovetotarget, it's not the best option to use (but the fastest and easiest), and prolem exists, sometime the object get "stuck" and you need to recovering them using a push to have em working back again. This is happening to my rides now too the physics turns off and on whenever someone gets on or off and now event though if you edit it and look it says physics enabled but it is not. seems that making a copy of it fixes it re rezzing it fixes it but this thing needs to set up and read coordinates from a note card when you rez it . It's my shroom ride again works a few days then stops. I'll drop one on you. also unchecking the physics on it and manually setting it physical again has no effect.
Hey RacerX I think your issue is different than the one from this bug. Please create (or point me to) a new / different jira if you are still having the issue you describe. Thanks.
|
|||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
Physics being disabled *permenantly* after enabling/disabling it multiple times via SLS (STATUS_PHYSICS, TRUE/FALSE)
