[r150] Physics Enabled/Disabled

I apologise if this has already been reported or is just a known problem with no fix, but it's popped up in three different cases for me, and it's reproducible. :P

Link to .capx file (required!):

dl.dropboxusercontent.com/u/7765312/C2/BugPhysicsEnableDisable.capx

Steps to reproduce:

1. Open Capx.

2. Watch as the blue square falls through the top platform.

3. Click "Set Y to 0" to move Blue square back to top

4. Watch as the blue square now lands on the top platform (should fall again)

(I tried Trigger once, and foreach loops, all give the same result as this)

Observed result:

After moving the square back up, it will always land on the top platform

Expected result:

Blue square should ALWAYS fall through the top platform and land on the bottom.

Browsers affected:

Chrome: yes

Firefox: yes

Internet Explorer: no

Node-Webkit: yes

Operating system & service pack:

Windows 7 64bit

Construct 2 version:

r150

I'm not sure what we can do about this; it appears the physics engine doesn't ask if it should collide again after you set the Y, so it's still using the old result. Our code appears to have updated correctly, but the physics engine is not asking for an update. My best guess is that setting the Y to 0 effectively teleports the object through the obstacle, which breaks it because you've forced a physical impossibility upon the physics engine. Can you reproduce it without teleporting objects?

Ashley

Hah yeah looks like your right, instead of using "Set Y" and using impulse to push it upwards, it works fine! However, and I'm guessing this is just a physics limtiation, but upon adding another object (and a few "ForEach" actions), it seems that all objects will copy the last objects collisions. Capx

Out of curiosity, howcome the physics behaviour allows you to disable collision from individual objects, whilst the general collision for sprites only allows ALL collisions to be enabled or disabled?

I've come across 2 different scenarios where fine control over collision would be really useful, one involving regular collisions, and one for physics collision.

1. Jump thru + physics. My platformer game has objects scattered around with physics behaviour that can be thrown about. The game is working very well (fully aware we should never combine physics+platformer behaviour :P), but if there is a Jumpthru platform (which would have immovable physics behaviour on it), the object wouldn't be able to go through the platform as it's travelling up. Having control over the collisions would allow me to disable collisions with jumpthrus whilst the object is travelling upwards, and enable them when travelling downwards!

2. Portal style game. One major important thing would be disabling collisions with walls/floors as one is overlapping a portal, but not disabling all collisions as there needs to be a small amount of collision on the edges of the portals (Otherwise when you overlap a portal, you'll just fall). I ended up making a platformer engine with JUST physics to try and make this miniature portal game, and the collisions were crazy and seemed very unpredictable. I should have kept that capx but gave up and didn't save it :P

Collisions in physics are enabled or disabled for entire object types. It's just for efficiency, otherwise the engine ends up carrying around huge tables of which instances are allowed to collide with which other instances. You could come up with alternative implementations of both your suggestions by temporarily disabling the physics behavior instead of using the 'disable collisions' feature (and you can disable the behavior for individual instances at a time).