--
[ 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.
> >
> >+ 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
>
>
--
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
