Physics freezes but box2D carries on when using output menu (console)

During the process of making my game I’ve realised that codea pauses all drawing when using the console (probably to make sure it doesn’t lag) and this does not freeze box2D in the process. This means all applyForce and velocity operations aren’t sent through but the box2D engine still updates its own velocities. Thus causing my player to fall over when the output menu is used (scrolling through output box or parameter box) and jolt back up when the scrolling starts again. This is leading to other problems IMO (the way codea and box2d interact should be constant) such as when reading a large file, the same happens. I have one idea of how this might be fixable. Add a physics.pause() statement at the end of each draw function and add physics.resume() at the start… I think. Has anyone found a way around this?

Yes I found other such bugs like music still playing when codea is paused and the touch function being called even when codea is paused. as to your solution it depends when box 2d does it’s calculations

I believe physics works by each time it is called taking in the Deltatime since the last frame draw, and then executing as many physics iterations as need to pass the amount of physics time to catch up with the draw cycle. It does this so physics always runs at the same speed as the clock, even if framerates are variable. Your output window interaction is really just an extreme version of a large framerate drop.

I’m not sure if you have tested the pause and resume approach you have suggested, but I would suspect that this would either cause physics not to process at all, or it would end up with no difference to the way it operates without those commands (depending on how it’s actually plumbed internally). But the best way to check would be to just try it.

@spacemonkey you were right on my pause/resume approach this does not work as box2D has its own timestep. if I used DeltaTime (which I do) it would not make a difference as there are still no applyforce calls coming from the draw function, meaning the body is only affected by gravity. I understand this is a framerate drop so if I were able to detect the time that the frame had been on for (not the time since the last frame because that is only recorded once the current draw function finishes) then depending on whether other function calls work I could possibly use tween to read that variable of time. I don’t think that’s possible though as Codea ‘freezes’ between these frames.