-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Overlap doesn't appear to account for empty space and overlaps them with ground #7
Comments
Interesting! Thanks for such a clear explanation. If you have a way of setting up something like a codepen that I could use to diagnose this I'd be happy to look into it. Something that jumps out at me immediately:
This is being set after enabling physics bodies for the particles of the emitter. Could it be that the body of each particle is larger than you expect? Perhaps you could find away to draw debug output for the bodies of currently alive particles, just to get a better visual of what's going on. Might be helpful to do the same for the tilemap at the same time. Unfortunately the plugin itself doesn't yet have its own debug output for all the polygons and vectors involved in the collision handling, but that is on the roadmap for 0.2.0 (#4). |
Some of the particles in the example have a similar issue.
This should allow for the particles to come out of the player and when they overlap the ground be killed. |
Very interesting! I will absolutely investigate this at some point, thank you for highlighting it so well. The plugin is probably not handling the |
Ok so I don't really understand the consequences of my actions but I got it to kind of work now. Go to this line:
Replace the if statement with the following: if (! overlapOnly && collideCallback) {
collideCallback.call(callbackContext, sprite, tile);
} |
Hmm, okay. That's interesting, because that branch passes handling to Arcade Physics to handle normally, if the tile doesn't have a Except the callback should still be called in the case of an overlap. The code you've linked to is meant to mirror this, to an extent: https://github.com/photonstorm/phaser/blob/master/src/physics/arcade/TilemapCollision.js#L63 Except I decided to break it down a little more to avoid code repetition. But perhaps the Also, love that the Lenny face is in the example GIF, haha. What do you use for screen capture? |
LICEcap One of the most useful tools ever for showing people stuff! |
I totally managed to reproduce the issue above, but even after completely disabling the plugin. This might be an issue with Phaser itself, and not the plugin. |
Okay, so this technically isn't a bug (but I think it is). The callback is working as expected because the sprites are indeed overlapping a tile. The problem, as highlighted in the GIF, is that these tiles shouldn't collide and have an index of -1, but Phaser doesn't say anything about To work around this, you can add a process callback.
This will still check the overlap, but only for tiles that can collide. It should give the result you're after. Collision process callbacks in Phaser are a check that let you decide whether to actually continue with the overlap/collision based on the result of your own callback function. In this case, we simply check whether the current tile is meant to collide with anything. Feel free to let me know if this resolves all of your issues. 😃 Also, technically, this means my plugin is incorrect, because it will bail out from |
Oh, and thanks for showing me LICEcap, it's fabulous! ✨ |
It totally worked! I didn't get a chance to really test it a lot but immediately I was able to shoot again! :) |
Just a heads up for closure on this, it's works awesome! |
Awesome, thanks for letting me know. I did close this pre-emptively but I had a gut feeling that this was the cause of all your issues. I thought maybe something else would be causing the sliding/missing tiles, but assumed these were different attempts to get it working and ultimately you just wanted the correct overlap responses. :) Glad it works so well! I look forward to seeing your project progress. |
UPDATE
See down the conversation, the collide behavior looks like it's correct but you can't use overlap yet.
#7 (comment)
OLD
The bullets hit the 50% slope and slide up.
The bullets go straight through and if you're shooting through a 10x10 the bullet will enter one side and collide with the opposite side.
This is how I create 50 reusable bullets.
This is how I fire a bullet.
This is how I collide bullets with the slope ground.
Normally I use overlap though.
but this has been happening.
The text was updated successfully, but these errors were encountered: