What makes you think that? I've never seen any evidence of that. At 2006/05/29 01:41 PM, Nick wrote: >-- >[ 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
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
