Looks good! How did you achieve this?
If you check out the adventure kit thread, the developer goes into a bit of detail. Basically you have to override every function on the character that has a hard-coded up direction (a lot), and generalize it to work with any up direction.
Sadly means that it isn’t possible in just Blueprints by the sound of things. And even though he went into some detail, it’s not enough to just go jumping into the Source, thinking you know what you’re doing… That’s how file corruption happens. Fret not though, thanks for everyone, We’re getting closer and closer!
Thanks for all the support guys 'n gals, we’re getting there 
IMO in Sonic they use a sphere and the character attached to it with a fixed rotation so it won’t rotate with the sphere, therefore you control the sphere. Then only with enough force you can do a full roll or else fall down. Pretty simple.
NOTE: I’m making some progress again finally. I’ve decided to try and tackle this once more; I had a brainwave watching Alex3D’s Ledge Climbing System in which as long as I could move the player to the trace location; I could fake the rest with Animations by casting to the AnimBP and setting a Blendspace of Direction or something along those lines.
I notice that the Advanced car template does this whole round the loop perfectly (Who knows, maybe this thread inspired it 
) but I’m assuming this works from the wheels. I tried taking a look but the code for the loop is nowhere to be seen, so I assume it’s written in the C++ code or something to do with the car movement mode (Which I’m unsure I could port over).
I hope to post an update with a guide for people if I figure it out, I mean the issue has been going on long enough
Honestly the problem isn’t animation.
What I would do is always trace downward from the player capsule a small distance. If the player’s trace touches a surface tagged with “WalkableCurvedSurface”, I would disable gravity and tick a force IN THE ACTOR DOWN DIRECTION, and then just use the trace to rotate the player actor to the surface normal. That would resolve most of the problems; the issue would, IMO, be input handling, since you’d need special functions to handle movement on those type of surfaces.
Thinking of Input Handling, I assume that would be rather simple actually:
InputAction “Left” > Branch (Is On Wall?) - False (Turn left), True (Move Character Left) .etc
I’m getting closer but the culprit’s seems to be the “Add Force” and getting the Rotation correct. Any chance someone can give me a fresh pair of eyes on this and let me know where I’ve gone wrong?
1-
2-
3-
4- (NOTE: Rot from XVector is connected to Impact Normal)
Interesting thing to note: Disabling Gravity doesn’t seem to do anything to a character, it’s when you change Gravity Scale that Gravity stops affecting them - I wonder if this is intentional.
Add Force is pretty weak. An impact normal is a normalized vector, meaning it has a length of one.
My character is about the same size as the stock third-person character, and my dashing movement uses an Add Force of like 800,000.
The stock UE4 gravity force is -980 units per second. Start by multiplying your impact normal (using vector*float) by -980 and go from there
Getting there, but getting some major issues with how it currently works; Even though I’m adding force to the Impact Normal, things aren’t going exactly to plan.
https://youtube.com/watch?v=E7LcxUKNJ50
I’m unsure why this is happening; Can anyone shed some light on this?
I’ve been messing around with the force value, but I can’t seem to get it to the correct value without the events in the above video happening, I’ll continue to tinker and come back with an update as soon as I have one.
I’ve decided to try and go back to basics and figure out how to attach a character to a 90 degree wall so they can walk up it, I believe once I’ve figured that out, I’ll iron out the kinks that I already have.
Currently, I’m tracing forward for a wall and once the player hits it, if they are at a certain speed, they will rotate to stand on the wall; But I have no idea how to keep them on the wall and keep the fact they can run if they wish a possibility.
Two things are happening.
One: you need to NOT apply any rotation to the character capsule unless the trace detects a flagged surface; unless you’re designing a Super Mario Galaxy style thing where moving across non-flat surfaces is something you always do, you want to avoid problems by not performing the wall cling calculation unless the surface calls for it.
Two: You need to make sure that the player is always in the FLYING mode when he should be walking on walls, and then set up his AnimBP accordingly. See, what’s happening is that the player is moving past the “walkable surface” angle and the system tries to make him FALL; he enters the falling state, gravity takes over and starts adding a downward force, etc.
The flying state makes the player check for collisions in all directions and never applies gravity or enters the “fall” state which causes an anim transition. If the player is in the flying state, you can use exclusively the Add Force movement without him launched off the ramp by the attempt to enter a falling state.
Hang on, I’ll try to implement it in my game and see if I can make it work.
I’m interested to see your attempt! Your flying mode idea works for going up the wall but without rotating the player, how would they go around the sphere? (Got a few bugs but I’m working on it!)
Well you would rotate the player, but only IF the downward trace was hitting a tagged actor/object. That way the system only attempts to rotate him to the angle of the surface he’s positioned above IF that surface is one designed for him to go around (eg loops). This will avoid issues with the player erratically rotating near corners or when walking over slightly irregular level geometry.
And as long as you always apply the “downward” force in the direction of CAPSULE down, the actor will always be pushed toward the surface beneath his feet. Since he’s rotating along with that curved surface, he should be constantly rotating slightly to match it as he moves forward, and therefore always pressing against it.
If he falls off the edge, the comparatively short downward trace no longer detects a “loop” surface, and switches back to normal gravity (whereupon you’d probably want to fire a Timeline that lerped his rotation back to normal or something).
But again, that’s specifically for loop running, i.e. a situation where you wouldn’t want the player to be able to jump and land at a sideways orientation. I’ve got wallrunning in my game that works really well without ever even rotating the player capsule, for example; my solution works well but as with the loop solution, is hardly a comprehensive wall-walking subsystem. I think you have to approach the problem by specific needs; wall-walking is only really necessary in games where the player can stand around on a wall, sideways, and should mostly be able to do all of his normal actions. If all you want is for the player to be able to run sideways across walls, or run around loops, or something, there are much simpler approaches.
I assume with your walking along wall approach you use a trace for the wall and then switch the mode to flying and add a force into the wall? Or am I thinking too “Literal” here? I believe once I get walking up / down a wall nailed then this loop problem will be a walk in the park.
I understand what you mean by always pulling to the down of the capsule, but surely that will drain the momentum of the characters speed unless you did it ever so gradual? Surely this would create a problem when the player is running forward and reaches the peak of the loop where when they are pushing forward (The down of the capsule) then they’ll just drop as they’re putting pressure to go the opposite way and thus losing all momentum?
No, actually I use an overlap check on a small outer capsule (it’s shorter and wider than the collision capsule, so it can only detect overlaps around the waist circumference) to determine if the player’s “side” is touching a wall which he can run on, and if he is, I take the Hit from the collision capsule hitting the static geometry and use that to adjust his movement to angles perpendicular to the normal of that impact. I disable all non-wallrun input and use special input commands for moving him forward and up/down, and make some changes to his character movement (I slow gravity down so instead of “falling” at his normal fall speed, it feels like he’s sliding down with friction, but he’s still in his normal falling state).
His capsule is rotated to face his movement direction as the game normally would do, but he’s never actually rolled or pitched (the top of his capsule still always points straight up); all of the rotation of his body is just handled by animation. It actually works really well; looks like this:
Now, I don’t do the running UP the walls, since I’m using a more Megaman-X-styled wall kicking set of mechanics, but I know that, for instance, GunZ 2 uses the same approach as I described, and vertical wallrunning is just handled by animating the player into a rotated state rather than actually transforming their collision capsule.
Yeah, I implemented something extremely similar last night; I guess I could compare the player’s speed to a fake gravity that has a similar value to the default world gravity and add a force to pull them down the longer they’ve been on the wall and the speed their going at.
Thanks for taking your time to describe what you did though; Even though I had implemented something similar last night, it’s great to see that I what I did would be considered correct by others!
Once I get running up the wall perfected, I’ll then do along the wall, similar to the way you describe and then I should be able to tackle a loop with the “Flying” movement mode.
**Even though it’s slightly off-topic: **Your game looks great! I’ve seen it a few times now around the forums and I have to say I’m already super-stoked to see the finished project! Anywhere I can keep up with development? I’d be more then happy to spread the word with my following to check out your stuff too as a thanks for helping me in this situation, which might not do much but I do have a few dedicated fans who’d love to check out your stuff!
**Returning to the Topic: **Once I’ve got this whole wall situation fixed up, I will create a template project for people to use and will do a little write-up on the methods behind it (Crediting everyone whose tried to help of course) and will release it in this thread.
Thinking about the loop, I’m going to try setting the character to “Flying” if he hits the tag “Loop” and is above a certain speed and with taking advice, I WON’T rotate the capsule but in fact the mesh inside (Which should be possible somehow) to the normal impact location, as they will be at a speed to get over the loop all the way, I will disable input at the top of the loop (So they can’t stop acceleration at the top and fall by accident and will slightly launch them just after the top of the loop to push them round the rest of the way).
When adding some blocking volumes (I need to figure out how to do this dynamically), I think I’ll be able to get a system that works quite well.
If anybody has any suggestions for any of the questions, feel free to answer them while I try to figure this out as well. I’m grateful for all the help given and I’m pretty sure that we’re almost there!
Back to tinkering with the system!
- R
Any chance you’re going to spill the beans on how you got over the loop? I assume it’s via a SphereComponent? :>