A pawn with a CharacterMovement controller seems to be unable to exceed 4000 (+/- imprecision) total velocity when in the Falling movement state. It’s so hard capped that if you move sideways, it will actually make you fall more slowly just to maintain the same velocity magnitude. Why is this?
I’m making a very momentum-dependent game (think Quake 3 rocket jumping stunt maps) that needs to exceed this speed by quite a bit. The strange thing is that other movement modes don’t have this limitation. Here’s the character running very fast on a surface:
Yet even at this speed as soon as I leave the surface my character is using as a base, the velocity will snap to 4000. Even launch forces can’t circumvent this limit.
Is there a good reason for this? Drag/walk speed/gravity/all other velocity-affecting settings seem to have no effect. Am I stuck hacking around this by changing the world scale? Having to dig into source to fix this would drastically increase the scope of this project and I’d really prefer to avoid it.
Update: Changing the world scale had no noticeable effect.
Update 2: I can’t even find where or why this is happening in the source code. Using alternative movement modes isn’t really viable since the CharacterMovement class makes a lot of assumptions about Falling actually being for falling et cetera. Re-implementing CharacterMovement in Blueprint would be an entire project unto itself.
Update 3: Nothing that I have tried has worked. Forcing the character into Flying mode with added gravity every time they leave the ground causes a host of other bugs and requires a tonne of special cases. This has absolutely blocked my project. Please help!!
There may be some form of Terminal Velocity mechanic inherent in the gravity mechanic that is not applicable when merely running along the ground.
If you didn’t create the gravity mechanic yourself(you are using some template resources from Epic), you may want to dig into it’s blueprint and see how it is handling it.
The CharacterMovement component is native so it has no blueprint. Even implementing my own gravity wouldn’t circumvent the velocity limit since that would still just involve launching the pawn.
I’ve tried a few things but it looks as if the CharacterMovement has a limitation within it. You can do one of two things I see. Either edit the source directly removing the falling limitations. Or, creating a new Character Blueprint specifically to bypass this limitation. Its possible, you would just have to create the components that make the character class by hand. This does not occur in the Pawn class itself.
It does. So far I found a work around but it isn’t something I find effective. It has something to do with the “Movement Mode”, when in “Falling” it limits it to 4000 velocity. Swimming, Running, Flying etc can move freely.
Update:
I’m lead to believe it has to do with “UCharacterMovementComponent::CalcVelocity”. Trying to find out why it applies breaking.
I have reviewed the source and I couldn’t find this speed limitation anywhere in the CharacterMovement class. There are velocity limiters, but they’re the same ones applied to Flying etc. which are accessible just as easily through the blueprints. There’s no mention of limited Falling that I could see.
If someone could comment who knows for sure what’s causing this/how to work around it I’d really appreciate it. Re-implementing all of the CharacterMovement functionality because of one unexplained quirk seems insane.
The problem you’re running into is because we have a default physics volume with terminal velocity of 4000.
I’m not an expert on this system so I need to double check something before giving you a proper fix, but in the mean time if you have access to code you can change this in the constructor of APhysicsVolume:
Engine\Source\Runtime\Engine\Private\PhysicsVolume.cpp line 13
TerminalVelocity = 4000.f; (change it to something higher)
This is not a permanent solution but I wanted to give you an answer so that you can at least keep going.
I’ll keep you posted on the proper solution once I find out more.
Ah okay, I was looking at that. I did point out that this only applied to Falling but not the other states. Which is could be a sloppy workaround if you did not want to get into the source.
SF, an easier way to do this is to add a physics volume. You can find this under All Classes. Simply drag it into the viewport and scale it so that it covers your entire map. With the Physics Volume selected look at the details panel under Character Movement where you can change the Terminal Velocity to whatever you want.
We’ll be exposing this as a world setting soon so that you can just change the properties of the default volume.
Thank you! Unfortunately that solution isn’t suitable to my particular project, as it’s a procedurally generated pseudo-infinite world where the player might eventually leave the volume even if it was very large. That’s great to hear it will be exposed as a world setting soon!
Thank you Ori Cohen, I would of never looked at this if not your discovery of the PhysicsVolume.
It was my pleasure to finally crack this SF. I actually needed something like this from my game.
I know Epic keeps telling us we can do everything in BP, but it still amazes me how much control you can really have if you find the right variables and operations.
Is there a variation of this method that would work for setting all friction values to 0.0? I assume it would involve looping over things with materials.