Re: [hlcoders] Physical Mayhem in progress - no crash! (yet)
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
RE: [hlcoders] Physical Mayhem in progress - no crash! (yet)
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
Re: [hlcoders] Physical Mayhem in progress - no crash! (yet)
-- [ 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
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 );
filesystem-AddSearchPath( cstrike, GAME );
cdll_client_int.cpp line 523 after ClientWorldFactoryInit();
filesystem-MountSteamContent( 240 );
filesystem-AddSearchPath( cstrike, 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
RE: [hlcoders] Physical Mayhem in progress - no crash! (yet)
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
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
RE: [hlcoders] Physical Mayhem in progress - no crash! (yet)
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
Re: [hlcoders] Physical Mayhem in progress - no crash! (yet)
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
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 ); filesystem-AddSearchPath( cstrike, GAME ); cdll_client_int.cpp line 523 after ClientWorldFactoryInit(); filesystem-MountSteamContent( 240 ); filesystem-AddSearchPath( cstrike, 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
RE: [hlcoders] Physical Mayhem in progress - no crash! (yet)
This works, thanks. -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 ); filesystem-AddSearchPath( cstrike, GAME ); cdll_client_int.cpp line 523 after ClientWorldFactoryInit(); filesystem-MountSteamContent( 240 ); filesystem-AddSearchPath( cstrike, 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
RE: [hlcoders] Physical Mayhem in progress - no crash! (yet)
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 );
filesystem-AddSearchPath( cstrike, GAME );
cdll_client_int.cpp line 523 after ClientWorldFactoryInit();
filesystem-MountSteamContent( 240 );
filesystem-AddSearchPath( cstrike, 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
RE: [hlcoders] Physical Mayhem in progress - no crash! (yet)
Thanks!
Patch posted at
http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List
with the rest of Jays fixes
--- Jay Stelly [EMAIL PROTECTED] 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 );
filesystem-AddSearchPath( cstrike, GAME );
cdll_client_int.cpp line 523 after
ClientWorldFactoryInit();
filesystem-MountSteamContent( 240 );
filesystem-AddSearchPath( cstrike, 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
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
Re: [hlcoders] Physical Mayhem in progress - no crash! (yet)
Nice work garry! Thanks for the 'fix' as you might call it :) Adam --- Garry Newman [EMAIL PROTECTED] wrote: 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 My Website http://www.ammahls.com Lead Programer NightFall http://www.nightfallmod.net Developer of CST and ZHLT 3.0 http://www.zhlt.info Team Lead - Prime - http://www.nigredostudios.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Physical Mayhem in progress - no crash! (yet)
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
Re: [hlcoders] Physical Mayhem in progress - no crash! (yet)
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
Re: [hlcoders] Physical Mayhem in progress - no crash! (yet)
--
[ Picked text/plain from multipart/alternative ]
Objects are asleep when they're at rest and it isn't calculating the
physics. If the objects are all moving it'd be pretty weird that they're all
asleep.
When they're moving around can you make it wireframe their physics object -
is that moving around too?
On 4/20/06, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
What is IsAsleep()? I can't find any documentation on it, but is it weird
that all the objects are IsAsleep() true?
I notice it because the closed-source side calls back to
WorldSpaceSurroundingBounds which calls ComputeSurroundingBox, and in
there it always goes to check and is always false. m_nSurroundType is
always set to USE_OBB_COLLISION_BOUNDS for all callbacks from the
closed-source. I can't find any documentation on that either - what does
OBB stand for?
I ran for several seconds with custom breakpoints, and all
CCollisionProperty objects that got callbacks from the closed-source side
were USE_OBB_COLLISION_BOUNDS and IsAsleep(). I'm not certain that means
all CCollisionProperty objects are that way. Is it possible some just
aren't getting callbacks?
-bk
At 2006/04/19 07:53 PM, [EMAIL PROTECTED] wrote:
I'm seeing plenty of callbacks to WorldSpaceSurroundingBounds from the
core engine side of things, and for what it's worth the SDK side is
returning seemingly valid, albeit hugely negative z, values.
+ pVecMins0x0012ddc0 {x=4984.7964 y=5646.7964 z=-1191362.9}
Vector *
+ pVecMaxs0x0012ddb4 {x=4991.2036 y=5653.2036 z=-1191346.1}
Vector *
I'm not ever seeing MarkEntitiesAsTouching getting a callback. That
actually makes sense in a way, since when Physical Mayhem occurs, you can
grav gun objects right through other objects.
It also is consistent with all the hugely negative z values. I guess
nothing ever got a touch callback for impacting the ground, so everything
just falls right through forever?
Why don't players fall through the map? I guess players don't obey
vphysics.dll in the same way the other entities do?
At 2006/04/18 11:58 PM, Jay Stelly wrote:
The z values are interesting - I'm not sure what to make of that.
Obviously those are out of the world coordinate range.
If it helps, the code for solidmoved is basically this:
// pSolidCollide is the CollisionProp of the entity that
moved
pSolidCollide-WorldSpaceSurroundingBounds(
vecWorldMins, vecWorldMaxs );
// builds a list of trigger entities touching the box
into m_TouchedEntities
SpatialPartition()-EnumerateElementsInBox(
PARTITION_ENGINE_TRIGGER_EDICTS,
vecWorldMins, vecWorldMaxs, false,
touchEnumerator );
// call the game DLL's touch functions
for ( int i = 0; i m_TouchedEntities.Count(); ++i )
{
serverGameEnts-MarkEntitiesAsTouching(
m_TouchedEntities[i], m_pTriggerEntity );
}
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, April 18, 2006 9:08 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Physical Mayhem in progress - no crash! (yet)
Inside engine-SolidMoved the engine.dll does a few callbacks
to the open source side to get collision properties and
origins. Then it loops around for a very long time, walking
some sort of closed-source linked-list.
Is engine-SolidMoved supposed to be doing looping and
cpu-intensive things? Or is the fact that that's happening
bad unto itself?
Anybody know of a good x86 asm manual?
At 2006/04/18 08:51 PM, [EMAIL PROTECTED] wrote:
I noticed that most of the objects in the world have z values like:
z -880609.44 float
z -861464.81 float
z -1501742.9 float
So I guess when the Physical Mayhem bug is happening and all
the items disappear, they aren't getting removed from the
game, they're just falling forever.
Could it be the player bodies falling out of the map bug
might be an unusual symptom of the Physical Mayhem bug?
At 2006/04/18 08:43 PM, [EMAIL PROTECTED] wrote:
So I happened to catch my server when the Physical Mayhem
bug was in progress but the server had not (yet) crashed.
(See
http://forums.steampowered.com/forums/showthread.php?s=thre
adid=24842
5 for anyone unfamiliar with this bug.)
Anything I can do to help debug this? As usual with the
Physical Mayhem bug, it's constantly using maximum cpu. If I
break in, it's almost always sitting in engine-SolidMoved in
this trace:
engine.dll!0da8aab8()
engine.dll!0da8aea4()
engine.dll!0da8b063()
engine.dll!0da8b094()
engine.dll!0dabfeba()
engine.dll!0dac0460()
server.dll!CBaseEntity
Re: [hlcoders] Physical Mayhem in progress - no crash! (yet)
OBB is just the bounding box around the model
USE_OBB_COLLISION_BOUNDS is probably there for other support that was never
implemented/never needed to be
So you think it's bad if every entity in the world is set to
USE_OBB_COLLISION_BOUNDS? Valve, is this bad?
Garry, are you talking about a feature in the SDK that can be enabled to do
this? If so, what is the steps to do so? If you're talking about code
changes, maybe.
If you just want to compare the origin of the CBaseEntity to the origin of the
CBaseEntity's IPhysicsObject, I can do that. By breaking on the if (
origin.IsValid() ) line in baseentity_shared.cpp I see:
+ origin {x=7434. y=6504. z=-1504929.6 } Vector
+ prevOrigin {x=7434. y=6504. z=-1504900.0 } Vector
So the entity is falling 29.6 units per frame. Seems reasonable for an entity
that fell right out of the world and is falling forever due to gravity.
I checked several entities, they all have constant x and y but are falling
between 10 and 30 units per frame.
Maybe I'm not using the word frame correctly above. Perhaps it should be
tick?
At 2006/04/20 04:25 AM, Garry Newman wrote:
--
[ Picked text/plain from multipart/alternative ]
Objects are asleep when they're at rest and it isn't calculating the
physics. If the objects are all moving it'd be pretty weird that they're all
asleep.
When they're moving around can you make it wireframe their physics object -
is that moving around too?
On 4/20/06, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
What is IsAsleep()? I can't find any documentation on it, but is it weird
that all the objects are IsAsleep() true?
I notice it because the closed-source side calls back to
WorldSpaceSurroundingBounds which calls ComputeSurroundingBox, and in
there it always goes to check and is always false. m_nSurroundType is
always set to USE_OBB_COLLISION_BOUNDS for all callbacks from the
closed-source. I can't find any documentation on that either - what does
OBB stand for?
I ran for several seconds with custom breakpoints, and all
CCollisionProperty objects that got callbacks from the closed-source side
were USE_OBB_COLLISION_BOUNDS and IsAsleep(). I'm not certain that means
all CCollisionProperty objects are that way. Is it possible some just
aren't getting callbacks?
-bk
At 2006/04/19 07:53 PM, [EMAIL PROTECTED] wrote:
I'm seeing plenty of callbacks to WorldSpaceSurroundingBounds from the
core engine side of things, and for what it's worth the SDK side is
returning seemingly valid, albeit hugely negative z, values.
+ pVecMins0x0012ddc0 {x=4984.7964 y=5646.7964 z=-1191362.9}
Vector *
+ pVecMaxs0x0012ddb4 {x=4991.2036 y=5653.2036 z=-1191346.1}
Vector *
I'm not ever seeing MarkEntitiesAsTouching getting a callback. That
actually makes sense in a way, since when Physical Mayhem occurs, you can
grav gun objects right through other objects.
It also is consistent with all the hugely negative z values. I guess
nothing ever got a touch callback for impacting the ground, so everything
just falls right through forever?
Why don't players fall through the map? I guess players don't obey
vphysics.dll in the same way the other entities do?
At 2006/04/18 11:58 PM, Jay Stelly wrote:
The z values are interesting - I'm not sure what to make of that.
Obviously those are out of the world coordinate range.
If it helps, the code for solidmoved is basically this:
// pSolidCollide is the CollisionProp of the entity that
moved
pSolidCollide-WorldSpaceSurroundingBounds(
vecWorldMins, vecWorldMaxs );
// builds a list of trigger entities touching the box
into m_TouchedEntities
SpatialPartition()-EnumerateElementsInBox(
PARTITION_ENGINE_TRIGGER_EDICTS,
vecWorldMins, vecWorldMaxs, false,
touchEnumerator );
// call the game DLL's touch functions
for ( int i = 0; i m_TouchedEntities.Count(); ++i )
{
serverGameEnts-MarkEntitiesAsTouching(
m_TouchedEntities[i], m_pTriggerEntity );
}
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, April 18, 2006 9:08 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Physical Mayhem in progress - no crash! (yet)
Inside engine-SolidMoved the engine.dll does a few callbacks
to the open source side to get collision properties and
origins. Then it loops around for a very long time, walking
some sort of closed-source linked-list.
Is engine-SolidMoved supposed to be doing looping and
cpu-intensive things? Or is the fact that that's happening
bad unto itself?
Anybody know of a good x86 asm manual?
At 2006/04/18 08:51 PM, [EMAIL PROTECTED] wrote:
I noticed that most of the objects
Re: [hlcoders] Physical Mayhem in progress - no crash! (yet)
-- [ 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
RE: [hlcoders] Physical Mayhem in progress - no crash! (yet)
I'm seeing plenty of callbacks to WorldSpaceSurroundingBounds from the core
engine side of things, and for what it's worth the SDK side is returning
seemingly valid, albeit hugely negative z, values.
+ pVecMins0x0012ddc0 {x=4984.7964 y=5646.7964 z=-1191362.9 }
Vector *
+ pVecMaxs0x0012ddb4 {x=4991.2036 y=5653.2036 z=-1191346.1 }
Vector *
I'm not ever seeing MarkEntitiesAsTouching getting a callback. That actually
makes sense in a way, since when Physical Mayhem occurs, you can grav gun
objects right through other objects.
It also is consistent with all the hugely negative z values. I guess nothing
ever got a touch callback for impacting the ground, so everything just falls
right through forever?
Why don't players fall through the map? I guess players don't obey
vphysics.dll in the same way the other entities do?
At 2006/04/18 11:58 PM, Jay Stelly wrote:
The z values are interesting - I'm not sure what to make of that.
Obviously those are out of the world coordinate range.
If it helps, the code for solidmoved is basically this:
// pSolidCollide is the CollisionProp of the entity that
moved
pSolidCollide-WorldSpaceSurroundingBounds(
vecWorldMins, vecWorldMaxs );
// builds a list of trigger entities touching the box
into m_TouchedEntities
SpatialPartition()-EnumerateElementsInBox(
PARTITION_ENGINE_TRIGGER_EDICTS,
vecWorldMins, vecWorldMaxs, false,
touchEnumerator );
// call the game DLL's touch functions
for ( int i = 0; i m_TouchedEntities.Count(); ++i )
{
serverGameEnts-MarkEntitiesAsTouching(
m_TouchedEntities[i], m_pTriggerEntity );
}
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, April 18, 2006 9:08 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Physical Mayhem in progress - no crash! (yet)
Inside engine-SolidMoved the engine.dll does a few callbacks
to the open source side to get collision properties and
origins. Then it loops around for a very long time, walking
some sort of closed-source linked-list.
Is engine-SolidMoved supposed to be doing looping and
cpu-intensive things? Or is the fact that that's happening
bad unto itself?
Anybody know of a good x86 asm manual?
At 2006/04/18 08:51 PM, [EMAIL PROTECTED] wrote:
I noticed that most of the objects in the world have z values like:
z -880609.44 float
z -861464.81 float
z -1501742.9 float
So I guess when the Physical Mayhem bug is happening and all
the items disappear, they aren't getting removed from the
game, they're just falling forever.
Could it be the player bodies falling out of the map bug
might be an unusual symptom of the Physical Mayhem bug?
At 2006/04/18 08:43 PM, [EMAIL PROTECTED] wrote:
So I happened to catch my server when the Physical Mayhem
bug was in progress but the server had not (yet) crashed.
(See
http://forums.steampowered.com/forums/showthread.php?s=thre
adid=24842
5 for anyone unfamiliar with this bug.)
Anything I can do to help debug this? As usual with the
Physical Mayhem bug, it's constantly using maximum cpu. If I
break in, it's almost always sitting in engine-SolidMoved in
this trace:
engine.dll!0da8aab8()
engine.dll!0da8aea4()
engine.dll!0da8b063()
engine.dll!0da8b094()
engine.dll!0dabfeba()
engine.dll!0dac0460()
server.dll!CBaseEntity::SetSimulationTime(float
st=2.4733254e-012) Line 178C++
engine.dll!0dab5fa4()
server.dll!CBaseEntity::PhysicsTouchTriggers(const
Vector * pPrevAbsOrigin=0x0012df3c) Line 2025 C++
server.dll!CBaseEntity::VPhysicsUpdate(IPhysicsObject *
pPhysics=0x05552ca0) Line 941 C++
server.dll!CPhysicsProp::VPhysicsUpdate(IPhysicsObject *
pPhysics=0x05552ca0) Line 2252C++
server.dll!PhysFrame(float deltaTime=0.01500)
Line 1359C++
server.dll!CPhysicsHook::FrameUpdatePostEntityThink() Line
441 + 0x9 C++
server.dll!InvokeMethod(void (void)* f=0x2242ac00)
Line 244C++
server.dll!IGameSystem::FrameUpdatePostEntityThinkAllSystems()
Line 221 + 0xa C++
server.dll!CServerGameDLL::GameFrame(bool
simulating=true) Line 920C++
engine.dll!0daa0691()
engine.dll!0da9b0e7()
engine.dll!0da9cc75()
engine.dll!0da03cd7()
engine.dll!0da04376()
engine.dll!0da0f025()
engine.dll!0da0f112()
user32.dll!77d496b8()
engine.dll!0da0f1af()
engine.dll!0daacefc()
engine.dll!0daac4ed()
dedicated.dll!1000c084()
dedicated.dll!1000c553()
materialsystem.dll!00cd0dae()
materialsystem.dll!00cd0f38
RE: [hlcoders] Physical Mayhem in progress - no crash! (yet)
What is IsAsleep()? I can't find any documentation on it, but is it weird that
all the objects are IsAsleep() true?
I notice it because the closed-source side calls back to
WorldSpaceSurroundingBounds which calls ComputeSurroundingBox, and in there it
always goes to check and is always false. m_nSurroundType is always set to
USE_OBB_COLLISION_BOUNDS for all callbacks from the closed-source. I can't
find any documentation on that either - what does OBB stand for?
I ran for several seconds with custom breakpoints, and all CCollisionProperty
objects that got callbacks from the closed-source side were
USE_OBB_COLLISION_BOUNDS and IsAsleep(). I'm not certain that means all
CCollisionProperty objects are that way. Is it possible some just aren't
getting callbacks?
-bk
At 2006/04/19 07:53 PM, [EMAIL PROTECTED] wrote:
I'm seeing plenty of callbacks to WorldSpaceSurroundingBounds from the core
engine side of things, and for what it's worth the SDK side is returning
seemingly valid, albeit hugely negative z, values.
+ pVecMins0x0012ddc0 {x=4984.7964 y=5646.7964 z=-1191362.9 }
Vector *
+ pVecMaxs0x0012ddb4 {x=4991.2036 y=5653.2036 z=-1191346.1 }
Vector *
I'm not ever seeing MarkEntitiesAsTouching getting a callback. That actually
makes sense in a way, since when Physical Mayhem occurs, you can grav gun
objects right through other objects.
It also is consistent with all the hugely negative z values. I guess nothing
ever got a touch callback for impacting the ground, so everything just falls
right through forever?
Why don't players fall through the map? I guess players don't obey
vphysics.dll in the same way the other entities do?
At 2006/04/18 11:58 PM, Jay Stelly wrote:
The z values are interesting - I'm not sure what to make of that.
Obviously those are out of the world coordinate range.
If it helps, the code for solidmoved is basically this:
// pSolidCollide is the CollisionProp of the entity that
moved
pSolidCollide-WorldSpaceSurroundingBounds(
vecWorldMins, vecWorldMaxs );
// builds a list of trigger entities touching the box
into m_TouchedEntities
SpatialPartition()-EnumerateElementsInBox(
PARTITION_ENGINE_TRIGGER_EDICTS,
vecWorldMins, vecWorldMaxs, false,
touchEnumerator );
// call the game DLL's touch functions
for ( int i = 0; i m_TouchedEntities.Count(); ++i )
{
serverGameEnts-MarkEntitiesAsTouching(
m_TouchedEntities[i], m_pTriggerEntity );
}
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, April 18, 2006 9:08 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Physical Mayhem in progress - no crash! (yet)
Inside engine-SolidMoved the engine.dll does a few callbacks
to the open source side to get collision properties and
origins. Then it loops around for a very long time, walking
some sort of closed-source linked-list.
Is engine-SolidMoved supposed to be doing looping and
cpu-intensive things? Or is the fact that that's happening
bad unto itself?
Anybody know of a good x86 asm manual?
At 2006/04/18 08:51 PM, [EMAIL PROTECTED] wrote:
I noticed that most of the objects in the world have z values like:
z -880609.44 float
z -861464.81 float
z -1501742.9 float
So I guess when the Physical Mayhem bug is happening and all
the items disappear, they aren't getting removed from the
game, they're just falling forever.
Could it be the player bodies falling out of the map bug
might be an unusual symptom of the Physical Mayhem bug?
At 2006/04/18 08:43 PM, [EMAIL PROTECTED] wrote:
So I happened to catch my server when the Physical Mayhem
bug was in progress but the server had not (yet) crashed.
(See
http://forums.steampowered.com/forums/showthread.php?s=thre
adid=24842
5 for anyone unfamiliar with this bug.)
Anything I can do to help debug this? As usual with the
Physical Mayhem bug, it's constantly using maximum cpu. If I
break in, it's almost always sitting in engine-SolidMoved in
this trace:
engine.dll!0da8aab8()
engine.dll!0da8aea4()
engine.dll!0da8b063()
engine.dll!0da8b094()
engine.dll!0dabfeba()
engine.dll!0dac0460()
server.dll!CBaseEntity::SetSimulationTime(float
st=2.4733254e-012) Line 178C++
engine.dll!0dab5fa4()
server.dll!CBaseEntity::PhysicsTouchTriggers(const
Vector * pPrevAbsOrigin=0x0012df3c) Line 2025 C++
server.dll!CBaseEntity::VPhysicsUpdate(IPhysicsObject *
pPhysics=0x05552ca0) Line 941 C++
server.dll!CPhysicsProp::VPhysicsUpdate(IPhysicsObject *
pPhysics=0x05552ca0) Line 2252C++
server.dll!PhysFrame(float deltaTime=0.01500
Re: [hlcoders] Physical Mayhem in progress - no crash! (yet)
-- [ Picked text/plain from multipart/alternative ] OBB is just the bounding box around the model USE_OBB_COLLISION_BOUNDS is probably there for other support that was never implemented/never needed to be -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physical Mayhem in progress - no crash! (yet)
I noticed that most of the objects in the world have z values like: z -880609.44 float z -861464.81 float z -1501742.9 float So I guess when the Physical Mayhem bug is happening and all the items disappear, they aren't getting removed from the game, they're just falling forever. Could it be the player bodies falling out of the map bug might be an unusual symptom of the Physical Mayhem bug? At 2006/04/18 08:43 PM, [EMAIL PROTECTED] wrote: So I happened to catch my server when the Physical Mayhem bug was in progress but the server had not (yet) crashed. (See http://forums.steampowered.com/forums/showthread.php?s=threadid=248425 for anyone unfamiliar with this bug.) Anything I can do to help debug this? As usual with the Physical Mayhem bug, it's constantly using maximum cpu. If I break in, it's almost always sitting in engine-SolidMoved in this trace: engine.dll!0da8aab8() engine.dll!0da8aea4() engine.dll!0da8b063() engine.dll!0da8b094() engine.dll!0dabfeba() engine.dll!0dac0460() server.dll!CBaseEntity::SetSimulationTime(float st=2.4733254e-012) Line 178C++ engine.dll!0dab5fa4() server.dll!CBaseEntity::PhysicsTouchTriggers(const Vector * pPrevAbsOrigin=0x0012df3c) Line 2025 C++ server.dll!CBaseEntity::VPhysicsUpdate(IPhysicsObject * pPhysics=0x05552ca0) Line 941 C++ server.dll!CPhysicsProp::VPhysicsUpdate(IPhysicsObject * pPhysics=0x05552ca0) Line 2252C++ server.dll!PhysFrame(float deltaTime=0.01500) Line 1359C++ server.dll!CPhysicsHook::FrameUpdatePostEntityThink() Line 441 + 0x9 C++ server.dll!InvokeMethod(void (void)* f=0x2242ac00) Line 244C++ server.dll!IGameSystem::FrameUpdatePostEntityThinkAllSystems() Line 221 + 0xa C++ server.dll!CServerGameDLL::GameFrame(bool simulating=true) Line 920 C++ engine.dll!0daa0691() engine.dll!0da9b0e7() engine.dll!0da9cc75() engine.dll!0da03cd7() engine.dll!0da04376() engine.dll!0da0f025() engine.dll!0da0f112() user32.dll!77d496b8() engine.dll!0da0f1af() engine.dll!0daacefc() engine.dll!0daac4ed() dedicated.dll!1000c084() dedicated.dll!1000c553() materialsystem.dll!00cd0dae() materialsystem.dll!00cd0f38() materialsystem.dll!00cd0dae() materialsystem.dll!00cd0f05() materialsystem.dll!00cd7f64() materialsystem.dll!00cd9502() tier0.dll!0087299f() materialsystem.dll!00cda349() tier0.dll!008764b5() tier0.dll!0087105a() tier0.dll!008731d0() tier0.dll!008738de() datacache.dll!00e7daa2() datacache.dll!00e7e08e() datacache.dll!00e733ae() datacache.dll!00e73e6b() engine.dll!0db556b8() engine.dll!0db552dc() engine.dll!0d9adc0d() dedicated.dll!10021d0b() dedicated.dll!10022c00() dedicated.dll!10022c00() dedicated.dll!1000c7f7() ntdll.dll!7c9106eb() ___ 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
Re: [hlcoders] Physical Mayhem in progress - no crash! (yet)
Inside engine-SolidMoved the engine.dll does a few callbacks to the open source side to get collision properties and origins. Then it loops around for a very long time, walking some sort of closed-source linked-list. Is engine-SolidMoved supposed to be doing looping and cpu-intensive things? Or is the fact that that's happening bad unto itself? Anybody know of a good x86 asm manual? At 2006/04/18 08:51 PM, [EMAIL PROTECTED] wrote: I noticed that most of the objects in the world have z values like: z -880609.44 float z -861464.81 float z -1501742.9 float So I guess when the Physical Mayhem bug is happening and all the items disappear, they aren't getting removed from the game, they're just falling forever. Could it be the player bodies falling out of the map bug might be an unusual symptom of the Physical Mayhem bug? At 2006/04/18 08:43 PM, [EMAIL PROTECTED] wrote: So I happened to catch my server when the Physical Mayhem bug was in progress but the server had not (yet) crashed. (See http://forums.steampowered.com/forums/showthread.php?s=threadid=248425 for anyone unfamiliar with this bug.) Anything I can do to help debug this? As usual with the Physical Mayhem bug, it's constantly using maximum cpu. If I break in, it's almost always sitting in engine-SolidMoved in this trace: engine.dll!0da8aab8() engine.dll!0da8aea4() engine.dll!0da8b063() engine.dll!0da8b094() engine.dll!0dabfeba() engine.dll!0dac0460() server.dll!CBaseEntity::SetSimulationTime(float st=2.4733254e-012) Line 178C++ engine.dll!0dab5fa4() server.dll!CBaseEntity::PhysicsTouchTriggers(const Vector * pPrevAbsOrigin=0x0012df3c) Line 2025 C++ server.dll!CBaseEntity::VPhysicsUpdate(IPhysicsObject * pPhysics=0x05552ca0) Line 941 C++ server.dll!CPhysicsProp::VPhysicsUpdate(IPhysicsObject * pPhysics=0x05552ca0) Line 2252C++ server.dll!PhysFrame(float deltaTime=0.01500) Line 1359C++ server.dll!CPhysicsHook::FrameUpdatePostEntityThink() Line 441 + 0x9 C++ server.dll!InvokeMethod(void (void)* f=0x2242ac00) Line 244C++ server.dll!IGameSystem::FrameUpdatePostEntityThinkAllSystems() Line 221 + 0xa C++ server.dll!CServerGameDLL::GameFrame(bool simulating=true) Line 920 C++ engine.dll!0daa0691() engine.dll!0da9b0e7() engine.dll!0da9cc75() engine.dll!0da03cd7() engine.dll!0da04376() engine.dll!0da0f025() engine.dll!0da0f112() user32.dll!77d496b8() engine.dll!0da0f1af() engine.dll!0daacefc() engine.dll!0daac4ed() dedicated.dll!1000c084() dedicated.dll!1000c553() materialsystem.dll!00cd0dae() materialsystem.dll!00cd0f38() materialsystem.dll!00cd0dae() materialsystem.dll!00cd0f05() materialsystem.dll!00cd7f64() materialsystem.dll!00cd9502() tier0.dll!0087299f() materialsystem.dll!00cda349() tier0.dll!008764b5() tier0.dll!0087105a() tier0.dll!008731d0() tier0.dll!008738de() datacache.dll!00e7daa2() datacache.dll!00e7e08e() datacache.dll!00e733ae() datacache.dll!00e73e6b() engine.dll!0db556b8() engine.dll!0db552dc() engine.dll!0d9adc0d() dedicated.dll!10021d0b() dedicated.dll!10022c00() dedicated.dll!10022c00() dedicated.dll!1000c7f7() ntdll.dll!7c9106eb() ___ 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
RE: [hlcoders] Physical Mayhem in progress - no crash! (yet)
The z values are interesting - I'm not sure what to make of that.
Obviously those are out of the world coordinate range.
If it helps, the code for solidmoved is basically this:
// pSolidCollide is the CollisionProp of the entity that
moved
pSolidCollide-WorldSpaceSurroundingBounds(
vecWorldMins, vecWorldMaxs );
// builds a list of trigger entities touching the box
into m_TouchedEntities
SpatialPartition()-EnumerateElementsInBox(
PARTITION_ENGINE_TRIGGER_EDICTS,
vecWorldMins, vecWorldMaxs, false,
touchEnumerator );
// call the game DLL's touch functions
for ( int i = 0; i m_TouchedEntities.Count(); ++i )
{
serverGameEnts-MarkEntitiesAsTouching(
m_TouchedEntities[i], m_pTriggerEntity );
}
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, April 18, 2006 9:08 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Physical Mayhem in progress - no crash! (yet)
Inside engine-SolidMoved the engine.dll does a few callbacks
to the open source side to get collision properties and
origins. Then it loops around for a very long time, walking
some sort of closed-source linked-list.
Is engine-SolidMoved supposed to be doing looping and
cpu-intensive things? Or is the fact that that's happening
bad unto itself?
Anybody know of a good x86 asm manual?
At 2006/04/18 08:51 PM, [EMAIL PROTECTED] wrote:
I noticed that most of the objects in the world have z values like:
z -880609.44 float
z -861464.81 float
z -1501742.9 float
So I guess when the Physical Mayhem bug is happening and all
the items disappear, they aren't getting removed from the
game, they're just falling forever.
Could it be the player bodies falling out of the map bug
might be an unusual symptom of the Physical Mayhem bug?
At 2006/04/18 08:43 PM, [EMAIL PROTECTED] wrote:
So I happened to catch my server when the Physical Mayhem
bug was in progress but the server had not (yet) crashed.
(See
http://forums.steampowered.com/forums/showthread.php?s=thre
adid=24842
5 for anyone unfamiliar with this bug.)
Anything I can do to help debug this? As usual with the
Physical Mayhem bug, it's constantly using maximum cpu. If I
break in, it's almost always sitting in engine-SolidMoved in
this trace:
engine.dll!0da8aab8()
engine.dll!0da8aea4()
engine.dll!0da8b063()
engine.dll!0da8b094()
engine.dll!0dabfeba()
engine.dll!0dac0460()
server.dll!CBaseEntity::SetSimulationTime(float
st=2.4733254e-012) Line 178C++
engine.dll!0dab5fa4()
server.dll!CBaseEntity::PhysicsTouchTriggers(const
Vector * pPrevAbsOrigin=0x0012df3c) Line 2025 C++
server.dll!CBaseEntity::VPhysicsUpdate(IPhysicsObject *
pPhysics=0x05552ca0) Line 941 C++
server.dll!CPhysicsProp::VPhysicsUpdate(IPhysicsObject *
pPhysics=0x05552ca0) Line 2252C++
server.dll!PhysFrame(float deltaTime=0.01500)
Line 1359C++
server.dll!CPhysicsHook::FrameUpdatePostEntityThink() Line
441 + 0x9 C++
server.dll!InvokeMethod(void (void)* f=0x2242ac00)
Line 244C++
server.dll!IGameSystem::FrameUpdatePostEntityThinkAllSystems()
Line 221 + 0xa C++
server.dll!CServerGameDLL::GameFrame(bool
simulating=true) Line 920C++
engine.dll!0daa0691()
engine.dll!0da9b0e7()
engine.dll!0da9cc75()
engine.dll!0da03cd7()
engine.dll!0da04376()
engine.dll!0da0f025()
engine.dll!0da0f112()
user32.dll!77d496b8()
engine.dll!0da0f1af()
engine.dll!0daacefc()
engine.dll!0daac4ed()
dedicated.dll!1000c084()
dedicated.dll!1000c553()
materialsystem.dll!00cd0dae()
materialsystem.dll!00cd0f38()
materialsystem.dll!00cd0dae()
materialsystem.dll!00cd0f05()
materialsystem.dll!00cd7f64()
materialsystem.dll!00cd9502()
tier0.dll!0087299f()
materialsystem.dll!00cda349()
tier0.dll!008764b5()
tier0.dll!0087105a()
tier0.dll!008731d0()
tier0.dll!008738de()
datacache.dll!00e7daa2()
datacache.dll!00e7e08e()
datacache.dll!00e733ae()
datacache.dll!00e73e6b()
engine.dll!0db556b8()
engine.dll!0db552dc()
engine.dll!0d9adc0d()
dedicated.dll!10021d0b()
dedicated.dll!10022c00()
dedicated.dll!10022c00()
dedicated.dll!1000c7f7()
ntdll.dll!7c9106eb()
___
To unsubscribe, edit your list preferences, or view the
list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo
