I left my server on dm_steamlab overnight: no crash, and no Physical Mayhem bug. (I'm still reluctant to say it's gone for good after 1 1/2 years of spending so much of my modding time on this.)
So then I reverted the fix and applied just the assert. The instant I did changelevel dm_steamlab, the assert hit. This corresponds with previous findings that dm_steamlab would always cause the Physical Mayhem bug. The assert involved a prop_physics and a prop_physics_multiplayer, which are collisiongroups 1 and 17 respectively. So now question the is, given that dm_steamlab caused the bad code path instantly, how was Valve ever able to play dm_steamlab WITHOUT hitting the bug? There would seem to be some other factor at work, that leaves me wary that we haven't seen the last of this. -bk At 2006/05/28 11:51 PM, you wrote: >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 _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
