What should I do if I reported a bug but nobody seems to care

rom1dev · May 12, 2025, 1:55am

Godot Version

v4.4.1.stable.official [49a5bc7b6]

Question

Context

I reported an issue some months ago on GitHub:

github.com/godotengine/godot

CharacterBody2D (only in Floating Motion Mode) accelerated by slides

opened 09:33PM - 02 Jan 25 UTC

Rom1-GoPlay

bug topic:physics topic:2d

### Tested versions v4.3.stable.official [77dcf97d8] ### System information G…odot v4.3.stable - Linux Mint 22 (Wilma) - X11 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 (nvidia; 535.183.01) - AMD Ryzen 5 5600X 6-Core Processor (12 Threads) ### Issue description ## with Floating Motion Mode As you can see here, the CharacterBody2D velocity on the x axis is increased as soon as it touches the StaticBody2D. However each frame, the velocity is set to `speed` (a variable that is equal to `Vector2(50, 100)`) so it should never speed up like that (I guess). https://github.com/user-attachments/assets/2615740b-8145-4acd-af8f-a6b9d1320f57 the script of the CharacterBody2D is as following: ```gdscript extends CharacterBody2D ## the vector wich will be assigned to velocity @export var speed: Vector2 = Vector2(50, 100) func _physics_process(delta: float) -> void: velocity = speed var is_collinding = move_and_slide() print(" is_colliding = ", is_collinding) print("x --> real_vel : ", get_real_velocity().x) print("y --> real_vel : ", get_real_velocity().y) print("x --> velocity : ", velocity.x) print("y --> velocity : ", velocity.y) print() # print a blank line to easyly distinguish frames in the output ``` I know thanks to these prints that the x real velocity is around 109 during the slide (instead of 50). I can also say that this depends on the value of the velocity y coordinate: The higher `velocity.y` is , the higher `get_real_velocity().x` will be during th slide. the fact that `velocity` is not updated during `move_and_slide()` is another issue already reported (https://github.com/godotengine/godot/issues/60447) ## with Grounded Motion Mode (expected behavior) https://github.com/user-attachments/assets/cda63e37-6558-46f6-b766-44a8ada58f30 ### Steps to reproduce 1. create a new 2D scene 2. add a CharacterBody2D in **Floating Motion Mode** and with a collision shape as child 3. add a StaticBody2D with a collision shape as child 4. for the StaticBody2D's collision shape, select a rectangle shape in order to have no slop 5. add a script to the CharacterBody2D and set its content as following : ```gdscript extends CharacterBody2D ## the vector wich will be assigned to velocity @export var speed: Vector2 = Vector2(50, 100) func _physics_process(delta: float) -> void: velocity = speed var is_collinding = move_and_slide() print(" is_colliding = ", is_collinding) print("x --> real_vel : ", get_real_velocity().x) print("y --> real_vel : ", get_real_velocity().y) print("x --> velocity : ", velocity.x) print("y --> velocity : ", velocity.y) print() # print a blank line to easyly distinguish frames in the output ``` 6. place the nodes so the CharacterBody2D slides over the StaticBody2D's upper side when yon run the scene 7. run the scene ### Minimal reproduction project (MRP) [issue_demo.zip](https://github.com/user-attachments/files/18294596/issue_demo.zip)

I am surprised because there are more people (and discussions) involved in some more recent issues.

Questions

I am wondering the following:

Which bug reports are prioritized ? Is there criteria ?
Can I do something else than waiting ?
Am I doing something wrong ?

disambiguation

It is important to make it clear that this is not a complaint. Also, I hope the words I use are not unpleasant. I am not a native speaker and I just use the words I find.
I don’t want to denigrate the amazing work of Godot developers, I just want to understand how things are organized.

dragonforge-dev · May 12, 2025, 3:59am

You did everything right. There could be many reasons why it isn’t prioritized. Maybe there’s no one to work on it. If it is important to you to get it fixed, this could be a reason for you to contribute to the project.

rom1dev · May 12, 2025, 7:06am

Thank you !

Do you mean fixing the bug myself ? There are even more reasons for me to try:

an amazing experience (I guess)
the best way to understand how things are organized, I guess.
Learning c++ which is a language I don’t master (never really used it).

However, this last point could also be a reason to avoid doing it. I am not sure to be able to make clean code in this language. It is still recent for me to write GDScript or python that I can easily understand later.
And there is an even more important reason I will not do it soon: I am currently really busy for school and exams. I can do my hobbies only if they bring zero deadlines. And I am unable to predict how next year will be.

Is contributing the only thing I can do ?

Do you know other plausible reasons ?

gertkeno · May 12, 2025, 8:09am

I don’t think this is a bug, move_and_slide is supposed to conserve speed to an extent; and your object is moving with a magnitude of 111.8, which pretty close to the resulting 109 when sliding against the wall. It’s not clear what you expect to happen, if you wish it canceled any “sliding” then that could be achieved easier by using move_and_collide instead of altering move_and_slide.

When grounded this is considered a “floor” so the vertical movement is canceled out by a presumed gravity which keeps horizontal movement consistent, which is usually desired for platformers.

This is also a widely used function, any change to move_and_slide would break many projects and tutorials so a contributor would be weary to take this on, and reviewing the change would require a lot of debate and rigorous testing.

You did a good job reporting, videos and demos are perfect, only thing missing is what your expected behaviour is. Issues take a long time, many have been open for years, for the reasons described I don’t think you will see a quick turn around on this.

rom1dev · May 12, 2025, 10:42am

Thank you to bring this to my attention !

No I don’t expect the sliding to be canceled.
In the example shown in the issue (where the collision happens on a horizontal edge), I just want the sliding to be slower. If velocity.x = 50, I expect the sliding speed to be 50. I think, it should not depend on velocity.y (as the collision happens on a horizontal edge). That’s why it should not conserve its magnitude in my opinion.

Maybe, I should make a schema to explain things better…

dragonforge-dev · May 12, 2025, 2:31pm

You can add your expected behavior as @gertkeno suggested.

I can think of many. Just like you’re busy with life, they are busy with life. The people working on Godot are doing it for fun and for free. They do not get paid for it. Just like the people on these forums are answering questions to the best of their ability for free.

Shakajolt · May 13, 2025, 3:45am

It looks like the engine is taking the expected velocity of 111 units/frame and then moving it as far as it can, then sliding it. From a physics standpoint, the current results are the ones most people would expect.

You’re constantly moving something at ~111units/frame. The game is taking that motion, moving until it collides with a wall, and then attempting to use up the remainder of that motion in whatever its new direction is. Or to put it another way; you’re not moving 50x and 100y units, you’re moving ~111units at about 296 degrees (or ~64 degrees below the X axis). Once you collide with something along that motion, the engine sees how much you’ve moved, and tries to use the rest of your movement along whatever surface you’ve hit.

I’d recommend playing with code to get the desired results. I haven’t personally dabbled with the physics engine much, but you could see if using move_and_collide followed by custom response.

After writing that and testing, this seems to get close to what you want:

func _process(delta: float) -> void:
	old_x = position.x
	old_y = position.y
	move_and_collide(velocity*delta)
	if (position.x - old_x) < (velocity.x*delta*0.99):
		move_and_collide(Vector2(velocity.x-(position.x - old_x),0)*delta)
	elif (position.y -old_y) < (velocity.y*delta*0.99):
		move_and_collide(Vector2(0,(velocity.y-(position.y-old_y)))*delta)
	print((position.x-old_x)/delta,",",(position.y-old_y)/delta)

Basically just moving and colliding, check for unused motion in the x or y direction, then continue moving in that direction.