RE: [hlcoders] collision issue
Welp, In order to make it not stop moving, I had to take it out of the hierarchy, soon as I did that it worked fine. Also of note, when in hierarchy, I had to set the move angles 90 degrees different from where they should actually face, like the brushes were being rotated, without actually rotating. I guess the moveparent stuff as-is doesn't working well with brushes being attached to non-brush based entities. Now I have to add a bunch of stuff to cbaseentity so I can still establish the door as being a child, oh well. -- -- omega Heroes of Excelsior http://www.heroesofexcelsior.com Blackened Interactive http://www.blackened-interactive.com > -Original Message- > From: Tony "omega" Sergi [mailto:[EMAIL PROTECTED] > Sent: May 31, 2006 6:57 PM > To: hlcoders@list.valvesoftware.com > Subject: RE: [hlcoders] collision issue > > 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!) > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] collision issue
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: hlcoders@list.valvesoftware.com
> 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(pGameData0);
> CBaseEntity *pEntity1 = static_cast(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
RE: [hlcoders] collision issue
> Alright, I have a prop (model based) which has vphysics
> collision, it has it's own collisiongroup. I have another
> entity, a brush entity (like
> func_door) that moves, and again, has it's own collisiongroup.
>
> ShouldCollide has all the necessary checks and whatnot, but
> when debugging, I've found that shouldcollide is never being
> tested, yet the door collides with the prop, and gets
> stopped; however, it's blocked function doesn't even get called!
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(pGameData0);
CBaseEntity *pEntity1 = static_cast(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
Re: [hlcoders] collision issue
You can't always set a breakpoint in callbacks from the closed-source engine. I'm not really sure why, but I've noticed, during my extensive time spent trying to debug the closed-source vphysics.dll that it doesn't always work. The stack trace gets messed up, presumably by inlined code that lacks symbols. At 2006/05/30 08:05 AM, Tony \"omega\" Sergi wrote: >Hey, I have an issue with collision. > >Alright, I have a prop (model based) which has vphysics collision, it has >it's own collisiongroup. I have another entity, a brush entity (like >func_door) that moves, and again, has it's own collisiongroup. > >ShouldCollide has all the necessary checks and whatnot, but when debugging, >I've found that shouldcollide is never being tested, yet the door collides >with the prop, and gets stopped; however, it's blocked function doesn't even >get called! > >Anyone (valve in particular) have any idea why this is happening? My guess >is that it's being blocked by vphysics inside the engine itself, before it >even gets passed down to the mod, but I'm not sure, as no debug output _or_ >devmessaging ever gets called when it collides. I've even tried putting >breakpoints in the code that creates the blocker list, the blocker code >doesn't even get called either, yet the door still stops. If I move the door >away from the prop, it moves fully. > >Any ideas? > > >-- >-- omega >Heroes of Excelsior >http://www.heroesofexcelsior.com >Blackened Interactive >http://www.blackened-interactive.com > > > >___ >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
