It’s this bit here, in the bottom right:
Note that Turn Left / Turn Right are, apparently, swapped around. My bad 
. That needs fixing.
Also note this was never set up with ramps in mind so the actual ramp movement method would be awkward and would need to be revised or even entirely replaced with AI NavMesh movement.
Many ways to pull it off:
- a pro-active way would be to set up some traces. Same function, swap the
Line Tracefor aCapsule Trace→Hitswill produce aNormal- a direction the hit surface is facing:
Dot Product said Normal with VectorUp to get a value range of -1 <> 1 indicating how steep the ramp is. Work that pitch in during the movement update to a smooth transition:
More would needed here as the next thing you’d want is a ramp that goes down.
- a reactive way - sample the surface we’re traversing on, something the movement component already does:
This is just pseudoscript, ofc. Not sure if helpful at all.
The thing is that when you get round to it in a somewhat serious manner, one would have a feature guideline, a design doc detailing how things are supposed to work. There was none and things escalated so it needs refactoring now.
You could probably get away with it all in the current system, it’s a matter of getting more data from the world via tracing.