godotengine / godotengine/godot
Apply_floor_snap() method of CharacterBody3D does not update the velocities after the snapping.
- Dominant language
- C++
- Stars
- 117k
- Forks
- 26.8k
- PR merge metrics
- PR metrics pending
Description
### Tested versions
4.2.1 stable. reproducible since the method was introduced.
### System information
Fedora workstation
### Issue description
When the discussions about the new `CharacterBody3D` were taking place, the necessity to snap the character regardless of the up velocity resulted in the `apply_floor_snap() `method by fabriceci (https://github.com/godotengine/godot/pull/73749). Now that we are working on a full refractioning of our game Liblast, i had the time to test it's functionality.
After quite a lot of head scratching, I think I isolated the problem.
The method is meant to force an snapping of the body to the floor even if there is vertical velocity applied. The body snaps correctly, but it's velocity never takes that into account. As a result the body will remain snapped, but it's vertical velocity will continue increasing as if the snapping never happened. This leads to an accumulation of vertical velocity on the body, making it jump when the delta velocity on the vertical axis scape from the snapping vector.
### Steps to reproduce
I made my best to reproduce the issue in the following MPR. The character body starts above the floor and falls down due to gravity until it reaches the floor. Once we have reached the floor, an small vertical force is applied. The character remains still until it scape and jump after around 4 seconds.
### Minimal reproduction project (MRP)
[Apply_floor_snap bug.zip](https://github.com/godotengine/godot/files/14157203/Apply_floor_snap.bug.zip)
Contributor guide
Research direction
Start with CharacterBody3D.apply_floor_snap() and reproduce the behavior using the linked minimal reproduction project. Compare the body's velocity after snapping with the reported vertical-velocity accumulation, and verify that the character no longer jumps after remaining snapped for around four seconds.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp, godot
- Domain
- game-dev
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100