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 behav
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 m
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
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);
> >}
&
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
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 )
> >{
> >// sw
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
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" ) )
> > > >
> > > >
&
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.
&
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
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)
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)
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)
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)
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)
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 ] 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)
>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 )
>> &
Re: [hlcoders] Physical Mayhem in progress - no crash! (yet)
Sounds like REM sleep _ Rapid Entity Movement Quoting Garry Newman <[EMAIL PROTECTED]>: > -- > [ 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? > ___ 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
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)
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/foru
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 *
>&
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()
> >>
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)
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
