Well I used that assert to step into andthrough the code, and it exists shouldcollide saying not to, yet, it still stops; but the server.dll Blocked stuff isn't getting called. It returns from vphysics, then hits vphysics again.
Im going to quickly set the door to non-solid and see what happens,im baffled. Unless vphysics.dll is overriding something somewhere. And yes, there is hierarchy here; the door's parent is the prop (which should NEVER collide, according to the game code, but it's still colliding in the engine somewhere!) -------------- -- omega Heroes of Excelsior http://www.heroesofexcelsior.com Blackened Interactive http://www.blackened-interactive.com > -----Original Message----- > From: Jay Stelly [mailto:[EMAIL PROTECTED] > Sent: May 31, 2006 2:34 PM > To: [email protected] > Subject: RE: [hlcoders] collision issue > > > It's not clear from your message whether you are expecting the objects > to collide or not. If not, then: > Which ShouldCollide()? The one in src/dlls/physics.cpp: > CCollisionEvent::ShouldCollide() ? That one should be getting called > constantly. I would put a trap in that function right at the top. Say > your two collision groups are group1 and group2: > > int CCollisionEvent::ShouldCollide( IPhysicsObject *pObj0, > IPhysicsObject *pObj1, void *pGameData0, void *pGameData1 ) > { > CallbackContext check(this); > > CBaseEntity *pEntity0 = static_cast<CBaseEntity *>(pGameData0); > CBaseEntity *pEntity1 = static_cast<CBaseEntity *>(pGameData1); > > if ( !pEntity0 || !pEntity1 ) > return 1; > > if ( (pEntity0->GetCollisionGroup() == group1 && > pEntity1->GetCollisionGroup() == group2) || > (pEntity1->GetCollisionGroup() == group1 && > pEntity0->GetCollisionGroup() == group2) ) > { > Assert(0); // breaks here, now step through and see why > they are colliding. > } > > Otherwise, Blocked() is not called in every instance. It's only called > by the game physics. So depending on how each object moves it may not > get called. What are the movetypes of the two objects? Are they in any > hierarchies? There's not enough information here for me to answer > further. > > Jay _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
