Quote:

Please note that this is likely to break existing code if you explicitely set forces/torques in your script.
-----------------
Marco, I'm guessing that would be EVERYONE using the PE?


Not necessarily; my car script only used gravity and constraints and thus is frame rate independent. (It's when I added jumping to that script that I noticed the bug). So if you only rely on constraints you're fine.

Here's how the system works:
every force/torque manually applied to bodies gets stored in an accumulator to later be executed. Once all current functions have been executed (i.e. terminated or reached a wait() statement) the physics engine is taking over and has as its input the time expired since last update (e.g. 1/35th of a second). It then splits this time into slices of 1/70th seconds (2 in this example). The simulator then applies the stored forces/torques, gravity and calculated constraint forces for each time slice, polygons get rendered and control is returned to C-Script.

Notes: Physics time is sliced to increase stability, and should not be tied to render time. The size of the timeslices is controlled by the variable PH_FPS_MAX_LOCK and defaults to 70 (Hz). Higher values means more stability and CPU time, lower values equals less stability and less CPU usage. In the current A6 release the user force accumulators would get reset to 0 after the first time slice (that's the bug), which means that when your rendering frame rate is 70 Hz or higher you won't notice any problems. If it is less than that, for each render frame multiple physics frames will be executed, but only the first of these has your custom forces, whereas all of them have gravity and constraint forces. In my jump example on a slow system the car would jump up for one frame and then fall down for two. The next A6 release will have custom forces applied throughout the interval, during each time slice as it was meant to be.

Quote:

If the above is the problem, I would suggest a scheme that explicitly ties in the Physics and Graphics clock in discrete intervals. For example, so you can set the PE clock to run twice as fast as teh Graphics clock when accuracy is desired or half as fast if your simulation values performance over accuracy.

You can do that and it has always been like that. Just change PH_FPS_MAX_LOCK. However, when using custom forces the results may be off until the mentioned bugfix has been added.