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: [email protected]
>>> 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
