Physics Behavior Bug - Graphics affecting motion

Problem Description

A Physics (behavior) object falling due to gravity will suddenly "stop" if its being transformed (size changed).

Attach a Capx

https://www.dropbox.com/s/1hsayxk27134kz6/Physicsbug.capx?dl=0

Description of Capx

One square sprite (Physics behavior). Whenever Touch is Down, its width increases.

Steps to Reproduce Bug

• Any Physics behavior
• Transform either its width, height, scale, etc.

Observed Result

At the moment (and while) the sprite is being transformed, it no longer follows "Physics", in fact it just stops there suddenly. In other words, the change in width defies Physics!

Expected Result

Graphics (and change in transformation) should not affect the Physics behavior or motion. Just like the case of animations and rotations, Physics should be independent of Width, Height and Scale as well.

Affected Browsers

• Chrome: Yes
• FireFox: Yes
• Internet Explorer: Yes
• Mobile Devices: Yes

Operating System and Service Pack

Windows 7 - SP1

Construct 2 Version ID

r200, I observed the same in r202, and r195 as well. This problem was apparently there since the beginning.

I don't think we can fix this. When you change the size of a physics object, the behavior is forced to destroy its physics body and create a new one in its place at the new size. It does try to preserve the velocity, but I think when you do this every tick it doesn't get the chance to step it. The thing which defies physics is really that something is completely disappearing and something new teleporting in its place, which is physically unrealistic and probably is why the result is also unrealistic.

Thanks for the reply. Now I understand the reason.

I am wondering if during the replacement of new Physics shape, if it could just save its final movement related parameters (such as VelocityX, velocityY, and the on-going accelerations) and then restore them into the new shape immediately. Would it then appear to continue moving? - Compared to letting it restart from zero velocity, which I believe would be impractical in any game.

By the way, I would like to share how I finally improvised around this problem while I was making a "Paper Throw" type of game, where you need the Physics object to be thrown ahead (in supposed 3D), which requires you to scale it down for perspective effects. Now, scaling would stop it from moving, as I struggled with for days. BUT I improvised by adding an invisible dummy physics sprite which I programmed to be thrown instead, while the actual "Object" is set position to dummy-physics object, and since that Object is non-Physics, I can change its scale any time independently while it follows the X/Y movement of the real Physics object.

I guess this quick trick will help others as well who wants to scale/resize a moving Physics object.

Ashley, do you think that 'replacement' procedure, as I mentioned above, would resolve the problem?