Platform/Solid collisions not triggering for specific y pos.

Problem Description

Top/bottom collision between a falling player controlled object (Platform behaviour) and a static Solid object consistently does not trigger when the Solid object is at a very specific location

Attach a Capx

Minimal capx with only 3 object types and 5 instances :

https://dl.dropboxusercontent.com/u/526 ... onBug.capx

Description of Capx

Minimal sample scene : 1 ground, 1 player, 3 blocks

• brown = static Solid used as ground
• yellow block = player controlled, uses the default Platform behaviour
• red block = static Solid (could be an enemy, a platform, etc.) to demonstrate the bug

Logic is simplistic : flash the player object (1second) when an Enemy/Player collision is triggered

Steps to Reproduce Bug

• Move right and jump on the first block (#1) ; notice a collision is triggered and the player object flashes as expected
• Wait for the flash to stop
• Jump right onto the next block (#2) ; notice the player object doesn't flash as a collision is NOT triggered
• Jump right onto the last block (#3) ; notice a collision is triggered and the player object flashes as expected
• In the editor, move red block #2 (the one not triggering the collision) up or down a bit ; test again, this time it does trigger the collision properly

Also notice that collisions from the sides (left/right) or from below (player jumping into red block #2 from below) always work consistently

This unexpected "falling/top collision" behaviour only happens when a red block is at y=524 ; there are other specific y values showing the problem as well but I believe they are all instances of the same issue

Observed Result

Collisions are not triggered consistently depending on the position of the objects

Expected Result

Collisions should be triggered consistently regardless of the positions of the obects

Affected Browsers

• Chrome: YES
• FireFox: ? (don't have)
• Internet Explorer: ? (don't have)

Opera: YES

Edge: YES

Operating System and Service Pack

Windows 10 Pro 64b

Construct 2 Version ID

212.2 64b Steam

Edit: updated affected browsers

I've exported the test scene and uploaded to dropbox, if it's quicker to review the bug without downloading / opening / running the capx before looking into the issue.

https://dl.dropboxusercontent.com/u/526 ... index.html

All 3 red blocks are instances of the same object type ; the red block in the middle never registers a collision when jumping onto it *only* because it's at a specific y position. See original post for addition repro info

I suspect that this may not be a bug. The platform behaviour is designed to prevent platform objects from overlapping objects with the solid behaviour, while the collision check checks for an overlap between two objects' collision polygons. So, if there's no overlap (platform behaviour doing its job) then there will be no collision...

One way or the other, it's still inconsistent - some Solids trigger a collision while some other instances don't ? And simply moving Solids that don't trigger collisions suddenly changes the behaviour.

I think I am using the Platform/Solid behaviours as intended, but the result is inconsistent.

Maybe Ashley can comment on the exact intended way to use/combine these behaviours, if that's not a bug

My guess would be that is has to do with space partitioning and cell boundaries during the collisions broadphase, if there's one ; objects sitting on the boundaries not handled properly would explain that sort of logic. Though it's a total gutfeel.

hello, I tested here capx file, but did not really understand the problem happens,

this is a real bug.

I could not solve the problem, really that Y position specifies the object does not collide.

Yeah, it happens for a collection of very specific Y values ; these must be corner cases that are not dealt with properly in the collision logic

Refeuh - I think your analysis is probably correct, not my previous thought. Inconsistent - but consistently inconsistent collision registering....

No rush, but it'd be nice to have a confirmation on this bug ; the only work around at the moment is to modify the level design to avoid these "corner cases"

Your linked .capx has 138 events. This is far too many to consider for a bug report. Did you upload the wrong file?

Ashley : my apologies ! I recently cleared some old links I submitted in the past for other bugs/demos and it seems I mixed a few things :/

Correct .capx for this bug : https://dl.dropboxusercontent.com/u/526 ... onBug.capx

You'll be delighted to see it only has 6 events <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy"> Thanks for finding the time to look into this !

Refeuh - Hello,

Colludium nailed it, The platform behavior is solving the collision as best as it can before you get to even test overlaps. Its not a bug at all and it actually is consistent in what it is doing and why.

When a collision is resolved in construct 2, there is a certain level of error due to floating point calculations and the type of resolution being performed. If it were guaranteed that collision objects were on a grid pattern and were square, you could calculate resolution perfectly... but as it is there can be up to a 10th of a pixel of error. You can google floating point math errors, and polygon collision detection to get an idea whats going on here.

On the second badguy, the collision resolution phases of the platformer behavior pushes the player completely out of collisions and then some. It all has to do with how far the object intersected the solid and the type of "push out" that was performed.

I have had to deal with this a ton in my game, but it isn't a problem that is game ending. You can simply create another animation (OverlapTest) and a frame for your player object that has a collision polygon that is 1 pixel larger than your polygon normally used by the platform behavior. On the rendering side of things, Your player object should be slightly larger than your collision object. This way you get the whole narrow escape but no unfair hits aspect to your game. Let me know if you have any questions regarding this.

Ashley - I believe this is all correct and similar to something you told me several years ago, please correct me if I am wrong.

The "solid" behaviour needs the collision information to resolve object overlaps anyway ; that's how all discrete or continuous collision detection systems work. Preventing object overlap should still register a collision, otherwise it makes the behaviour useless to write actual gameplay logic.

Floating point math errors are a known problem, and while actually solving collisions can always be difficult and lead to degenerate cases, registering collisions should be consistent.

I still believe the specific y positions hint at a physics cell boundary issue.

Bump -

Not that I really care for a fix, but I'm wondering if anyone had a chance to confirm what's actually going wrong with this

It looks like it's got to do with the collision cells.

The layout is effectively split in to cells the size of the window.....

...Now when checking for collisions with an object, it only needs to check all the other objects in its cell

Your window height is 104 so each collision cell is 104 pixels high. The problem in the capx occurs at y = 520, a multiple of 104. You can see the same problem when the collision happens at 104, 208, 312, etc. It looks like the two sprites are in different collision cells and so no collision is registered.