|
History
| Log In
|
|
|
|
|
|
[
Permlink
| « Hide
]
wildefire walcott - 08/Jun/08 10:39 PM
There are other symptoms of recent physics weirdness: You can see this in action on the steps of my house in Bay City: Docklands. Last night my partner and a friend and I were all standing on the front steps talking, when both of them aksed why the house was moving. I noticed what they were talking about soon enough; the picture was jittering around as if a distant herd of elephants was running past. At first I wondered if there were some errant rez faux scripts in the house, but I checked all the nearby linksets to find them empty. I then found that if I watched closely, the house was not moving relative to the sidewalk or adjacent buildings- it was I who was moving, and the camera was just following me, giving me the impression that everything else was moving. It felt like collision jitter, and this confused me because they were just regular-ass prim-per-stair steps. No sculpties, phantom or otherwise. SL was just having a hard time making our avatars stand motionless on the staircase.
I've noticed the same thing. It seems that collision is triggered with a sometimes huge delay. A surf track we created is fubar since the 1.22.2 rollout. Checkpoints sometimes does not register a collision, and ramps that adds a small speed boost, most of the time doens't activate, and when they do, it might give you a boost seconds after your actually over the ramp.
Please fix this sooner rather than later It's been like this for a while, now it's to the point of unbearable of course, but there has been a problem with the collision system for months. =/
I've noticed the rocochet effect from prims as well recently, but wasn't sure what was causing it. Bullets scripted with
collision_start(integer collide) { llDie(); } should die on impact. Over the past few days I have seen them not only bounce back, but continue going for a distance of 10m or more. Ironically, I *have* had these bullets hit me and trigger collsion events on scripted items I was wearing. I have also seen them go through prims without either bouncing back or dying, giving me repeated messages that they had entered restricted parcels despite the fact that I was firing at a half-meter thick target sitting in front of another half-meter thick wall. These were 2.5m long spherical bullets travelling 115 m/s, which have never behaved like this under normal conditions. Edited to 1.22.2 - It stated that it was unreleased, but I guess the Jira hasn' been updated
I think this has something to do with the Havoc 4 engine was aware there were going to be problems with the changeover. Won't be surprised if this is a side effect of trying to reduce griefing by making AV's harder to target.
Increased ricochet may be an isolated issue if I recall there's a way to adjust the ricochet in the physics engine. Should be noted that "move to target" of a physical object still reliably produces collisions with AV's. Volume detect is also functioning fine. Appreciate the heads up .Will be conducting some further tests myself shortly as I'm not sure if it's affecting "collision", "collision start" and "collision end" equally,scripting system may be registering things physics engine isn't processing properly . Not sure if ricochet is affecting all material types equally will have to look into this as well. What I'm seeing is a big delay before collision_start is triggered on object (vehicle) to object collision with volume detect. I still belive it's related since the same delay would cause bullets not to die on impact, and things passing through objects, because the engine doesn't react to a collison in time
Just to clarify, these bullets behaved perfectly fine in Havok4 up until now, so I don't believe that it's a general H4 issue, but specific to this server release.
Agree. I was using our track just before the restart, and when I tp'ed back after the restart, everything was broken
A Related issue needs your vote!!!
There is a similar, if not identical, report open at http://jira.secondlife.com/browse/VWR-7724 Though voting here is > 60 as 6/12/2008, the related/identical one has just 2. Vote there as well. It doubles the likelihood of them assigning this fun wrecker. This happens with all guns ingame. Every single gun i've fired at an avatar since 1.22.2 has had this problem. It is now present in 1.22.3. Needless to say, SL is acting up like a troubled child on crack
Just getting in behind my peoples here, this is definitely an issue with all collision based weaponry in SL post 1.22.2.
/me does the B-Boy stance behind Suz who is behind all the people that beat her to this issue. It is teh sux.
We need resolve this as Suzanna has, as usual, clearly alerted us to this problem then it is a issue requiring some serious attention and priority.
i have noticeds that its not just cubes. i use cylinders for my bullet objects. no matter what size i use or what speed i fire them at they all seem to pass through the object. however i have found a way around this but it its still a horrid pain to work with.
from what i have gathered there are 2 spots that you can infact trigger a collision with the agents. just left of agent such at an elbow in the default stand animation where the hand is on the hip and just top-right of agent. but yes i do agree we need to have this fixed. this surely breaks all projectile based products in SL. Yeah, it shouldn't just be those points that return collisions, there *should* (ie expected and observed behavior seen thus far in H1 and H4 up until now) be a rectangular "hitbox" roughly half a meter wide and as tall as the avatar's shape. This holds true (under past normal behavior) even if the avatar is in an animation. For instance, if an avatar were lying in a "prone" animation, a bullet will still result in a collision if you fire slightly below their nametag, which you will notice is still located where it would normally be.
The consistent delay on execution of collision events is just as serious as the fact that they pass right through objects. I don't know if these two issues are related but both are causing major issues for many products, especially weapons and shields.
An interesting thing to note is that bullets will hit avatars more consistently from some angles than from others, and hits are also more frequent if the avatars are moving. Brief testing on the preview grid indicates that this issue is still present in 1.22.4.90215 as well. I can confirm the "aim to the left of the avi's right elbow and hit them" report.
Still broken in server version 1.23 on the preview grid.
It sure would be nice to know where this month-old critical pervasive high-impact physics bug stands without having to camp out in somebody's office hours. We do weapons QA, testing and evaluation, and it's nearly impossible to do any productive work until this is resolved.
Has the defect been identified? I'm working on this bug this week (2008.07.07). I've already reverted a few things that I thought might be related and failed to find the problem. So now I'm regressing into older versions until I can narrow in on the culprit changes.
Thanks, Andrew, I appreciate the update, and recognize that working inside Havok is non-trivial. It's good to know this is not languishing.
Not sure if it helps, but I've noticed that bullets with 'blood splatter triggers' on collision will often register a blood splatter 50-60 meters behind an avatar without having hit ground or another prim...in other words, the 'bullet prim' SEEMS to be recognizing that the collision-event happens, but very, very late. The avatar, however, still fails to recognize that a collision even occurred.
My testing in this regard is by no means scientific (was a result of 'try shooting me and seeing how bad things are still broken while on a completely empty sim), but I figured I'd throw in the info anyway. hmmmm, that would be consistent with other behavior such as bullets bouncing off of objects or going through multiple objects without dying (despite being scripted solely to die on impact), in that it seems as though there is some sort of problem or delay in the triggering of the collision_start() event.
Is it possible that the reason that the collision is not being passed on to the avatar is due to the avatar's key not being passed in the physics engine's calculations (ie it belatedly sees that it hit something, but doesn't register a key for the collision)? Or could it even be the reverse, that the collision detection is just fine, but gets delayed because the database is taking too long to return the key of the collided object? I mention the second possibility only because it offers another possible place for the bug to be lurking that hasn't yet been explored. I might try scripting a bullet to llOwnerSay() the name of the object it hits before dying, to see what comes up. Not sure if this is helpful, but it may be related. When running llGetAgentInfo, there is a significant delay on returning the CORRECT value for AGENT_IN_AIR. In other words, it returns FALSE shortly after jumping, being pushed upward, or otherwise leaving the ground, as if it hasn't yet realized you're in the air. Additionally, the "ground friction" seems to apply during this time, even while in the air. This is happening in a script which worked correctly some time before this bug appeared. If it is indeed related, it suggests this is deeper than just the collision event code and is a delay in other physics/script interaction too.
Julia-- I wonder if that's related to the significant delay we're seeing in flying recognizing a change in command state...the reason that lately one tends to overshoot a desired altitude; for example you stop commanding "fly down" but continue to descend for somewhat less than a second, where before you would halt immediately.
I wish I knew more about the internals of this stuff, even at a at broad-brush level. It would really enhance my contribution on the "given enough eyeballs, all bugs are shallow" effort. I have a fix for this bug in my code sandbox. Turns out there were two problems...
(1) Indeed some LSL collision events are not handled in a timely manner. I've tightened up the handling rate, particularly for the *first* collision event after a period of none. (2) Some anti-avatar-entrapment code is preventing the bullets from colliding sometimes, especially when there is a somewhat rapid shot rate. The flying/stop response time problems, and llGetAgentInfo delays are unrelated to the above bugs, but for all I know the llGetAgentInfo() could be similar to (1). Great news Andrew - Will be great when it hit the grid!
Excellent news and thank you for narrowing this down so quickly.
From the sound of it these were changes made to fix much more minor issues with physics, and in the process killed physics entirely. Will your new fixes scrub all traces of this and put us back at the proper, expected behavior from before those changes went live? My only concern is that, like the original sound throttling code, we may see some unexpected behavior once this goes into heavy real-world use which would put us right back where we are now, if those older changes aren't fully undone. Well intentioned as these features are, I would just prefer not to see any experimental tinkering while we're having shotgun server code updates with < 5 day testing windows on the preview grid. Julia, I think "killed physics entirely" is not an accurate assessment of the situation. I'm confused by your questions so I offer the following alternate questions/answers in an effort to provide some of the information that I think you seek:
(1) Q: Are you fixing bugs or adding features? A: Fixing bugs. Changes will be made to pre-existing "features". In particular, when the LSL collision_start() and similar events are handled, and also how some anti-avatar-entrapment features kick in. (2) Q: Will these changes be deployed too fast? A: No. These will go into the normal testing and deploy pipeline. I wouldn't expect these changes to be deployed for about two weeks or more. (3) Q: Are you worried that these changes are in the middle of fragile code and will introduce new unforseen and horrible bugs? A: No. The collision_start() changes are very safe and correct. The other stuff is definitely an improvement and if anything will prove to not have been enough -- I've fixed the popgun recipe above, however it may be that larger bursts of bullets may still have problems (that is, a gun that shoots more bullets per second for longer periods may still eventually stop colliding -- the rate/duration would have to be accurate hits against the avatar on the order of 12 bullets/sec for 1.5 seconds). Congratulations on the fix, Andrew, and thanks. We'll beat it up when it gets to the beta grid.
I have experienced same issue with some monsters that use collision detection to accumalate damage.
I cAn stand there and get no damage from attacks? unless its a violant or hard collision. It makes my parcel less effective with damage all screwed up As this issue is technically not about the script collision event but about collisions with avatars, I've created and linked an issue about the lag in the script collision event.
See SVC-2698 Do we have any update on when the fix for this issue will be applied? I know that the difficulties with implementing 1.23 have slowed down things a bit, but I have a long-list people begging me for an update of when to expect the fix...
^^ I'm with Kenn on wondering when an update for the fix will be applied. Is this on the agenda for the 1.24 server release? I know it may not be on the top of the priority list due to the 1.24 server release utilizing the Mono VM, but it would be great if this is rolled out with the server upgrade if it has been thru the normal testing process without any noticeable issues. If the 1.24 server release is still slated for August 8th-10th, this would make a great addition! Any feedback would be highly appreciated Andrew. :) Thanks for addressing this promptly for all of us.
I'm hoping to get the fixes into the 1.25 release (the MONO project will be 1.24) however the relevant collection of fixes has failed the first QA pass (not this one, but two of the other bugs). I need to fix them and resubmit.
Ya know Andrew, this is a huge problem. This messes up combat in all combat sims, including safezone ones. All guns made to play in these types of RP situations are dead. There are hundreds of people missing out due to this.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Bug
Fix Pending
Critical
Serious Object-Avatar collision problems in 1.22.2 and above
