_integrate_forces changes behavior if debug printing

Question

For my game I want a spaceship to become a kinematic body when docking so other spaceships won't knock it off.

This works but when going back to a regular rigid body I experience some glitches, either the position or velocities reset to incorrect values. Trying to resolve this I ended up with the following implementation (I revert the mode to rigid body in the regular _physics_process call when not docking):

func _integrate_forces(state):
    if !dock_locked && dock_state == 0: return
    mode = RigidBody2D.MODE_KINEMATIC
    position = state.transform.get_origin()
    linear_velocity = state.linear_velocity
    var impulse = 0.9 * (dock_position - position) - 0.2 * linear_velocity
    state.apply_central_impulse(impulse)
    state.integrate_forces()
#   print_debug(impulse)

My issue is the above works quite well if the print_debug statement is uncommented! If I uncomment the print statement my spaceship smoothly snaps to the position I want and as soon as docking is interrupted it maintains momentum correctly and keeps moving as normal.

But if I comment the debug print the ship stops moving in place while docking.

Can anyone explain this and help me understand what do I need to do to get the behavior I need consistently?

Thanks!

Comments

I just stumbled on exactly the same problem.

I was going through a very simple tutorial, and noticed a problem with basic game loop. Debugging led me to discover what you did: print statements change program behavior. I get correct behavior with them and invalid behavior with print statement deleted or commented out.

I also notice that presence of print statements seems to impact whether debugger breakpoints around it activate or not (?!?).

Stranger yet, adding multiple print statements in a row seems to affect program execution as well, each time in a subtly different way. That's literally the only thing I change.

This is very concerning. It's the most basic of programs, and already the parser is doing something weird and buggy. It's the kind of thing that makes one drop the engine entirely.

What is known about this issue?

---

I stopped worrying about this a while back (as longa s my builds work).

I do not think it's a parser/compile issue, though. I still think it's a race condition, or in other words, a physics threading issue.

I have not tested on recent builds, but I am hopeful it will be fixed... eventually!

Answer 1

Hi,
the integrated forces function will be called 60 times per second. Printing to the console is awfully slow. So i think the printing can result in dropped physics frames (but thats just a guess) wich would result in different behaviour.

when i have to monitor a varibale with heavy updates i usually put a label onto the screen and a timer. Whenever the timer timeouts the label pulls the variable and displays it.

Comments

Hello, thanks for the reply!

I do understand that logging can be costly, but the part that baffles me is that I get correct behavior when using the log, and I get incorrect behavior when NOT logging!

I wonder if that is a bug (some sort of race condition maybe) or I am doing something outright wrong (aside from logging).

---

sorry, i've missunderstood it. i thought it didnt work when printing to console.

I see a "* 0.9" and "* 0.2" are those damping factors? Those damping is preety high ... when the console printing is dropping frames it get less often "damped" (per second). Have you tried to set this realy tiny? like 0.999?

The only thing in the code i see....

state.integrate_forces()

this is not necessary! and it does some stuff that i dont know (when looking in the sources). i would remove this line.

---

Thanks!

Yes those numbers are just interpolation/damping factors. Changing them does not really affect the issue. Regardless of the changes I do I get incorrect behavior without logging, but correct behavior when logging or in browser builds, I assume because of them being slower?

For now I will put this to rest and work on other aspects of the game.