The particular case Garry reported was with a prop set to COLLISION_GROUP_PUSHAWAY against another prop set to COLLISION_GROUP_DEBRIS. The code in hl2mp gamerules returns different values for: ShouldCollide( COLLISION_GROUP_PUSHAWAY, COLLISION_GROUP_DEBRIS ); And ShouldCollide( COLLISION_GROUP_DEBRIS, COLLISION_GROUP_PUSHAWAY );
The code I posted fixes this. The picture vs. the file cabinet in cs_office is such a case. Vphysics assumes this will not occur; if it does a bunch of unintended things can happen. (In this particular case it results in a dangling pointer but there are other possible effects depending on the callstack and cached collision state at the time of the bad data coming from the game DLL. That's why it doesn't always crash or even show up as a problem.) Jay > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Sunday, May 28, 2006 7:29 PM > To: [email protected] > Subject: RE: [hlcoders] Physical Mayhem in progress - no crash! (yet) > > Yeah part of my real job is engineering support so I > understand the importance of repro steps if engineering > hasn't seen an issue. I'm a bit baffled though, given how > many people have reported it, that Valve hadn't seen it > regularly. (Does Valve have a public HL2DM stress test > server? If so, what's the IP?) > > I think you tried to answer my question, but perhaps I didn't > grasp the intracacies of the answer. What scenario does the > CHL2MPRules::ShouldCollide change actually fix? If it's as > simple as one prop hitting another, why doesn't it always break? > > Also, earlier when I reported the bouncing still occuring I > had only applied the fix server-side. I've since applied it > client-side as well and for about 20 minutes and counting > I've not seen any physics issues. Too early to call it dead, > but that's promising. > > -bk > > At 2006/05/28 06:34 PM, Jay Stelly wrote: > >Garry sent in a deterministic way to cause some bad physics behavior. > >Because of his repro case I was able to fix a bug with the code I > >posted below. Personally, I have never been able to reproduce the > >behavior you've described. I believe Adrian has seen the > behavior in > >HL2DM at some point, but noone at Valve has a set of steps for > >recreating the behavior as far as I know. Also, I've looked at the > >minidumps you've posted and they don't help diagnose the problem. > >Garry's bug had the same characteristic - looking at the > state of the > >code after the bug had occurred was not helpful. Being able to > >recreate the behavior in a controlled way is the shortest path to > >fixing the problem. Sometimes bugs are easy and you can guess the > >cause based on the results, but often they are not. In > those cases it > >is really desirable to go back through the steps that caused the bug > >and analyze what is happening in the code. If you can't do > that then debugging is much more difficult. > > > >More info on what was happening here: > >In this case the problem is that the game DLL is not being > consistent > >in how it reports collision rules to vphysics. > ShouldCollide(a,b) is > >supposed to return the same value no matter how many times > it is called > >until you call CollisionRulesChanged() for a or b. Also > >ShouldCollide(a,b) must always return the same result as > >ShouldCollide(b,a). Vphysics uses this procedure call instead of > >storing some kind of matrix of possible collisions. If this > function > >does not fulfill it's part of the contract it can cause vphysics to > >fail (including crashing). > > > >So given that the problem has similar symptoms to Garry's, it makes > >sense for you to instrument your code to test for cases of > the same bug. > >The simplest way to do that would be to wrap ShouldCollide() in > >src/dlls/physics.cpp: > > > >int CCollisionEvent::ShouldCollide( IPhysicsObject *pObj0, > >IPhysicsObject *pObj1, void *pGameData0, void *pGameData1 ) { > > int x0 = ShouldCollide_Default(pObj0, pObj1, pGameData0, > >pGameData1); > > int x1 = ShouldCollide_Default(pObj1, pObj0, pGameData1, > >pGameData0); > > if ( x0 != x1 ) > > { > > Assert(x0==x1); // break here and step > through the code > >to see what's wrong > > ShouldCollide_Default(pObj0, pObj1, pGameData0, > >pGameData1); > > ShouldCollide_Default(pObj1, pObj0, pGameData1, > >pGameData0); > > } > > return x0; > >} > > > >int CCollisionEvent::ShouldCollide_Default( IPhysicsObject *pObj0, > >IPhysicsObject *pObj1, void *pGameData0, void *pGameData1 ) // .... > > > >If you hit that assert, you know you've got the same bug and > you should > >be able to step through the code and fix it trivially. I'll > try that > >as well with dm_steamlab in HL2DM since you are still reporting some > >kind of problem. If you do hit the assert but don't know how to fix > >it, send me the steps to recreate the assert and I'm sure > I'll be able > >to fix it if I can make the assert happen. > > > >Jay > > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On Behalf Of > >> [EMAIL PROTECTED] > >> Sent: Sunday, May 28, 2006 2:18 PM > >> To: [email protected] > >> Subject: RE: [hlcoders] Physical Mayhem in progress - no > crash! (yet) > >> > >> This is certainly a promising step - thanks all. > >> > >> However, can you explain what exactly this fixes? Is this > supposed > >> to fix the classic Physical Mayhem Bug, or does this fix > something to > >> do with scripts/propdata_cs.txt, which is presumably irrelevant to > >> the generic HL2DM Physical Mayhem Bug? Also does "I was able to > >> repro the bug with those changes" mean Valve has -only- > repro'd the > >> bug with those changes? Ie, has Valve never repro'd the > bug in plain > >> HL2DM? > >> > >> I applied the patch and loaded up dm_steamlab. Within about > >> 5 minutes, Physics bugs started occurring, but > behaviorally it's not > >> the same as the classic Physical Mayhem Bug. Now items do > not fall > >> infinitely out of the world, and cpu usage is not 100% as > it normally > >> would be during the Physical Mayhem Bug. However the warping and > >> repeat-bouncing is still occurring. > >> > >> This seems to be an improvement at least, but it's not a > whole fix. > >> It's still very difficult to play while this is occurring. > I'm going > >> to leave it running on dm_steamlab to see if it crashes or if the > >> crasher aspect has gone away. > >> > >> Has anyone else tried Jay's patch? > >> > >> -bk > >> > >> At 2006/05/24 08:51 PM, Jay Stelly wrote: > >> >Ok, I was able to repro the bug with those changes. > Here's the fix: > >> > > >> >// add these lines to hl2mp_gamerules.cpp: > >> > > >> >bool CHL2MPRules::ShouldCollide( int collisionGroup0, int > >> >collisionGroup1 ) > >> >{ > >> > if ( collisionGroup0 > collisionGroup1 ) > >> > { > >> > // swap so that lowest is always first > >> > swap(collisionGroup0, collisionGroup1); > >> > } > >> > > >> > > >> >Jay > >> > > >> > > >> >> -----Original Message----- > >> >> From: [EMAIL PROTECTED] > >> >> [mailto:[EMAIL PROTECTED] On > Behalf Of Garry > >> >> Newman > >> >> Sent: Wednesday, May 24, 2006 3:14 AM > >> >> To: [email protected] > >> >> Subject: Re: [hlcoders] Physical Mayhem in progress - no > >> crash! (yet) > >> >> > >> >> Ok done it. It happens. > >> >> > >> >> I found the exact cause too. When you shoot these pictures > >> they fall > >> >> on the other physics objects.. > >> >> > >> >> http://www.garry.tv/img/cs_office_phys.jpg > >> >> > >> >> And then the physical mayhem happens. Which is weird > >> because I always > >> >> thought those pictures were clientside so they > shouldn't even be > >> >> touching the other stuff.. > >> >> > >> >> Here's the test mod > >> >> > >> >> http://www.garry.tv/img/phys_testmod.zip > >> >> > >> >> And here's the code changes (based on hl2mp mod) > >> >> > >> >> GameInterface.cpp line 493 after TheNavMesh = ... > >> >> > >> >> filesystem->MountSteamContent( 240 ); AddSearchPath( "cstrike", > >> >> filesystem->"GAME" ); > >> >> > >> >> cdll_client_int.cpp line 523 after ClientWorldFactoryInit(); > >> >> > >> >> filesystem->MountSteamContent( 240 ); AddSearchPath( "cstrike", > >> >> filesystem->"GAME" ); > >> >> > >> >> props_shared.cpp line195 > >> >> > >> >> if ( !m_pKVPropData->LoadFromFile( filesystem, > >> >> "scripts/propdata_cs.txt" ) ) > >> >> > >> >> I changed the spawnpoints to use > >> info_player_counterterrorist too but > >> >> I doubt that affected it. > >> >> > >> >> > >> >> > >> >> On 5/24/06, Garry Newman <[EMAIL PROTECTED]> wrote: > >> >> > Yeah kinda. I'm based off HL2, and mounting CS:S using the > >> >> > filesystem->mount and addsearchpath (to tail) commands. > >> >> > > >> >> > I'll try it with a new mod to make sure it isn't something > >> >> that only > >> >> > happens with GMod.. > >> >> > > >> >> > On 5/23/06, Adrian Finol <[EMAIL PROTECTED]> wrote: > >> >> > > I just tried to reproduce this by following these > steps and I > >> >> > > couldn't get it to happen. > >> >> > > > >> >> > > This is what I did so let me know if I missed something: > >> >> > > > >> >> > > I changed HL2DM's GameInfo.txt to also mount the cstrike > >> >> folder so I > >> >> > > could load cs_office and all its resources. I loaded > >> >> HL2DM on msdev > >> >> > > and built that, then I added the propdata folder > and renamed > >> >> > > Cstrike's propdata.txt to cs.txt and placed it there. > >> >> > > > >> >> > > Loaded cs_office and ran around shooting rockets > >> trying to get as > >> >> > > many physics objects in motion as I could. After 5 > >> >> minutes running > >> >> > > around everything was behaving fine. > >> >> > > > >> >> > > Did I miss anything? > >> >> > > > >> >> > > > >> >> > > > >> >> > > -----Original Message----- > >> >> > > From: [EMAIL PROTECTED] > >> >> > > [mailto:[EMAIL PROTECTED] On > >> Behalf Of Garry > >> >> > > Newman > >> >> > > Sent: Tuesday, May 23, 2006 8:21 AM > >> >> > > To: [email protected] > >> >> > > Subject: Re: [hlcoders] Physical Mayhem in progress > - no crash! > >> >> > > (yet) > >> >> > > > >> >> > > Hey exactly a month later! > >> >> > > > >> >> > > Here's what I'm doing to cause the physical mayhem. > >> >> > > > >> >> > > In my mod/scripts folder I made a folder called propdata. > >> >> I copied > >> >> > > CS:S's propdata.txt to this folder and renamed in cs.txt. > >> >> > > > >> >> > > In CPropData::ParsePropDataFile I changed the > >> loadfromfile line > >> >> > > to > >> >> > > > >> >> > > if ( !m_pKVPropData->LoadFromFile( filesystem, > >> >> > > "scripts/propdata/cs.txt" ) ) > >> >> > > > >> >> > > > >> >> > > So I start my mod and go to cs_office. It's fine > for about 20 > >> >> > > seconds of shooting props then they all start > bouncing around. > >> >> > > > >> >> > > > >> >> > > I find that this has prevented it.. (props.cpp:4747) > >> >> > > > >> >> > > //LINK_ENTITY_TO_CLASS( prop_physics_multiplayer, > >> >> > > CPhysicsPropMultiplayer ); > >> >> > > > >> >> > > LINK_ENTITY_TO_CLASS( prop_physics_multiplayer, > >> >> CPhysicsProp ); > >> >> > > > >> >> > > Obviously it's going to change all > >> prop_physics_multiplayer into > >> >> > > prop_physics.. so it might not be ideal for your mod. I'm > >> >> guessing > >> >> > > that my problem is different from yours though, > >> somehow.. even if > >> >> > > the symptoms are the same. > >> >> > > > >> >> > > > >> >> > > > >> >> > > On 4/23/06, [EMAIL PROTECTED] > >> >> > > <[EMAIL PROTECTED]> wrote: > >> >> > > > The mod players were getting restless so I > couldn't wait any > >> >> > > > longer > >> >> > > for a response from Valve so I had to shut it down. > >> >> Unfortunately > >> >> > > there's no documentation on how most of that stuff is > >> supposed to > >> >> > > work, and there are frightfully few asserts in the > >> SDK. I guess > >> >> > > I'll have to do a lot of research to compare a working > >> >> vphysics.dll > >> >> > > to a broken vphysics.dll in order to pin down the > >> exact problem. > >> >> > > > > >> >> > > > At 2006/04/20 08:03 PM, Aaron Schiff wrote: > >> >> > > > >-- > >> >> > > > >[ Picked text/plain from multipart/alternative ] > >> >> > > > >USE_OBB_COLLISION_BOUNDS just says to search within > >> >> the bounding > >> >> > > > >box constructed around a physical model to detect > >> >> other objects. > >> >> > > > >It's not the matter you should be worried about. > >> >> > > > >-- > >> >> > > > > > >> >> > > > >_______________________________________________ > >> >> > > > >To unsubscribe, edit your list preferences, or view the > >> >> > > > >list > >> >> > > archives, please visit: > >> >> > > > >http://list.valvesoftware.com/mailman/listinfo/hlcoders > >> >> > > > > >> >> > > > _______________________________________________ > >> >> > > > To unsubscribe, edit your list preferences, or > view the list > >> >> > > > archives, > >> >> > > please visit: > >> >> > > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > >> >> > > > > >> >> > > > > >> >> > > > >> >> > > _______________________________________________ > >> >> > > To unsubscribe, edit your list preferences, or view > the list > >> >> > > archives, please visit: > >> >> > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > >> >> > > > >> >> > > > >> >> > > _______________________________________________ > >> >> > > To unsubscribe, edit your list preferences, or view the > >> >> list archives, please visit: > >> >> > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > >> >> > > > >> >> > > > >> >> > > >> >> > >> >> _______________________________________________ > >> >> To unsubscribe, edit your list preferences, or view the list > >> >> archives, please visit: > >> >> http://list.valvesoftware.com/mailman/listinfo/hlcoders > >> >> > >> >> > >> > > >> >_______________________________________________ > >> >To unsubscribe, edit your list preferences, or view the list > >> archives, please visit: > >> >http://list.valvesoftware.com/mailman/listinfo/hlcoders > >> > >> _______________________________________________ > >> To unsubscribe, edit your list preferences, or view the list > >> archives, please visit: > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders > >> > >> > > > >_______________________________________________ > >To unsubscribe, edit your list preferences, or view the list > archives, please visit: > >http://list.valvesoftware.com/mailman/listinfo/hlcoders > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list > archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
