Collision bug with stacked sprites

[zhelezkov]

HaxeFlixel has a quite weird collision checks. (The main problem in function separate I think). And it has to be fixed. Here's a demonstration of a horrible bug with collision: https://github.com/RedSQ/flixel-collision-issue. Blocks are starting falling under each other. The code has nothing special.

Ideas for improvements: Make a different collision types for collison objects, like a: FIXED, ACTIVE, LITE, PASSIVE. It would be very comfortable to work with. LITE entities only collide with ACTIVE or FIXED entities. FIXED entities will collide with LITE, PASSIVE and ACTIVE entities. So, it would give a more flexible collision system.

[SeiferTim]

There are a couple of things you could try in order to make this work. You mentioned one of them in your demo (setting acceleration to 0 when they hit the floor). You could also set objects that have something under them to immovable = true.

The issue with the current collision system, and separate, in particular, is that it's very basic and simple because it's quick, and 99% of the time, it's more than sufficient - at least, I've rarely had to mess with it.

That other 1% though, can be tricky since it's not very easy to get in and tweak it or substitute it's logic with your own, although by doing those little 'hacks' in the places where you have problems, you should be able to make it behave the way you want.

Now, I'm not saying that there's nothing wrong with the separate logic that couldn't be tweaked, but if there's anything to change there, it should be (relatively) minor, and not a total overhaul, as you proposed. Adding all these different flags and things like you suggest seems complicated and would not be as simple or elegant to explain or use for the general usage.

One last thing, in your demo, I would actually not want to use collide for this case anyway - I would do a simple overlap function that checks when 2 objects overlap and then just move the one has the lowest y so that it is just above the other one.

[gamedevsam]

Alternatively, you can use Nape as the main collision system, using flixel's native collision system to do basic overlaps tests. That seems to be the route most people take.

[MSGhero]

^+1 nape is better than anything us mere mortals could write

[sruloart]

Nape is great, but it has some quirks when you set it to use really high numbers (the gravity here is 20000, watch the white box and remember that the floor is supposed to be solid): http://www.filedropper.com/gravitas (It's debug-enabled for your pleasure, it won't tell you too much though).

[MSGhero]

You have to enable continuous collision detection for "bullet" objects. I've never used that high of a number, but it works with kinda high numbers for sure.

[sruloart]

CCD's are enabled by default, so that's a bug as far as I can tell. My point being, Nape is a lot of fun, but it's not a magical solution for HaxeFlixel's collisions, as there are some drawbacks for using an entire physics engine in EVERY game, especially for some really minor stuff (like jumping on the ground). If it's simple, keep it simple.

[SeiferTim]

100% Agree, @sruloart

[MSGhero]

It's disabled by default, otherwise nape's performance would suck: http://napephys.com/docs/types/nape/phys/Body.html isBullet is false.

[sruloart]

@MSGhero yep, you're right! but in my (poor) defense, I didn't understand why this exists: player.body.disableCCD I mean, why should I disable it if it's not the default behavior? :{

Contrary to my pride, my general point is still valid. I think.

[MSGhero]

Yeah your point is valid, it's just that nape is the best haxe lib for any non-basic collisions. The original post should still be looked into, though, in case it's a bug and not a limitation.

[SeiferTim]

@MSGhero It's not a limitation, it just requires that you setup your objects 'correctly' for the behavior you want to achieve - like anything else. Using the default, built-in collision logic is just as viable a solution as implementing the Nape plugin, if that's what you choose to do.

[AndreiRegiani]

Referred on our forums: https://groups.google.com/d/msg/haxeflixel/8Mo_mrpUDXk/jl9D6-nXKukJ

I wonder if that would do the trick. Can anyone test this issue with that change? (@RedSQ, @Gama11 ?) I don't have a HaxeFlixel setup at the moment. But for separateY() instead of separateX().

[danim1130]

Note that until a more permanent solution, you could call FlxG.collide() multiple times to solve the bug (calling it four times solved the problem for me).