Can't set Physics velocity sometimes

I made a very simple slingshot game to learn Construct2, but when the projectile is released, usually the projectile just drops straight down (as if Bird.Physics.VelocityX and VelocityY were set to 0). I would be posting in a different group to figure out what I had done wrong except that a different, similar program written by someone else exhibits the same behavior; a lot of the time, the projectile just falls straight down out of the slingshot. But, there does seem to be some kind of difference because the projectile falls out of the other person's slingshot maybe half of the time whereas my projectile falls down most of the time.

To try to debug, I added a text box that is set to str(Bird.Physics.VelocityX) just after the Bird's VelocityX is set. Strangely, it always displays correctly (a number between 0 and 600), but the Bird often just drops (as if Bird.Physics.VelocityX is 0). How can the bird possibly fall straight down when I've verified that its Physics.VelocityX is large? My only conclusion is that this must be a bug in Construct2 that sets Physics.VelocityX to 0 after the event.

I'm using release 103.2 64-bit (downloaded yesterday) free version, rendering with OpenGL 4.1.10750 on an ATI Radeon HD 5700 Series (shader language 4.10). The file for this project is here. To reproduce, simply click and drag the character backwards and down, and then release. Repeat 10-15 times to see how often the problem occurs.

The physics basics tutorial strongly recommends you do not use 'set position' and 'set angle' on objects using the Physics behavior, because in order to keep up Construct 2 must tell the physics engine to teleport the object in the physics world. This is complicated and for technical reasons has to happen at the end of the tick, and must also override the velocity otherwise the object can start drifting around even when you use 'set position' every tick like you do.

So what happens is you set the object position, Construct 2 marks the object to be teleported and reset at the end of the tick, then 'On touch end' fires, and sets the velocity. At the end of the tick Construct 2 tells the physics engine to teleport the object, and reset its velocity so it actually ends up in the position you asked for. So almost every time the object resets to 0 velocity and falls straight down.

I've managed to find a workaround for this particular issue, so it should work in the next build. But I think there are other problems involved in using 'set position', so I would encourage you to find a different way of handling it if you can.

The tutorial does NOT strongly recommend against using 'set position' and 'set angle'; it says that avoiding them makes things more "realistic". In this case, I'm positioning something before letting physics take effect so 'set position' is exactly the right tool to use. I'm sure I could hack a workaround together in order to not use 'set position', but the real solution long-term is for you to fix the bug.

Here's a fix for the bug you described: when the user has an event that sets the velocity of the physics object, mark the object as having a velocity change. If an object being teleported is also marked as having a velocity change, then set the velocity of that object to the user-defined velocity rather than 0 following the teleport. If the HTML5 defines the teleport to happen at a different time than would make sense for the user, then solve for the change in position between those two times and apply that difference to the teleport target.

Oops, you're right - I meant we generally strongly recommend it on the forum. (The tutorial should probably be updated to reflect that.) Because 'set position' requires a teleport and it's difficult for the engine to keep up with this, it has a tendency to make physics games unstable in general, not only just in this specific example. So we recommend using physics forces for everything and avoiding set position/set angle altogether. While I've implemented a workaround along the lines of what you described, it will not prevent you having other problems based on 'set position'.

Ive seen this topic is super old. But couldnt find another way yet. I understand the reason behind avoiding "set position" when using the physics behavior due to lateUpdate and so. My situation is the following:

Im building an infinite top down game, camera following the player, player can move in all directions. To make it possible to generate new level parts and "forget" old ones, i created a 9 square grid. Whenever the player overlaps with the next tile e.g. up: step one - the bottom row of the level squares positions above the other and then step two - the whole grid is shifted to the original position.

player is on 5, entering square 2:

1 2 3

4 5 6

7 8 9

becomes:

7 8 9

1 2 3

4 5 6

and the whole grid shifts down by one row.

This way you can walk in every direction like on an escalator.

The problem appears now in the second step, when repositioning the grid / everything, the level, assets etc. I also need to reposition the player, that is controlled by physics force.

How can I get such an effect?

Its not possible to position "Layers", also having everything that needs to do the level shift in a "Family" doesnt do any good. Containers dont help. And setting the position of the player naturally sets his velocity to 0.

Any ideas or other approaches? I built a linear endless runner before. Theres tons of tutorials on that. Also on generating levels randomly "beforhand". But not live in all 4 directions.

Would love to hear from anybody. Any help is much appreciated.

Best,

Chris

I found a solution :)

i stored the player.physics.velocity.x and y and angular velocity in three variables.

My plan was to save them just before the "shift" (see post above) and reapply them right after the repositioning. But I still got weird results.

I disabled the physics behavior just after saving the variables and enabling it right after the shift. Works like a charm ;)

Hope this might help anybody in the future

Best,

Chris