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. > >+ pVecMins 0x0012ddc0 {x=4984.7964 y=5646.7964 z=-1191362.9 } > Vector * >+ pVecMaxs 0x0012ddb4 {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 178 C++ >>> >> 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 2252 C++ >>> >> server.dll!PhysFrame(float deltaTime=0.015000000) >>> Line 1359 C++ >>> >> >>> server.dll!CPhysicsHook::FrameUpdatePostEntityThink() Line >>> 441 + 0x9 C++ >>> >> server.dll!InvokeMethod(void (void)* f=0x2242ac00) >>> Line 244 C++ >>> >> >>> 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 >>> >>> >> >>_______________________________________________ >>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