I suggest that but switching back to regular capsule collision after the loop became problematic correct?
Indeed and the sphere (No matter what speed) wouldn’t actually go around the loop either.
did you modify the material friction while doing this? like Ice-like surface
But the good news is there was an official response about gravity tools somewhere here in the forums that they are working on more flexible gravity systems for objects and players, so I’m just gonna work on something else until there’s update on this.
(which makes sense in some degree, since you can change timescale for individual objects, why not gravity as well?)
I decided to give this a shot. What I have is REALLY buggy, but here is a video of my progress:
and HERE is my blueprint if you want to take a look.
Basically what I’m doing is when the level loads I change the pawns gravity scale to 0 and change the movement mode to flying. Then everything else is just tracing down to get the floor normals and rotating the player to match.
Its floaty feeling and there is no actual force keeping the player on the surface other than the fact that its a loop and your always running into an up angle. I’m sure there is a better way to figure out the angle of the player, but basically the rotation of the player depends on the normal of the ground so you can’t turn the player.
One problem I ran into is when the player is upside down the camera doesn’t follow and makes it difficult to control the player so I had to snap the camera rotation to the player as well which means I can’t look around either.
how about spawning a radial force to the trace impact spot? I did some testing and it does affect player, but requires something like 600 000 as value
edit2: whoops, .uasset needs to be manually copied to project, import doesn’t work
Hey ! Look at this, maybe the guy who made this can help you ?
You are a god. I’ll mess around with this and see if I can come up with a solution.
Well… It seems like your script doesn’t like me. Guess it’s back to the drawing board (Again). I am seriously starting to think Matinee will be the way to go…
Why?
Let me show you:
https://youtube.com/watch?v=e83lOEznHk0
I’m going to tinker around a little bit, but I don’t think it’s going to work for me.
That’s about how well it works for me at the moment. I feel like the parts are in the right place but the things that need to be figured out are how to simulate a false gravity to push the player towards the new down, and then how to properly rotate the player so that the normals aren’t controlling the way he faces. I just remembered you can change the sliding feeling with Breaking Deceleration Flying in the character movement.
If you just want the loop like in sonic you can make it so if the trace returns false you can reset the gravity scale to 1 and rotate the player to the standard world rotation, then when it returns true turn the gravity back to 0.
This doesn’t stop the clipping that happens with the camera though. I’ve tried editing your blueprint but I’m not getting anywhere, haha. I tried to re-create your blueprint on another MyChar however Set GravityScale wouldn’t show up. Weeeirrd.
I think you’re hitting an inherent limitation of the character movement code at the moment, which is that the capsule is always vertically aligned and that the “floor”/“base” is always down.
If you want to try to work around it I think you either have to implement a custom mode, use a mode that is not PhysWalking, or change a bit of the current walking code to remove the vertical assumption and change the floor traces to trace relative to the capsule orientation. Other things like IsWalkable() would also have to be changed… it’s not a small task 
Something more scripted (matinee) is possibly the best option for now.
We’ve started an internal discussion about the possibility of relaxing these restrictions, but I can’t promise any sort of ETA or outcome at the moment. This thread has certainly been keeping it on our radar though, so thank you!
Thanks for letting me know Zak. I’ll continue to tinker around, but I’ll but a Matinee solution in place for now and I’ll continue to mess around to see if I can figure out a solution in anyway, or maybe someone on here can do it before me - Who knows 
Maybe we can come up with a solution that wouldn’t need a change of the source code; Who knows
Thanks for keeping us informed though; I’ll let you know if we figure anything out on here!
Like Zak said, capsule and gravity are hardcoded to be always vertical (Z axis); Kitatus, try to keep using McFearson’s blueprint and squash the capsule, so that it almost becomes a sphere (dunno if you can do that with blueprints), and make sure the traces have the correct orientation.
Anyways, what you’re trying to achieve is hard, it took me many months to get a good solution in UT2004, and doing this properly with blueprints seems very very complex. I recommend you switch to Matinee, or wait and hope that better code arrives.
I’m currently converting the character movement code (I have completed PhysFalling with any gravity direction), but it’s taking days of continuous development, Epic’s base class is huge. Maybe we could join efforts somehow? Any map where I could verify that everything works as expected?
Just wanted to chime in that I’ve been following this thread with the hopes of getting some ideas for a non-matinee solution. The project we’re working on involves an NPC spiderbot (think of Rage’s little mech spider buddy) that we’d like to get running up and down walls, ceilings, boxes and other props, so the matinee-based solution wouldn’t really work in our case.
I did figure we’d want to build some sort of secondary collision mesh with little ramps around the base of objects the spider was supposed to climb up in order to get a smooth interpolation up the surface, but all the issues with gravity and sticking to walls/ceilings seems to be one of the biggest issues.
On an entirely separate note, can the AI navmesh system currently allow for navigation up walls and ceilings?
Cheers!
Nick I think switching to either Flying mode or a custom CharacterMovement mode and doing your own traces when you are walking up walls and/or ceilings is a good approach. This is how the SwingNinja sample does it.
I’d guess no; they probably are expecting Navmesh.
That’s not how it works in Sonic though. I believe it was the momentum/speed that kept Sonic on track.
It looks like a spherical collision that affects only the position and not the rotation of the character.
You could also add an invisible collision mesh inside the loop, and just rotate the mesh to the rights rotation position.
Another idea would be to add splines inside the loop, and constrain the character to those splines.
