Thanks for spotting that! I actually have no idea why it was that way… Anyhow, I will make sure to update the package asap. Thanks again.
EDIT:
Let me think aloud 
.
After looking into the code, this issue seems a little strange to me. I can’t really reproduce it though, because I’m on a quite slow machine, so I generally have low framerate (I did try it on faster machines though and it seemed right…). Anyway, here’s what bothers me.
Your suggestion seems correct, however, it should not be needed. A few lines above the one you posted there’s this:
speedVec = Vec3(self.speed[0]*stepSize, self.speed[1]*stepSize, 0)So the speed is, in fact, multiplied by stepSize (not in the best way, I admit), which should make it constant regardless of the framerate. I do notice, that this is not the case (especially with very low FPS), but this problem also applies to the rest of the simulation. I.e. when the framerate goes down, the speed of stuff falling down, exploding and so on also goes down as well.
That’s, as far as I can tell, probably caused by the way Panda deals with repeating doMethodLater tasks, such as the one I use for stepping the sim – the real interval between the calls is just not exacly what you set it to be, but rather what the system can keep up with (which shouldn’t come as a surprise). Or that’s related to how Panda calculates the time – whether it’s real time or some interpolation, or whatever, I have no idea how it’s actually done.
Anyway, if I do the change you suggest, the character basically starts moving a lot too fast. That’s because of the 100 value. Can you tell me why you see that as necessary?
Also, maybe you’ve removed/changed the line I posted in the code tags? That would explain the need to multiply by stepSize (but not the need to multiply by 100). Otherwise, I don’t see how that would solve the problem.