What is the overlap offset coordinate based on?

0 favourites
  • 12 posts
From the Asset Store
Advanced inventory mechanics for your RPG game (Array-based). Take Items, split them, pick up them, read the description
  • Hi,

    I'm wondering what the "Is overlapping at offset" coordinate is based on in Construct 2.

    For instance, is it based on the coordinate of an object's hotspot? Or is it based on the edge of the bounding box from whichever side you are offsetting from?

    Thanks in advance.

  • Quoted from the Sprite manual entry.

    s overlapping another object

    Is overlapping at offset

    True if any instance is overlapping any instance of another object. The collision polygons are taken in to account if set, as well as the object's size and rotation. The 'offset' variant will test for an overlap at an offset from the first object. For example, testing for an overlap at an offset of (100, 0) will temporarily move the object to the right 100 pixels, test for the overlap, then move it back again.

    It does move the object according to its origin point.

    Once the origin is moved, the collision polygon is moved accordingly.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Thanks for the explanation.

    The reason I'm asking is because I'm having a *lot* of problems with object bounding boxes colliding with each other when they really shouldn't.

    For example, I have 4 16x16px boxes placed in 2 stacks next to each other on a 16x16px tiled grid.

    As such:

    [ ][ ]

    [ ][ ]

    I have an event that goes:

    If box is NOT overlapping crate at offset 0,1px && If box is NOT overlapping ground tile at offset 0,1px

    Move crate self.x, self.y+1

    The problem is that the top crates will NOT fall down if there is a bottom crate located in the stack next to it.

    For example, in this case the top crate would fall down:

    [ ]

    [ ] <-- When this is destroyed, the top crate falls down.

    But in this case:

    [ ][ ]

        [ ] <-- Suddenly the top crates can't fall down until this bottom crate is destroyed as well.

    Why is this?! The bounding boxes are set to the exact size of the objects, so that shouldn't be a problem.

    It's really frustrating. :/

  • > Move create self.x, self.y+1

    Should this be... > Move create self.y, self.y+1

    Where Y is down ?

  • What do you mean by "Move create"?

    And what do you mean by "self.y, self.y+1"?

  • What do you mean by "Move create"?

    And what do you mean by "self.y, self.y+1"?

    --------------------------------

    Question 1

    "I have an event that goes:

    If box is NOT overlapping crate at offset 0,1px && If box is NOT overlapping ground tile at offset 0,1px

    Move create self.x, self.y+1"

    This is what you wrote!

    ----------------------------------

    Question 2

    You wrote "self.x, self.y+1"

    Which direction are you trying to move the object X or Y.

  • Sorry, my bad. I meant to type "move CRATE." :-)

    hich direction are you trying to move the object X or Y.

    Y, but I'm specifying the X position as well for the sake of clarity.

  • Your best bet, would be to post a link to the capx.

    (I'm still using r95..if your using a more recent release somebody will

    look at it)

  • I don't want to post the cap because it's for a commercial project. I don't think there's a need to do it anyway, since it's not a bug. :-)

  • Try to have crates 1 pixel smaller (63X63) than the grid's cells size.

  • Thanks for the reply.

    Would that really make any difference? Isn't the bounding box what determines the collision?

    Because I've already tried to reduce the bounding box by 1px on all sides, but it only caused the box to fall down until it's once again in contact with the box below. And then we're back on square 1. :-/

  • I had a similar issue on a breakout game I was working on, it involved physics but the same principle.

    I did as suggested previously in the thread, but used floating point - ie   15.9 x 15.9

    There appears no visible difference , but it's enough for objects not to touch physically, even if visibly they appear to touch.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)