-- [ Picked text/plain from multipart/alternative ] I don't think the modding hl2:dm code is the exact same as valve's hl2:dm release code
On 5/29/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > 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: hlcoders@list.valvesoftware.com > >> 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: hlcoders@list.valvesoftware.com > >> >> 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: hlcoders@list.valvesoftware.com > >> >> >> 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: hlcoders@list.valvesoftware.com > >> >> >> > > 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 > > -- _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
