reading Object Type in code?
by Charles Marshall · in Torque X 2D · 07/26/2010 (4:21 am) · 7 replies
I have a collision delegate for my player, which include the parameters ourObject and theirObject. How do I test these objects for an Object Type? I set Object Types in the Builder but in the debugger I only see values of "unknown". Are the Object Types of the Builder represented by T2DSceneObject.ObjectType in the code?
About the author
#2
What I was wondering is if there was a field or method or some other way to dig the Object Type identifier (created in the TXB) for a spawned object.
I haven't been able to find one, and maybe it's not the way to solve the problem I'm facing (although it would seem like a pretty direct way).
The problem is I have a "player" object type that I want collidable with several other object types. For instance, an "enemy" and a "powerup".
The idea was to add "enemy" and "powerup" to the "collides with" list in TXB and have the collision delegate check which it is and decide whether to apply the buff or hurt the player.
I've been searching the forums to find other ways to solve this but not sure a uniform, "best practice" way is out there.
I did run across this thread, and will look further into it soon:
http://www.torquepowered.com/community/forums/viewthread/114407
07/27/2010 (2:00 am)
Thanks for the reply.What I was wondering is if there was a field or method or some other way to dig the Object Type identifier (created in the TXB) for a spawned object.
I haven't been able to find one, and maybe it's not the way to solve the problem I'm facing (although it would seem like a pretty direct way).
The problem is I have a "player" object type that I want collidable with several other object types. For instance, an "enemy" and a "powerup".
The idea was to add "enemy" and "powerup" to the "collides with" list in TXB and have the collision delegate check which it is and decide whether to apply the buff or hurt the player.
I've been searching the forums to find other ways to solve this but not sure a uniform, "best practice" way is out there.
I did run across this thread, and will look further into it soon:
http://www.torquepowered.com/community/forums/viewthread/114407
#3
and then write trigger delegates for when they actually collide or touch with other objects. My enemy objects have two trigger boxes, one for getting hit and one for when they hit something else.
07/27/2010 (2:06 am)
Ah, I do similar things, but instead of dealing with collision for individual things, i attach a "trigger zone" to my scene objectand then write trigger delegates for when they actually collide or touch with other objects. My enemy objects have two trigger boxes, one for getting hit and one for when they hit something else.
#4
How I'm doing it in the shmup I am developing is I have the player set to only collide with what harms it. This way, when it hits something that harms it, it's delegate gets called.
For the powerups, I have the powerup set to collide with the player. When it hit's the player, it's delegate runs, but the player's does not. The powerup delegate then informs the player it hit that it gained said powerup.
You see, both object don't have to be set to collide for their delegates to go off, just one.
Another way to do it, the way you are looking into, is to test the types. I assume you already have set naming conventions for your types so to say test if an object is of the "Powerup" type you'd have to do this:
This function will be true if the SceneObject's ObjectType contains the powerup type. It basically ANDs the bits and if a nonzero number is resulted it pops out a true.
I believe that is what you are looking for, throw that in an if statement and you should be fine.
07/27/2010 (8:39 am)
There's a few solutions to what you want to do. I'm guessing you are doing some sort of shooter, whether it be an arena or a shmup, the only reason Im guessing that is you make no mention of walls or other such obstacles.How I'm doing it in the shmup I am developing is I have the player set to only collide with what harms it. This way, when it hits something that harms it, it's delegate gets called.
For the powerups, I have the powerup set to collide with the player. When it hit's the player, it's delegate runs, but the player's does not. The powerup delegate then informs the player it hit that it gained said powerup.
You see, both object don't have to be set to collide for their delegates to go off, just one.
Another way to do it, the way you are looking into, is to test the types. I assume you already have set naming conventions for your types so to say test if an object is of the "Powerup" type you'd have to do this:
SceneObject.ObjectType & TorqueObjectDatabase.Instance.GetObjectType("Powerup")This function will be true if the SceneObject's ObjectType contains the powerup type. It basically ANDs the bits and if a nonzero number is resulted it pops out a true.
I believe that is what you are looking for, throw that in an if statement and you should be fine.
#5
@Chris
I had considered the first solution, but I ran into some complexities and haven't sat down to try to sort them out. For instance, what if I want the power up to have a different effect on the enemy than on the player? Then it seems I have the same problem, it's just been moved to another object's collision delegate.
The second solution appears to be what I'm looking for. It's simple and direct and evades the logistics issues that could arise when dealing with many object types and collision combinations. I'll have to try it tonight when I get out of work!
I ran through all the tutorials in the official documentation but I don't recall learning how to use the TorqueObjectDatabase. I admit, I skipped over the other parts of the documentation, though!
@Ray
Thanks for sharing your solution! I'll definitely keep it in mind in case I run into problems with the bit checking.
07/27/2010 (2:31 pm)
thanks again guys! @Chris
I had considered the first solution, but I ran into some complexities and haven't sat down to try to sort them out. For instance, what if I want the power up to have a different effect on the enemy than on the player? Then it seems I have the same problem, it's just been moved to another object's collision delegate.
The second solution appears to be what I'm looking for. It's simple and direct and evades the logistics issues that could arise when dealing with many object types and collision combinations. I'll have to try it tonight when I get out of work!
I ran through all the tutorials in the official documentation but I don't recall learning how to use the TorqueObjectDatabase. I admit, I skipped over the other parts of the documentation, though!
@Ray
Thanks for sharing your solution! I'll definitely keep it in mind in case I run into problems with the bit checking.
#6
In my shmup, I have two bullet types, player and enemy. Both of them use the same delegate. How I do it is I have the player and enemy components implement an interface(IDamagable), thus when a bullet collides with an entity to do the damage code it searches the components of what it hit for one of type IDamagable and then calls the method defined by it.
So basically I do something like this(this is my actual code):
It doesn't care what object type them is, it just calls it's code if it has any(thus if it's not damageable but still collidable, the bullet still disappears.
07/27/2010 (4:46 pm)
Well, when it gets complicated where you want one objecttype to do one thing and another to another, or two of the same object type to do different things I'd much rather use interfaces than checking object types and then looking for their respective components. It adds more work than needs to be done with the object type stuff(I basically use object types just for the collision, I rarely check them in code).In my shmup, I have two bullet types, player and enemy. Both of them use the same delegate. How I do it is I have the player and enemy components implement an interface(IDamagable), thus when a bullet collides with an entity to do the damage code it searches the components of what it hit for one of type IDamagable and then calls the method defined by it.
So basically I do something like this(this is my actual code):
public static void BulletCollision(T2DSceneObject us, T2DSceneObject them, T2DCollisionInfo info, ref T2DResolveCollisionDelegate resolve, ref T2DCollisionMaterial physicsMaterial)
{
IDamagable damageComponent = null;
BulletComponent bulletComponent = us.Components.FindComponent<BulletComponent>();
if (bulletComponent == null) return;
foreach (TorqueComponent component in them.Components)
{
if (component is IDamagable)
{
damageComponent = component as IDamagable;
break;
}
}
if (damageComponent != null)
{
damageComponent.CauseDamage(bulletComponent._damage);
}
// TODO: Maybe have an effect call.
bulletComponent._enabled = false;
us.MarkForDelete = true;
}It doesn't care what object type them is, it just calls it's code if it has any(thus if it's not damageable but still collidable, the bullet still disappears.
#7
Thanks!
07/27/2010 (6:15 pm)
Yeah, that looks much better. Initially, I was looking for the bit-checking type solution but I think as I move from proof-of-concept to actual game development, where I'll have a great many more object types colliding with a variety of effects, I'll need to be more deliberate.Thanks!
Torque Owner Raymond Ku
no studio
does
variable.GetType() do anything?