Strange collision bug with immovable objects



  • I'm working on a platformer, and we have this bug where the player character can stand on the sides of immovable objects. It only happens while trying to move into the object. At a fundamental level, the problem is that the DOWN touching flag is getting set.

    Here're a few examples:

    platform
    block
    dirt

    In the first image, the platform is in the wall, but the player can still stand on it.
    In the second and third images, the player can stand on the "tops" of two different kinds of immovable blocks instead of falling down.

    The issue could potentially be related to this. If anyone could confirm the problem or offer any workarounds, I'd be very appreciative.

    If it helps, I've stepped into the code and it's the computeOverlapY function that thinks they overlap and is setting the flags.



  • immovable blocks don't do collision checks to well. it is best to set _startX and startY vars to the X and Y vars at constructor new.

    then at update() set X and Y vars to equal the _startX and _startY vars to keep those sprites still in motion.

    the first image the player is getting stuck in the seam because of the down collision is set true. allowCollisions = FlxObject.UP + FlxObject.LEFT + FlxObject.RIGHT; to fix that issue. for the second and third issue, set the collision such as the first collision accordingly.



  • @galoyo I tried forcing the X and Y variables in the update function, but it makes no difference. I'm not sure why it would, as the objects don't actually move anyway.

    Also, changing the allowCollisions flags may "fix" the specific issue, but it fundamentally breaks the intended logic. It's perfectly acceptable (and necessary) for the player to be able to stand on all of the different immovable objects in my examples.



  • @NoahWilson yes, your correct. there is a bug in regards to standing on sprites. the allow collision is the workaround.

    I needed to use _startX and _startY instead of immoveable true, when for example, the x or y was in motion but the other var was not. you might one day need to use those vars.



  • also, immovable objects can still be moved when banging into them. the way I provided with the _startx and _startY is the solution to that bug.



  • @galoyo Tried forcing X and Y instead of setting immovable... Yeah, not what I wanted.
    nopenope



  • there might not be a solution to this. that is, the way you are moving objects in the above image.



  • @galoyo That's simply the default collision call between the player and the blocks, along with the hack to try and force the blocks back to their original position. Nothing fancy or unusual about it.



  • Upon further investigation, I'm convinced that it's exactly a manifestation of this issue. By default some of the boxes will block while jumping up and some while falling down, but sorting the group of blocks by ascending/descending as mentioned in the issue will make them all block the same direction.



  • yes, and to make matters worse, the immovable == true should be renamed to moveable == true :)



  • AHA I BELIEVE I'VE FIXED IT!

    In computeOverlapY when constructing the two rectangles, it's using Object1/2.x instead of Object1/2.last.x, which is inconsistent with how the computeOverlapX function was doing it. Making this fix seems to have solved the problem!

    I'll post back if I notice any other strange effects that result from this change.



  • There's only one issue that I've noticed. In situations where the player can move both laterally and fall down, there's a "jitter" that can occur where it'll sit on the corner of the block and just sort of vibrate. This seems to be partially due to trying to fit a 16x16 player into a 16x16 hole - reducing the player size to 14x14 fixed it in most situations, and further reducing the player size to 12x12 removed it everywhere.

    Regardless, this behavior seems preferable to the buggy blocking described previously.

    Here are a few examples.




  • yes, also, when using tilemapExt import for sloped tiles there is a jitter bug. I am using 32x tiles and 28x sprites and the jitter is still there. to fix, you could use an overlap tile that is invisible and use that tile overlapsAt on all those slope tiles but not the corner ones. that's how I fixed the jittering.



  • @galoyo We aren't using any sloped, or non-rectangular tiles.



  • @NoahWilson ok. I thought maybe that information would help you or someone else reading this topic with jitters and other bugs. :)



  • I ended up writing custom logic for the player that detects and corrects jitter. Not ideal, but it works well enough.



  • This post is deleted!

Log in to reply
 

Looks like your connection to HaxeFlixel was lost, please wait while we try to reconnect.