change size without stopping physics

0 favourites
  • 13 posts
From the Asset Store
Simplistic hyper-casual game with nature elements. Tap to switch between the 4 elements and reach a better score.
  • well my game is using the power shot like in this tutorial here: scirra.com/tutorials/178/bullettime-charge-shot and im trying using a physics object instead of a bullet. So when it's charging its on layer 1 and starts to change the size (bullet.Width + 0.5, bullet.Hight + 0.5) then on mouse release it moves to layer 2 and changes the size to (bullet.Width - 0.5, bullet.Hight - 0.5) but it stops in midair and decreases size. Anyone know why?

  • Hard to tell without a capx.

  • http://dl.dropbox.com/u/52562580/bowlBombing%20%281%29.capx there ya go :3 thx you seem to be very helpful and active.

  • Seeing your capx I don't understand what the problem is.

    I don't experiment a size decrease (and nowhere in the code is there such a thing anyway).

    Also it doesn't seem to stop in midair.

    Tested in chrome 16 and firefox 9.0.1.

    Could you please give more informations/details.

    Or maybe is it not the current capx you're experiencing trouble with ?

  • well I removed the few lines where it decreased, basically the line that allows it to increase in size was reversed, so that if it was greater than 81.92 it would decrease at the same rate that it increases while being fired. Once it starts to do that it stops midair, decreased in size, then moved along its course.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • I had the same problem earlier. I had an object shrink when overlapping another object with physics on. The object just seemed to freeze in mid-air, and then shrink indefinitely, even though the object was only meant to shrink on collision by 1 pixel.

    Sorry I couldn't figure it out, but you're not alone!!!

  • http://dl.dropbox.com/u/50465867/WeirdShrink.capx

    An example I quickly pulled together, just to show what I mean. Should it stop in mid-air like that?

  • AnD4D: yes, as the capx is setted up it's normal.

    Let's "translate" your code :

    Every tick, when Sprite2 is overlaping sprite, we set sprite2 width to sprite2's current width -1. Same for height.

    As long as sprite2 is overlapping sprite, it will shrink.

    How events work.

  • We fixed a bug where Physics objects would stop if you changed their size ages ago. Are you lot not staying up to date? Does this definitely happen in r76?

  • Hi Kyatric,

    In my example, I wanted it to shrink whenever it collides, so it's correct the way it works. What I didn't want was the physics to stop.

    I'm pretty sure I'm up to date... at work (lunch... :p) ATM, so I can't check, but I'm pretty sure it's the latest version... I recall having families.

  • Ashley: r76 here.

    Nevertheless even if I thought the behavior in AnD4D was an optical illusion (the sprite is moved/shrinked at the same time => gives the impression it does not move), check with this capx.

    Apparently the shrinking "blocks" the red sprite movement (in that case, straight falling, black sprite hasn't any behavior).

    I've modified the values to make it obvious and I would have expected the red sprite to keep on falling through the black sprite, shrinking, not getting "blocked" on it.

    Or I am missing something here.

  • Nope, that's what I see too! The one I put together was just a quick one. My first attempt was a lot slower and more obvious.

    Sooo... does this count as a bug again? Wonder how that snuck back in!

  • Sorry to revive an old thread, but I'm having this problem too. The example from Kyatric explains it perfectly.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)