Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New function to replace/fix the stop_on_slope param in move_and_slide(+ _with_snap) #2530

Closed
Clamshell64 opened this issue Mar 30, 2021 · 1 comment

Comments

@Clamshell64
Copy link

Clamshell64 commented Mar 30, 2021

Describe the project you are working on

A 2D platformer with slopes

Describe the problem or limitation you are having in your project

the stop_on_slope parameter in move_and_slide() or move_and_slide_with_snap() does not stop the KinematicBody2D on slopes, and
the workaround here: godotengine/godot#34117 is for 3D, and does not work in 2D. I want my player (and other objects) to stop on slopes!

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Because stop_on_slope doesn't actually stop the KinematicBody2D on slopes, I think a separate built-in method that could be used with move_and_slide() and move_and_slide_with_snap() should be added to Godot to clear up any issues people are having with their KinematicBody2Ds sliding down slopes.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

my proposal will work by adding a separate method to Godot (I will call this method stop_on_slope() here).

  • stop_on_slope() will be called with the move_and_slide() or move_and_slide_with_snap() method to keep the KB2D (KinematicBody2D) from sliding down slopes (when needed)
  • stop_on_slope() will have an optional parameter, max_angle. Not to be confused with the one in move_and_slide(), max_angle will specify how great a slope can be before KB2D starts to slide down instead of stop.

Why am I suggesting a whole new method to replace a parameter?
Because I've looked into some of the issues involving the parameter in question and it seems that having it[slope_stop] not work is actually intended. A separate function would allow slope_stop in move_and_slide to be left alone, while people who want the stop on slope thing to work would simply have to call another method.

to be clear, the most important thing in my proposal is that stop_on_slope() will actually stop the body on a slope.

If this enhancement will not be used often, can it be worked around with a few lines of script?

I think this enhancement will be used whenever someone wants an KB2D to stop on a slope in a 2D game. Although the stopping on slopes issue may be able to be worked around with a few lines of code (I say "may" because I couldn't figure out how to do it myself after a considerable amount of time), I think the enhancement would be used often enough to justify its addition.

Is there a reason why this should be core and not an add-on in the asset library?

This should be in core because the need to stop on slopes in a 2D(sidescroller) game is certainly not an uncommon thing. Using a Rayshape2D makes going up slopes work perfect, but it messes with going down them and makes one-way collision weird.
I don't think anyone should have to use hacky workarounds to get their KB2Ds to stop on slopes
If a new method is not an option, I'd be happy to discuss a different solution to the problem.

Thank you for your time.

@Clamshell64
Copy link
Author

Ah I thought slope_stop was absolutely broken. Turns out, it's not. I found an answer here: godotengine/godot#47042 The whole point of the proposal was to get your KB2Ds to stop on slopes, which I thought was impossible save for elite coders. Therefore, this proposal doesn't really need to be open anymore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants