Pin one object to another?

Hi Guys

Is there a way to pin Object1 to Object2 without using groups or updating it’s position every frame?

Thanks in advance for any help!

Depending on what kind of behavior you’re trying to accomplish, you can use joints.

Hi @Alex@PaNc

Thanks for your help :slight_smile: I’m trying to detect a collision between a group object and a normal object.

One object is just an image and the other object is a group containing a whole bunch of body parts.

Since collisions between objects in groups vs objects outside those groups doesn’t seem to work (Seems like they have to be in the same co-ordinate space), I have to attach a fake “hitmap” to the group object and make it’s x and y always equal that of the group.

So, I was wondering what the simples and most efficient way of doing this would be?

There is no such thing as a “group of bodies.” This is because the physics engine places all physics bodies into the root stage display group, relative to the display object’s X,Y position within it’s parent group.

The easy way to think about this is this:

  • Take the X,Y value of your display object (if it’s parent group has moved, this X,Y will not change)

  • Go to the X,Y position on the screen from the top left of the screen

  • Draw the outline of the physics body at the new X,Y position

  • Are the display object and the physics body aligned?

The easy way to find out if they are different is to call :contentFromLocal(0,0) on your display object which has a physics body attached. If the x,y values returned are different from the display object’s x,y values, then you will have problems with your physics in your game.

The solution is to simply not move the parent group. This is ok because when you are using physics bodies which are meant to be used as a group they are probably meant to be attached to each other by a joint, meaning they will move as a group. Think of a ragdoll - the arms will move relative to the body because they are attached, not because they are in the same display group.

So, as a first step, put ALL of your display objects into the same display group - the stage should be a good place. Then, attach objects to each other as they should be by using joints. Then, if you really want some of those objects to be grouped in display groups, put them in display groups but DO NOT MOVE the groups.

The final thing to remember is that when you move a physics object it must be with a touch joint and not by changing the x,y values - this is called fighting the physics engine and WILL cause your game to break.

Treat your display objects and physics bodies like this and you will not have collision problems.

http://springboardpillow.blogspot.co.uk/2014/06/fighting-physics-engine.html

Hi @horacebury

Thank you for your detailed post and link. What you put down makes perfect sense.

The issue is that I am really working with a level that predominantly uses ‘Tweening’.

In this case I understand using physics is not suitable and I should be looking for another war to do collision detection on the objects.

What is it that you are tweening? If it’s just the positions of the objects there isn’t really anything stopping you doing that. It is a little more complex to tween a physics object, but when you think that you are really just tweening the position of a touch joint it becomes a lot clearer.

Bear in mind that a touch joint needs to be moved by a setTarget() call and not just a x,y update. Having said that, an enterFrame listener would do the trick and in this case would not be heavy.

Hi @horacebury

To be honest, for some of the levels I’m working for physics are completely unnecessary. All they do is provide an easy way to do precise hit detection.

Since I’m tweening characters with multiple body parts, I’ve replaced the current hit-test with a bounding box to bounding box hit-test that does the job without using physics :slight_smile:

if rock.contentBounds.xMin < ufo.contentBounds.xMax

and rock.contentBounds.xMax > ufo.contentBounds.xMin

and rock.contentBounds.yMin < ufo.contentBounds.yMax

and rock.contentBounds.yMax > ufo.contentBounds.yMin then

… do stuff

end

Depending on what kind of behavior you’re trying to accomplish, you can use joints.

Hi @Alex@PaNc

Thanks for your help :slight_smile: I’m trying to detect a collision between a group object and a normal object.

One object is just an image and the other object is a group containing a whole bunch of body parts.

Since collisions between objects in groups vs objects outside those groups doesn’t seem to work (Seems like they have to be in the same co-ordinate space), I have to attach a fake “hitmap” to the group object and make it’s x and y always equal that of the group.

So, I was wondering what the simples and most efficient way of doing this would be?

There is no such thing as a “group of bodies.” This is because the physics engine places all physics bodies into the root stage display group, relative to the display object’s X,Y position within it’s parent group.

The easy way to think about this is this:

  • Take the X,Y value of your display object (if it’s parent group has moved, this X,Y will not change)

  • Go to the X,Y position on the screen from the top left of the screen

  • Draw the outline of the physics body at the new X,Y position

  • Are the display object and the physics body aligned?

The easy way to find out if they are different is to call :contentFromLocal(0,0) on your display object which has a physics body attached. If the x,y values returned are different from the display object’s x,y values, then you will have problems with your physics in your game.

The solution is to simply not move the parent group. This is ok because when you are using physics bodies which are meant to be used as a group they are probably meant to be attached to each other by a joint, meaning they will move as a group. Think of a ragdoll - the arms will move relative to the body because they are attached, not because they are in the same display group.

So, as a first step, put ALL of your display objects into the same display group - the stage should be a good place. Then, attach objects to each other as they should be by using joints. Then, if you really want some of those objects to be grouped in display groups, put them in display groups but DO NOT MOVE the groups.

The final thing to remember is that when you move a physics object it must be with a touch joint and not by changing the x,y values - this is called fighting the physics engine and WILL cause your game to break.

Treat your display objects and physics bodies like this and you will not have collision problems.

http://springboardpillow.blogspot.co.uk/2014/06/fighting-physics-engine.html

Hi @horacebury

Thank you for your detailed post and link. What you put down makes perfect sense.

The issue is that I am really working with a level that predominantly uses ‘Tweening’.

In this case I understand using physics is not suitable and I should be looking for another war to do collision detection on the objects.

What is it that you are tweening? If it’s just the positions of the objects there isn’t really anything stopping you doing that. It is a little more complex to tween a physics object, but when you think that you are really just tweening the position of a touch joint it becomes a lot clearer.

Bear in mind that a touch joint needs to be moved by a setTarget() call and not just a x,y update. Having said that, an enterFrame listener would do the trick and in this case would not be heavy.

Hi @horacebury

To be honest, for some of the levels I’m working for physics are completely unnecessary. All they do is provide an easy way to do precise hit detection.

Since I’m tweening characters with multiple body parts, I’ve replaced the current hit-test with a bounding box to bounding box hit-test that does the job without using physics :slight_smile:

if rock.contentBounds.xMin < ufo.contentBounds.xMax

and rock.contentBounds.xMax > ufo.contentBounds.xMin

and rock.contentBounds.yMin < ufo.contentBounds.yMax

and rock.contentBounds.yMax > ufo.contentBounds.yMin then

… do stuff

end