Why is a Falling character's speed capped at 4000 units per second?

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?

3258-screen+shot+2014-04-04+at+5.56.09+pm.png

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:

3259-screen+shot+2014-04-04+at+6.08.38+pm.png

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.

Hoping this isn’t true. Try reviewing this page. I’m hoping it will reveal the answer.

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.

Hi SF,

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.

Thanks!

The limitation is inside UcharacterMovementComponent::PhysFalling

Velocity = Velocity.ClampMaxSize(GetPhysicsVolume()->TerminalVelocity);

Perfect! I appreciate this immensely. I haven’t built from source yet but this is worth learning the process for.

I feel dumb for missing that line, I even searched for “4000” and somehow didn’t reach that.

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.

Thank you Ori Cohen, SF,

Here is the fix. Note: This is within the Level Blueprint.

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.

Perfect! I didn’t think of reaching the default physics volume by iterating over all of them. Thank you so much!

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.

I’ve tried a few things with no luck. What exactly are you trying to achieve?

That’s the second time I’ve come back to a question and it didn’t remember the answer was accepted. Sorry my connection must have been flaky.

attach the volume to the player. problem solved. =3