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
