Can't set Physics velocity sometimes

Bugs will be moved here once resolved.

Post » Sat Sep 15, 2012 8:22 pm

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.
B
3
Posts: 6
Reputation: 337

Post » Mon Sep 17, 2012 4:34 pm

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.Ashley2012-09-17 16:35:13
Scirra Founder
B
359
S
214
G
72
Posts: 22,946
Reputation: 178,478

Post » Mon Sep 17, 2012 5:21 pm

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.
B
3
Posts: 6
Reputation: 337

Post » Mon Sep 17, 2012 5:53 pm

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'.
Scirra Founder
B
359
S
214
G
72
Posts: 22,946
Reputation: 178,478


Return to Closed bugs

Who is online

Users browsing this forum: No registered users and 0 guests