Slope Support

[bitmammoth]

The character continues movement while no input is given on sloped terrain. A ray cast downward to detect if distance to ground <= floor value + no input {halt movement} , should fix this issue. I have tried this in the script but its a bit buggy. Are there plans to implement sloped terrain support soon? Perhaps, I could make a pull request with the current code I have though this should be a very simple fix at core level.

[NathanLovato]

I guess this should be added to the Move state for now. I'm not sure what makes the character move on slopes without input. If the character is sliding down it's a matter of using move_and_slide_with_snap instead of move_and_slide. Otherwise, that would sound like a bug to me.

Contributions are welcome, sure. See our code style guide: https://www.gdquest.com/docs/guidelines/best-practices/godot-gdscript/#code-writing-style

[bitmammoth]

The code style is compatible :) Some questions I have are regarding the state machine. In the move state there are functions for the controls of the player state, limited to before the child actions are triggered. If I am correct in my understanding it is there which checks for the character controllers current animation ect... exist. For this instance/situation the Air movement is triggered during falls or a difference in is_on_floor() i.e. jumping (in player class "has_contact"). The previous sets a state in form of a boolean of true/false. It seems to need interaction with a raycast in the air state to handle stopping of movement during transition between the child and parent states. I have tried a few different solutions and have some working and some I am unclear if they were from a proper approach. Could you elaborate on this "I guess this should be added to the Move state for now". I think this would be a nice addition.

[NathanLovato]

You can add a snap Vector3 property to the Move state, that you can modify upon entering and leaving the Air state. That should be all that's needed as you can already rely on the KinematicBody for detecting when you touched the floor.

At least, I don't think the Player class or classes outside the state machine need changes for slope support.

Our HFSM works like so:

1. Child states, i.e. Run or Air, access and control their parents.
2. A parent state like Move state defines all the properties and methods that are common to most movement in the game, while child states define specific behaviors.

I'll let you give this a try, tell me if you need a hand.

[nezvers]

I'll test the project with gravity manipulation, but I can explain my experience with slopes in my FPS project.
move_and_slide_with_snap helped with floor detection for jumping but didn't help with slopes.
I apply gravity only when is is_on_floor and snap vector is turned to 0 when not on a floor.
Returning only Y-axis value didn't help and stop_on_slope cut down the slope sliding speed but didn't stop it even the movement vector magnitude is 0.
move_and_slide worked for slopes, but it gave iffy floor detection. So the final idea I haven't put in is to use Raycast down to help to detect the floor.
Not using with_snap also means going onto slope downwards will have floating and interfere with precise jumping.

[NathanLovato]

Unless there's a bug in move_and_slide_with_snap, it should work. Although I know that a backer had a harder time setting it up in 3D on a freeform terrain, due to collision boxes in 3D being a bit harder to handle compared to 2D. But he managed to make it work on a Zelda-like game with mountains.

[maystey]

move_and_slide_with_snap worked for me (at least on a simple slope). Is somebody actively working on the PR for this?

[NathanLovato]

That function should work yes. Nobody's on it right now, PR welcome!

[NathanLovato]

Note we have some commit guidelines and GDScript style guide (based on the official style guide, but extended)

[maystey]

@NathanLovato I've discovered undesired behavior when moving into steep slopes (angle is greater than the floor angle). If in the air the player slides up them and sometimes the player doesn't leave the run state and runs up them. Would you prefer if I try to fix this in another PR, or can I go ahead and see if I can fix it in this one?

Also, I'd like to add a slopey piece of terrain to the main game area (similar to the playground). Do you have any style recommendations for the model, or should I leave this alone? I do have a simple design in mind that features 3 slopes at different inclines (30, 45 and 60 degrees perhaps).

[NathanLovato]

You can go ahead and fix anything related to slope movement as part of this task.

Regarding the slopes, I believe I was using a grid of 1mx1m in Blender when modeling the basic level asset, so we could precisely snap blocks together in Godot. That's all I'd recommend. So instead of having fixed angles, I'd recommend to design meshes that follow a 1mx1m grid (or 0.5mx0.5m for more fine-grained results).