I feel the same way in regards to the frustration and the lack of patience at this point. It has been two years since the physics engine was released. Bugs need to be fixed before new features. Period.

At this time, I am not aware of a work-around for the current bug. The code given above reduces/eliminates the explosions, but it introduces the slowdown effect. This effect is not minimal and it is basically unusable.

@Conitec: Please fix the current physics bugs before adding new features! Pretty please with lots of sugar on top.

Jason

Quote:

---

I hope it does. Currently the movement of physics objects is not interpolated between physics frames, which leads to some of the problems I have mentioned earlier. Once this interpolation is in place I want to check this falling behavior again as the two might be related. I do not have a time estimate as to when this will be done.

---

Have you finished the interpolation for the physics objects yet? I'll be needing this as soon as possible... if you need someone to test it I can. Currently, I am having trouble with my powerslides(they use forces), and my steering. There are multiple jerks when the framerate is lower... this is very frusterating; I need to visualize and tweak the gameplay as a whole without all the jerks.

I also have a question about forces in general. Should I multiply the value i'll be using in something like phent_addcentralforce() by time? Or does a force automatically multiply its value by time regardless? Thanks.

Forces are not automatically multiplied by time. When they are applied for one frame only, their effect depends on the frame rate without correction. Alternatively, add a velocity instead of a force.

- Of course we always fix all bugs before implementing new features. However, fixing a bug often requires a new feature, as in this case, physics movement interpolation.

But even without this the physics engine is very stable. You just have to keep in mind to maintain a constant frame rate for using physics. When experiencing a frame rate dependency, set fps_max at a low enough value to avoid frame rate variations.

Okay, I have made a large number of changes and bugfixes to the physics engine and the timings appear to be constant now for framerates from 25 to 300 (beyond that precision would get flaky so it's a hardcoded limit).

Rereading the posts, though, I am still not sure that I understand the various problems that were mentioned. Thus, if you have sample code that currently exhibits timing issues when run at different fps_max rates, I would like to run it with the beta for comparison. -> mgrubert@conitec.et

Thanks for the update! I'll be looking forward to the next beta.