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
