Checking if Sprite is on the ground?
by Beef Churger · in Torque 2D Beginner · 06/13/2014 (5:38 pm) · 9 replies
I currently have this function set up:
Which works, however it will still return true if the object is rubbing against either side of the sprite... which is bad. How can I check if the sprite is 'standing' on an object?
Thanks.
function MySprite::onGround(%this)
{
for(%a = 0; %a < %this.getContactCount(); %a++)
{
%obj = %this.getContact(%a);
if(%obj.getSceneLayer() == 1)
{
return true;
}
}
return false;
}Which works, however it will still return true if the object is rubbing against either side of the sprite... which is bad. How can I check if the sprite is 'standing' on an object?
Thanks.
#2
You can also get the normal vector from the collision of two objects. A sprite that is colliding with the ground will have a normal of (0, 1). See the collision callback section of the physics guide for instructions on how to get the collision normal.
06/14/2014 (4:54 am)
Mich's suggestion is a nice solution.You can also get the normal vector from the collision of two objects. A sprite that is colliding with the ground will have a normal of (0, 1). See the collision callback section of the physics guide for instructions on how to get the collision normal.
#3
1. The character has a small, separate sensor shape for its feet. Whenever that collides with something, we know there's stuff touching the feet. Checking only velocity doesn't help in my case, since the character could be grabbing a wall as well when Y velocity = 0.
2. Check the collision normal between the actual, physical body shape and the "ground" object. If the angle is between defined limits, we know the character should stay standing upright and not slide down the slope.
06/14/2014 (11:20 am)
I'm implementing this successfully in two parts:1. The character has a small, separate sensor shape for its feet. Whenever that collides with something, we know there's stuff touching the feet. Checking only velocity doesn't help in my case, since the character could be grabbing a wall as well when Y velocity = 0.
2. Check the collision normal between the actual, physical body shape and the "ground" object. If the angle is between defined limits, we know the character should stay standing upright and not slide down the slope.
#4
06/14/2014 (1:35 pm)
@Eero - Your solution seems valid to me, considering the wall grabbing. So would you say you have a solution now?
#5
06/14/2014 (2:31 pm)
The problem with checking vertical velocity is if the sprite is standing on dynamic objects that wiggle around. 
#6
06/15/2014 (4:25 pm)
If it's not touching the ground then the ground object won't be in the contact list....
#7
06/15/2014 (7:38 pm)
I should have been more specific, I want to know if it's standing on top of an object (not just the ground).
#8
06/15/2014 (9:02 pm)
Oh, okay. I think you can just run through the contact list and use a little vector math to see if you're above the object you're in contact with. You might have to experiment a little to see how well that works for what you're doing. 
#9
http://www.garagegames.com/community/forums/viewthread/134445
The bug will only bite you if you are using the OnCollision(%sceneObject, %collisionDetails) callback for scene objects.
The fix mentioned there only corrects the collision shape ID issue, though. There will also be a problem with the collision normal. There is no way to tell if the collision normal will be oriented for the object you are calling the collision on or for the object with which it collided. I was not using that feature and so did not try to fix that aspect. So if you plan to use collision normals as part of your scheme be warned.
06/23/2014 (3:28 am)
I solved the same problem using sensors. It works well provided you fix the bug referenced in this post:http://www.garagegames.com/community/forums/viewthread/134445
The bug will only bite you if you are using the OnCollision(%sceneObject, %collisionDetails) callback for scene objects.
The fix mentioned there only corrects the collision shape ID issue, though. There will also be a problem with the collision normal. There is no way to tell if the collision normal will be oriented for the object you are calling the collision on or for the object with which it collided. I was not using that feature and so did not try to fix that aspect. So if you plan to use collision normals as part of your scheme be warned.
Employee Michael Perry
ZombieShortbus