I am making a game where you play as a dragon and I want the dragon to be able to grab onto or crawl along and around cliffs and boulders.
In more detail, when you touch a cliff or cave roof or some such object I want it to latch on and them be able to crawl around until you take off again.
Any ideas how I would do this?
here is a video of the dragon game, this video is a bit old now, the flying is much better now and the landscape is more interesting but this gives you an idea:
Nice, dragon 
Have you figured this out? I need not only self climbing but also the AI to climb vertical navMeshes.
Would be nice having similar to UCX_ altrenative to model static meshes for navMeshes and with given angle let the AI climb instead of walk.
I have came up with a half solution since I posted this, here is a video of it
The system I’ve came up with works quite well up to 90 degrees but any steeper and the character flips upside-down, so I basically make the character fall and play a particle effect when it gets steep enough to mess up…
What I do is when you collide with something with a climbable physics material turn off gravity, put the character into flying movement mode and apply a constant force in the direction of the cliff normal, this means the character can now move around on the surface of the object, I then do a line trace from the character in the direction of the stored cliff normal and use that to update the gravity direction, rotation etc. Using that trace if the cliff is to far away then you are obviously not climbing it therefor you turn gravity back on, put movement mode back to falling and stop applying the force in the direction of the cliff.
The next thing was how to get the character to rotate to the cliff angle AND rotate to player input… I knew what I wanted was to get the z axes to be the cliff normal and everything else to work around that, after a wile I found the node I was looking for, “Project Vector on to Plane” This allowed me to make a movement direction vector based on which way you were moving and the camera was facing which was forced onto the plane of the cliff. Is that perfect or what? Well actually its not… If the normal is steeper than 90 degrees, eg upside down then the character flips so its as close as it can be to the right way up which means it ends up going along the rock with its head… So I’ve told you what I know, do you have any ideas how I might stop the flipping?
Thank you for explaining your very interesting solution. In my case I need the AI to recognize the vertical ladders and use them whenever receiving SimpleMoveToLocation from any random position to another:
Navigation mesh does not get generated for them even when the collision mesh is 89° and navigation links to not make jumping out of the box.
To stop the flipping maybe apply a force vector in direction from center of mass of dragon to center of mass of the cliff?
Interesting, so is there not a setting on the navigation mesh which controls whats the steepest slopes can be? because if you set that to its highest (probably 89 degrees) and rotated the ladders to just below that angle (lets say 88 degrees) then I would think it would be fine, (although beer in mind the NPCs themselves would probably need to have their max slope angle or whatever its called set to as high as it goes too so they can get up, that should be in the movement component I expect.
If that doesn’t work what about. doing a check, if their target is un reachable, is it higher or lower than them, if higher go to the bottom of the up ladder (this would have to be set using a variable I expect, maybe by checking through all the objects of class base of ladder and seeing which is the nearest one which is reachable. Once it reaches the ladder base blueprint it could then go into climbing mode which would simply interpolate its position from the base of the ladder to the top, once at the top the character could do the same check to see if it needs to continue up or down or is on the right level. inevitably this would cause a whole load of flaws, like NPCs going up and down the same ladder if the height of their target was in between the two, and that sort of thing but on the whole I think that would do the job.
By the way I am an artist rather than a programmer so I don’t have a clue about the right way to do this stuff, I just do anything I can think of that seems to work!
Woops I set this as an answer, I guess it is an answer, I’m just exploring ideas more than anything though.
I am more a programmer and a lazy one: spoiled by navMesh how works fine for the most of the cases and not for what you suggest in the beginning - it did not work with 89° for both.
I am afraid have to make it the hard way with possibilities of many errors.
All could be avoided if a feature (think existed in the past) to add custom geometry to be used for navigation, because the one I made for collision with 89° works fine.
I think using the cliff normal works ok with the force, the issue is more of a visual one. Its the rotation method which is causing the problem, (see the blueprint above) below is a crude sketch showing what the problem seems to be.
Maybe use Make Quad: Vector components are dragon position - following camera, angle from from vector between dragon and center of the rock?
Note: This only works by not using the controller rotation but using the actors rotation… the controller expects the character to always be standing up, and since they had to chose an axis to limit because of gimbal lock, if you rotate more than the -90/90 degrees, they flip the roll axis, which completely changes the rotation values, and causes the visible flip. I don’t quite understand why this was done, since the engine uses quaternions internally which work around this issue…
To answer the flipping issue. If you are using a character blueprint type, you need to turn off “use controller yaw, roll, pitch” then your character won’t flip out when you rotate him past 90 degrees on the pitch axis.
If you need to use controller input (instead of handling input in the character itself) then what you do is turn off “use controller xyz” then after you’ve rotated past 90°, you need to rotate the controller 180° on the roll axis seperately to compensate for the flip, THEN you turn it back on. This way you won’t visually see the internal flip of the roll axis UE4 does to work around Euler angles and gimbal lock. This should also correctly orient your left/right input again.
