T2DResolveCollisionDelegate - or maybe not?
by Ron Barbosa · in Torque X 2D · 04/23/2010 (5:21 am) · 10 replies
Hey all...I have a situation in my game prototype where I have to periodically change what my main player collides with.
Up until recently, in this situation, I've been able to just disable collisions entirely on the main player and that worked fine. But now I need to be more granular.
My game has power-ups. During the "player respawn" period, he should not be able to pick them up. I handled this in the past by disabling collisions until respawn was completed, but now my map is getting more complex and it has boundaries/borders. So I can't just disable collisions (because then the player can pass through borders), I need to selectively disable collisions.
My problem comes from the fact, that my power-ups have a "Kill" resolution for collisions. The player picks them up and they disappear. The power-ups already run through a collision delegate so that the effects of the power-up can be claimed. Is there a way in this collision delegate (perhaps using the "ref T2DResolveCollisionDelegate resolve" parameter) to check the mutual nature of collisions and then elect to "cancel" the kill resolution?
During respawning, my player's "CollidesWith" member is set strictly to "borders." So during the collision delegate, I'm checking to see if my player is CURRENTLY configured to collide with power-ups and if not, I don't process the collision. But the "Kill" still occurs. So I'm not getting the benefits of the power-up (which is per design), but the power-up is still disappearing.
I know I can remove the kill resolution and handle the deletion in the delegate code, but deletion might not always be the desired resolution. I might want to apply the power-up and leave the power-up in the game scene (like a never-ending health fountain or an ammo dump that has unlimited ammo). I might want the player to be clamped or bounced from the power-up. Also, this same problem might arise in a non-power up situation. I just want to know if there's a way to cancel the configured collision resolution.
I can't find anything about this in the documentation...and the forums are somewhat needle/haystack when it comes to collision management.
Thanks
--RB
Up until recently, in this situation, I've been able to just disable collisions entirely on the main player and that worked fine. But now I need to be more granular.
My game has power-ups. During the "player respawn" period, he should not be able to pick them up. I handled this in the past by disabling collisions until respawn was completed, but now my map is getting more complex and it has boundaries/borders. So I can't just disable collisions (because then the player can pass through borders), I need to selectively disable collisions.
My problem comes from the fact, that my power-ups have a "Kill" resolution for collisions. The player picks them up and they disappear. The power-ups already run through a collision delegate so that the effects of the power-up can be claimed. Is there a way in this collision delegate (perhaps using the "ref T2DResolveCollisionDelegate resolve" parameter) to check the mutual nature of collisions and then elect to "cancel" the kill resolution?
During respawning, my player's "CollidesWith" member is set strictly to "borders." So during the collision delegate, I'm checking to see if my player is CURRENTLY configured to collide with power-ups and if not, I don't process the collision. But the "Kill" still occurs. So I'm not getting the benefits of the power-up (which is per design), but the power-up is still disappearing.
I know I can remove the kill resolution and handle the deletion in the delegate code, but deletion might not always be the desired resolution. I might want to apply the power-up and leave the power-up in the game scene (like a never-ending health fountain or an ammo dump that has unlimited ammo). I might want the player to be clamped or bounced from the power-up. Also, this same problem might arise in a non-power up situation. I just want to know if there's a way to cancel the configured collision resolution.
I can't find anything about this in the documentation...and the forums are somewhat needle/haystack when it comes to collision management.
Thanks
--RB
#2
I don't want to change it, I just want to programmatically ignore it when it should not be processed.
Eventually when collisions with the main player are reenabled I would want the "Kill" to be processed. Changing it to null would remove the kill resolution entirely.
Thanks
--RB
04/23/2010 (10:15 am)
Thanks for the suggestion, but I don't think that would work. That would actually CHANGE the value in the scene object.I don't want to change it, I just want to programmatically ignore it when it should not be processed.
Eventually when collisions with the main player are reenabled I would want the "Kill" to be processed. Changing it to null would remove the kill resolution entirely.
Thanks
--RB
#3
To customize the collision resolution you would give your power-ups a custom ResolveCollision delegate. The delegate can decide what to do dynamically at runtime. You can do your own thing and/or call the default stuff as well (such as T2DPhysicsComponent.KillCollision().
04/23/2010 (10:51 am)
To selectively alter what things your player can collide with, setting the object type and collides-with stuff should suffice. The collision should not even happen if that stuff is set correctly.To customize the collision resolution you would give your power-ups a custom ResolveCollision delegate. The delegate can decide what to do dynamically at runtime. You can do your own thing and/or call the default stuff as well (such as T2DPhysicsComponent.KillCollision().
#4
I basically set my player to be of type "player" and "fullySpawnedPlayer" and I would toggle the "fullySpawnedPlayer" piece appropriately. And that worked...but I was hoping for something a bit more elegant.
I had hoped that I could "capture" the collision resolution before it was enacted, and elect to abort under the necessary conditions.
No matter...it's working fine the way it is now...it's just one of those implementations that I fear will raise trouble in the future. =P
Thanks guys!
--RB
04/23/2010 (10:57 am)
Thanks Duncan, I had gone down that route for a while.I basically set my player to be of type "player" and "fullySpawnedPlayer" and I would toggle the "fullySpawnedPlayer" piece appropriately. And that worked...but I was hoping for something a bit more elegant.
I had hoped that I could "capture" the collision resolution before it was enacted, and elect to abort under the necessary conditions.
No matter...it's working fine the way it is now...it's just one of those implementations that I fear will raise trouble in the future. =P
Thanks guys!
--RB
#6
04/23/2010 (11:08 am)
I think this would be ignoring it when the player isn't able to collide with anything. I'm using it now.T2DSceneObject player = TorqueObjectDatabase.Instance.FindObject<T2DSceneObject>("player");
if (!player.CollisionsEnabled)
{
ourObject.Collision.ResolveCollision = null;
}
else if (player.CollisionsEnabled)
{
ourObject.Collision.ResolveCollision = T2DPhysicsComponent.KillCollision;
}
#7
@Darthuvius...thanks for the tip...I'll give that a shot. The only issue I see is that it will only work for Kill collisions...not for bounce or clamp or whatever else might have been configured in TXB.
Thanks!
--RB
04/23/2010 (11:29 am)
Thanks again, gents.@Darthuvius...thanks for the tip...I'll give that a shot. The only issue I see is that it will only work for Kill collisions...not for bounce or clamp or whatever else might have been configured in TXB.
Thanks!
--RB
#8
04/23/2010 (11:32 am)
You know, I think I have run into the same problems you have. I have custom collision delegates for all my object types, and I don't set the ResolveCollision flag in TXB.
#9
I think the rule of thumb is something like:
On ObjectA
1. Set CollidesWith to include all object types that ObjectA ALWAYS collides with.
2. Add an object type for each variation on collisions (IE full spawned vs. spawn in progress).
3. Add/remove the object types that coincide with variations on collisions.
On other objects that selectively collide with ObjectA
1. Set CollidesWith to include the object type that corresponds to the collision needs (IE full spawned vs. spawn in progress).
That about sums it up I think.
I have it working now...but at the first sign of trouble...I'm going to go sit down in a room with a pen and paper, and work this whole thing out. =P
Thanks guys!
--RB
04/23/2010 (11:40 am)
I've been working with a combination of custom delegates, basic resolution, and both together. All was well until I ran into this respawning issue where I need more selective collision containment.I think the rule of thumb is something like:
On ObjectA
1. Set CollidesWith to include all object types that ObjectA ALWAYS collides with.
2. Add an object type for each variation on collisions (IE full spawned vs. spawn in progress).
3. Add/remove the object types that coincide with variations on collisions.
On other objects that selectively collide with ObjectA
1. Set CollidesWith to include the object type that corresponds to the collision needs (IE full spawned vs. spawn in progress).
That about sums it up I think.
I have it working now...but at the first sign of trouble...I'm going to go sit down in a room with a pen and paper, and work this whole thing out. =P
Thanks guys!
--RB
#10
"Use this for objects which sometimes collide and sometimes don't"
04/24/2010 (8:01 am)
Just to add some more options - check out TestEarlyOut. The code commments say:"Use this for objects which sometimes collide and sometimes don't"
Torque Owner Darthuvius
ourObject.Collision.ResolveCollision = null;