Looks like another symptom of this new Physical Mayhem bug is the "Object
attached to Physcannon has no physics object" error I mentioned earlier. I
added an assert for it, and it hit it on an ordinary barrel that somehow was
lacking a physics object.
+ m_ModelName {pszValue=0x039452d8
"models/props_c17/oildrum001_explosive.mdl" } string_t
+ m_pPhysicsObject 0x00000000 IPhysicsObject *
> server.dll!CGrabController::ComputeError() Line 413 + 0x91 C++
server.dll!CGrabController::UpdateObject(CBasePlayer *
pPlayer=0x264b8f38, float flError=12.000000) Line 2334 + 0xe C++
server.dll!CWeaponPhysCannon::UpdateObject() Line 2460 + 0x16 C++
server.dll!CWeaponPhysCannon::ItemPreFrame() Line 2632 C++
server.dll!CBasePlayer::ItemPreFrame() Line 90 + 0x24 C++
server.dll!CHL2_Player::PreThink() Line 351 C++
server.dll!CHL2MP_Player::PreThink() Line 627 C++
server.dll!CPlayerMove::RunPreThink(CBasePlayer * player=0x264b8f38)
Line 255 + 0x10 C++
server.dll!CPlayerMove::RunCommand(CBasePlayer * player=0x264b8f38,
CUserCmd * ucmd=0x1e7f0f30, IMoveHelper * moveHelper=0x2341c3fc) Line 378 C++
server.dll!CBasePlayer::PlayerRunCommand(CUserCmd * ucmd=0x1e7f0f30,
IMoveHelper * moveHelper=0x2341c3fc) Line 3140 C++
server.dll!CHL2_Player::PlayerRunCommand(CUserCmd * ucmd=0x1e7f0f30,
IMoveHelper * moveHelper=0x2341c3fc) Line 840 C++
server.dll!CBasePlayer::PhysicsSimulate() Line 3032 + 0x23 C++
server.dll!Physics_SimulateEntity(CBaseEntity * pEntity=0x264b8f38)
Line 2064 + 0x10 C++
server.dll!Physics_RunThinkFunctions(bool simulating=true) Line 2120 +
0xf C++
server.dll!CServerGameDLL::GameFrame(bool simulating=true) Line 907 +
0x9 C++
engine.dll!0dab0d91()
engine.dll!0daab617()
engine.dll!0daad1d5()
engine.dll!0da0e277()
engine.dll!0da0e976()
engine.dll!0da1b8c5()
engine.dll!0da1b9f3()
user32.dll!77d496b8()
engine.dll!0da1ba9f()
engine.dll!0dabf4f3()
engine.dll!0dabd28d()
dedicated.dll!100056f4()
engine.dll!0da2e0ab()
engine.dll!0dabeea9()
engine.dll!0dabe3d0()
engine.dll!0dabe3e3()
engine.dll!0db218d1()
engine.dll!0dabed25()
engine.dll!0dc304bb()
dedicated.dll!10005ba4()
materialsystem.dll!00d0d4e2()
materialsystem.dll!00cc552e()
materialsystem.dll!00cd1cfe()
materialsystem.dll!00cd1e88()
materialsystem.dll!00cd1cfe()
materialsystem.dll!00d115de()
materialsystem.dll!00cdaac2()
tier0.dll!0089357f()
ntdll.dll!7c90d4ea()
kernel32.dll!7c809ad2()
kernel32.dll!7c809ae9()
tier0.dll!00897c55()
tier0.dll!008910b8()
tier0.dll!00897c55()
datacache.dll!00e800ab()
datacache.dll!00e714c9()
datacache.dll!00e73c5e()
datacache.dll!00e7490e()
engine.dll!0db85d38()
engine.dll!0db8596c()
engine.dll!0d9b030d()
dedicated.dll!1001fd6b()
dedicated.dll!10020c41()
dedicated.dll!10020c41()
dedicated.dll!10005d81()
ntdll.dll!7c9146c3()
ntdll.dll!7c914481()
ntdll.dll!7c919bd3()
ntdll.dll!7c910895()
tier0.dll!008a24e9()
tier0.dll!00891db0()
dedicated.dll!1000613d()
ntdll.dll!7c91056d()
kernel32.dll!7c801be6()
kernel32.dll!7c801bf6()
ntdll.dll!7c919aeb()
ntdll.dll!7c919ba0()
kernel32.dll!7c80ac66()
srcds.exe!004011bc()
At 2006/07/03 06:28 PM, [EMAIL PROTECTED] wrote:
>Ok, the "too many convex pieces" message only occurs on that one spot in
>dm_steamlab. It appears to be a feature of the map and has no affect on the
>critical vphysics issues.
>
>I tried host_framerate set to 0, 1, 10 and 100. I didn't notice any
>difference in physics interactions, or any difference in anything else at all,
>at any setting. The vphysics continued to be broken at all host_framerate
>settings with a debug mod dll and high cpu usage. The vphysics continued to
>work fine at host_framerate settings with a release mode dll, regardless of
>cpu usage.
>
>I speculated that maybe the ShouldCollide_Default assert code you recommended
>might be what was causing debug builds to break, so I tried taking that out as
>well, but it still broke.
>
>Has this not reprod for anyone else? Does Valve run large stresstests on
>debug HL2DM?
>
>At 2006/07/02 12:19 PM, Jay Stelly wrote:
>>The function that controls this is in src/dlls/physics_collisionevent.h:
>>
>> int AdditionalCollisionChecksThisTick( int
>>currentChecksDone )
>> {
>> //CallbackContext check(this);
>> if ( currentChecksDone < 1200 )
>> {
>> DevMsg(1,"VPhysics Collision detection getting
>>expensive, check for too many convex pieces!\n");
>> return 1200 - currentChecksDone;
>> }
>> DevMsg(1,"VPhysics exceeded collision check limit
>>(%d)!!!\nInterpenetration may result!\n", currentChecksDone );
>> return 0;
>> }
>>
>>If you get this message:
>> DevMsg(1,"VPhysics Collision detection getting
>>expensive, check for too many convex pieces!\n");
>>
>>It means you're exceeding the design limits of the collision system.
>>It's letting you know that you may get performance problems.
>>
>>If you get this message:
>> DevMsg(1,"VPhysics exceeded collision check limit
>>(%d)!!!\nInterpenetration may result!\n", currentChecksDone );
>>
>>Then the physics system thinks there's a bug or infinite loop of some
>>kind and it's turning off collisions. So you can certainly get the
>>behavior you describe if you see this message.
>>
>>The messages should be unrelated to system load. There isn't any
>>dependency there anyway. Vphysics does simulation at 66Hz regardless of
>>system load (unless you've changed the tick interval for physics) and
>>the limits are all per physics tick. You can always change this
>>function to do several more checks per tick if it makes sense for your
>>mod.
>>
>>That said if you have something you suspect is related to system load,
>>just run with host_framerate 10. That should be the lowest framerate
>>the system will achieve since longer timestamps are clamped to 100ms.
>>
>>Jay
>>
>>> -----Original Message-----
>>> From: [EMAIL PROTECTED]
>>> [mailto:[EMAIL PROTECTED] On Behalf Of
>>> [EMAIL PROTECTED]
>>> Sent: Saturday, July 01, 2006 10:57 PM
>>> To: [email protected]
>>> Subject: RE: [hlcoders] Physical Mayhem bug again! Death by
>>> Touch considered harmful??
>>>
>>> Ah thanks very much. Those messages were from dm_resistance,
>>> so perhaps you can pass the message along to whoever at Valve
>>> made that map. :)
>>>
>>> (I still have the asserts in place from the first HL2DM SDK
>>> Physical Mayhem bug concerning ShouldCollide, so I haven't
>>> hit that issue.)
>>>
>>> After a few hours of testing, I've determined that the repro
>>> scenario has nothing to do with any code changes I've made.
>>> It turns out that it's caused by running a debug version of
>>> the server.dll, and having system cpu usage exceed 25% or so.
>>> So far it doesn't repro in release mode, even with the
>>> higher cpu usage. The reason it took 4 players to repro, is
>>> because in debug mode that's about where srcds.exe starts
>>> using 25% cpu.
>>>
>>> I can artificially launch some other program on the server
>>> box to use cpu, and it, combined with a debug server.dll,
>>> repros the vphysics bug. It's like... vphysics or one of the
>>> other core dlls says "hmm cpu load on the box is high, I
>>> don't have time to check whether these two objects should
>>> touch, so I'll just let them slide through each other"... Is
>>> there something like that in the core dlls side of things?
>>>
>>> The reason it's intermittent is that once cpu goes under the
>>> threshold vphysics suddenly wakes up and starts doing
>>> collisions correctly again.
>>>
>>> For now the work-around is apparently "never use debug
>>> versions of your mod."
>>>
>>> Now that I write this I'm starting to think it was no
>>> coincidence that I found that "VPhysics Collision detection
>>> getting expensive, check for too many convex pieces!" thing.
>>> That message seems to hint at the sort of vphysics logic I
>>> speculated on above.
>>>
>>> At 2006/07/01 06:03 PM, Jay Stelly wrote:
>>> >> The only physics-related console messages are:
>>> >>
>>> >> Object attached to Physcannon has no physics object SOLID_VPHYSICS
>>> >> static prop with no vphysics model!
>>> >> (models/props_foliage/shrub_01a.mdl)
>>> >> SOLID_VPHYSICS static prop with no vphysics model!
>>> >> (models/props_buildings/row_industrial_cluster.mdl)
>>> >> SOLID_VPHYSICS static prop with no vphysics model!
>>> >> (models/props_foliage/tree_deciduous_card_01_skybox.mdl)
>>> >>
>>> >> I'll try to figure out if those are actually bad or just overly
>>> >> verbose informative messages.
>>> >
>>> >These are warnings for the level designer who built the map. The
>>> >entities are set to use a vcollide, but they don't have one so it is
>>> >being disabled. There's no bad behavior other than missing
>>> collisions
>>> >that may be expected.
>>> >
>>> >Jay
>>> >
>>> >_______________________________________________
>>> >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
