Suppose you move RigidBody2D with applied_force and make it collide with an obstacle. Of course, the Collider is ready to go.
Collision one. It momentarily overlaps the obstacle, pushes back, and stops. Second collision. It stops without overlap.
How can I get rid of this overlap in the first collision?
Have you tried enabling continuous collision detection on the RigidBody2D? That might reduce the chance of the overlap.
Continuous Cd has not been able to improve this overlap. Ray and Shape, the overlap will happen in both.
Hmm, strange. Does changing the physics FPS in the project settings help?
Also, what is the other, yellow Godot icon, node? Is it also a RigidBody2D? If it is a RigidBody2D but does not move, maybe try changing it to a StaticBody2D and see if that fixes the issue. If it is a StaticBody2D, maybe try changing it to a RigidBody2D with the static mode and see if that helps.
Another thing to try could be tweaking the margins of the collision shapes, if the margins are available for tweaking in 2D. Maybe setting a smaller margin will help reduce, if not eliminate, the issue.
There is no change due to the change in physics FPS. The overlap is still there whether I set the FPS to 120 or 20.
The yellow Godot icon is Static, but the overlap is still there. Changing to Static Mode in RigidBody2D also causes the overlap.
I think this is how I see it in my experience. Essentially, overlap should not be shown on the screen during a collision. It should end the frame by drawing the pushed back state. (Regardless of whether it pushes through or not.)
If you can see the overlap, I think the processing is probably crossing the frame. This is a common mistake experienced when creating your own obstacle collision handling. If you do the drawing first and the physics later, the pushed back picture will show up in the next frame, and the current frame will show the overlap.
I've currently written all the input and move processes in _integrate_forces, is there a way to get the input and physics done stably before the drawing?
Maybe try doing the input and move processes in _physics_process? I think _physics_process is called before the screen is drawn, or after, though I am not positive. Outside of that, I'm not sure what could be causing the issue. It might be a bug, though why it is occurring I am not sure.
Yeah, the physics process is what is affected by the physics FPS, might be why it didn't have any effect.
In the case of my homebrew Collision, the pushback process is written in a script, but since the physics process is the job of the Godot engine, I thought it would be impossible for me to devise a solution.
Thank you for all the help. Now I'm sure of it. I'm going to report it to GitHub.
