Platform/Solid collisions not triggering for specific y pos.

Report Construct 2 bugs here.

Post » Thu Sep 10, 2015 1:31 pm

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
Last edited by Refeuh on Mon Dec 28, 2015 6:37 pm, edited 4 times in total.
Image
Game Producer & Independent Developer - http://raphaelgervaise.com
B
24
S
9
Posts: 240
Reputation: 2,238

Post » Fri Sep 11, 2015 1:40 am

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
Last edited by Refeuh on Mon Dec 28, 2015 6:36 pm, edited 1 time in total.
Image
Game Producer & Independent Developer - http://raphaelgervaise.com
B
24
S
9
Posts: 240
Reputation: 2,238

Post » Fri Sep 11, 2015 12:56 pm

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...
A big fan of JavaScript.
B
76
S
20
G
76
Posts: 2,284
Reputation: 47,552

Post » Fri Sep 11, 2015 1:04 pm

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.
Image
Game Producer & Independent Developer - http://raphaelgervaise.com
B
24
S
9
Posts: 240
Reputation: 2,238

Post » Fri Sep 18, 2015 2:16 pm

hello, I tested here capx file, but did not really understand the problem happens,
this is a real bug.
B
28
S
7
G
1
Posts: 78
Reputation: 2,253

Post » Fri Sep 18, 2015 2:18 pm

I could not solve the problem, really that Y position specifies the object does not collide.
B
28
S
7
G
1
Posts: 78
Reputation: 2,253

Post » Fri Sep 18, 2015 3:12 pm

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
Image
Game Producer & Independent Developer - http://raphaelgervaise.com
B
24
S
9
Posts: 240
Reputation: 2,238

Post » Fri Sep 18, 2015 4:49 pm

@Refeuh - I think your analysis is probably correct, not my previous thought. Inconsistent - but consistently inconsistent collision registering....
A big fan of JavaScript.
B
76
S
20
G
76
Posts: 2,284
Reputation: 47,552

Post » Thu Sep 24, 2015 9:35 am

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"
Image
Game Producer & Independent Developer - http://raphaelgervaise.com
B
24
S
9
Posts: 240
Reputation: 2,238

Post » Thu Oct 15, 2015 1:58 pm

Your linked .capx has 138 events. This is far too many to consider for a bug report. Did you upload the wrong file?
Scirra Founder
B
402
S
238
G
89
Posts: 24,628
Reputation: 196,023

Next

Return to Bugs

Who is online

Users browsing this forum: No registered users and 1 guest