It’s 30*30*1/50 = 18. Notice the /50 is needed. That’s what I mean by the units of the physics behavior being off. That second capx figures out the conversions between units in the behavior and what it should be. 50 comes up a lot. I think it was mainly due to an oversight when the behavior was made. Position and speed are spot on but most other values are off by some factor. This really only becomes an issue when trying to apply physics based calculations.
50??? 60 I'd understand, but 50? I don't get it.
Do you know how velocity is calculated? I imagine it has that 50 in there again. If I apply an impulse of 1 again on an object with 0 density, I end up with 50. Strangely, I thought that force was essentially a constant impulse being applied, so if I apply a single frame of force, I'd get the same result.
If I could figure out how much velocity the force would generate on a stationary object based on it's current position toward a certain angle, I could add those numbers to the predicted velocities in the loop, and get a more accurate line.
I note that force actually appears to be based on time, so if I apply a single force of 60, I end up with 49.79... so let's say 50.
However, that all becomes a lot harder when you have mass and damping included.
Additionally, while if I give the sprite a density of 0, I get 49.79 after that burst of force, if I instead give it a density of 1 I get 139.16. No idea why an object with more mass would move faster. However, saying that, a density of 2 gives me 69.58.
So that makes no sense. I think you're right. It just seems like someone made a mistake in coding the physics engine...
Update - Just realised, with a density of 0, we get a mass of 50, rather than 0: 30*30*0/50 = 50, which is wrong.