Physics (was Events and conditions)

Hi, I have a problem. I think it's due to my limited understanding of Construct.

I want the object to resize when I right click on it. If it's small, it should grow and lose its physics behavior. If it's large, it should become small and gain physical behavior again. And the "small" size is fixed at 32, while the large size depends on the image, and I don't want to lose that size. So here's what I do:

<img src="http://i32.photobucket.com/albums/d7/thepicturesofnayon/cap.png">

What's wrong here?

What happens when you enlarge it? That is right, its width is not equal to 32 anymore.

Events are processed from top to bottom; after that image width equal to 32, where its size is changed, it then proceeds to the image width NOT equal to 32, which passes as true. So it runs BOTH events within the same cycle.

You probably want to make those two events exclusive; otherwise they both run. Try with "ELSE" condition. Or you could use a variable that is reset at end of the cycle.

Yeah! It worked!

But now I have a physical problem... After growing then again shrinking an object, its physics behavior starts acting weird.

It gravitates towards weird directions.

Other objects act weird too.

Is there a solution other than generating a new "large" object on right click and destroying the original, then destroying the large and recreating the small on another right click?

Here, have a cap:

http://www.mediafire.com/file/nnuuz042l54/proj1.cap

I... have no idea what is going on in that .cap

I will say this: Resizing physics objects often leads to bounding box problems. This is a known issue.

What I believe is happening is that the bounding box for your, uh, giant bear macro is glitching out. When you change from large to small, the bounding box is still large, and the small bear macro pushes out of solids away from the black platforms.

What I would recommend is that instead of changing the size of your object, you should destroy your physics object and spawn your larger object in it's place, and vice versa. That way you can preserve your bounding box.

In a future build this probably won't be an issue.