LittleStain -Small variations occur when using dt (Like really, really small). In a physics simulation puzzle game this small fluctuation in dt can produce a chain of events that compounds to produce a drastically different result than was acquired last time the exact same thing was done. In these types of games, using time frame independent physics doesn't make sense.
dt is calculated based on how long the last frame took. The current frame might not take that long - but in the end it averages out to 1 every second. The variation from frame to frame could yield results that vary, but we are talking minute fractions of 0.02 (depending on framerate). In reference to the above situation, this could be undesirable. But in a game such as asteroids with physics, this variation in dt is largely irrelevant. As far as the game goes and feels everything is still "predictable".
My tests involve a simulated force of gravity acting on an object and an impulse based jump. The degree of variation in using dt in time-frame independent physics in my test is relative to what dt is and not a small difference. In other words, as the framerate increase, the force of gravity acting on the object increases over time. As frame rate drops, the force of gravity lessons over time. This indicates that dt is already applied to the physics internally and needs not be applied again. If you cut frame rate in half, gravity decrease by half.
When running framerate dependent physics, frame rate only affects our perception of time passing but doesn't affect the actual game. If you apply dt to this model of physics you can get the same result as was described above, though "time" to reach max height after impulse was different, the height was still the same. I used impulse vs force to be able to compare maximum height obtained when applying a force in the opposite direction. I did this to take "human perception of what is happening" out of my experiment.
If you remove dt from timeframe independent physics calculations within the event sheet, you get the expected results; that is, regardless of framerate, the object reaches the same "highest point" in the same "real time" after leaving the ground under an impulse and affected everytick by a constant force.
This is in CONTRAST to what the manual states, indicating either an error in the manual, or an error in the implementation of physics in construct. My hunch is that the manual should be changed to reflect the actual state of box2d in construct.
....and by the way, just for clarification... I have worked with box2d outside of construct2 in other applications (XNA in C#, Unity in C#, Torque C++) and I have also read most of the box2d manual and understand the API in addition to reading a lot of the source code and understanding the theory behind collision detection in box2d. I have rolled my own collision detection before. Don't think I am speaking out of ignorance. I posed this problem as a question because I believe Ashley is a very competent programmer (and a wizard) and I looked for input and guidance before outright saying I found a discontinuity between Box2d/Construct2internal/Construct2 Manual in case I am wrong/confused. The more time passes and the more I tinker with this the more I believe that If Ashley says to use dt in events with timeframe independent physics then there is a "bug"; If he says not to use dt then the manual needs to be updated for clarification.
I would find it odd that I am the first to find this problem but it seems that may be. In any case it is really difficult to test due to lack of frame rate control. I had to spam thousands of objects in order to get a drop in framerate to test changes.
Also I may have found a bug in timescale and physics (when timescale is 0, force is still applied everytick in a building manner, such that when timescale becomes greater than 0 all the force added to the object over the last frames is added all at once in one frame... but I need to run further tests.