x

Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

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?

alt text

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:

alt text

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!!

Product Version: Not Selected
Tags:
more ▼

asked Apr 05 '14 at 01:24 AM in Blueprint Scripting

avatar image

SF
298 26 32 39

avatar image 7thGate Apr 22 '14 at 03:03 AM

I hit this too. I was building a sample game with very high jumping/fast running, and I started noticing that the jump height was being dramatically reduced if I was moving very quickly when I jumped. Also, if I started moving laterally at the apex with a high value for AirControl, continuing to move would prevent most of gravity from applying, allowing me to hover and very slowly drift downwards.

At first I thought it was clamping the velocity after applying the input and gravity together, which would have had this effect, but the gravity calculation very explicitly clamps the 2D components of the vector and handles the Z axis separately. The terminal velocity clamp, however, uses all three components of the velocity vector, which distorts the Z component significantly if you are already at terminal velocity with just your X and Y velocity components. It seems kind of strange that this would work this way since the rest of the calculations treat the Z axis separately.

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

3 answers: sort voted first

Thank you Ori Cohen, SF,

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

alt text

more ▼

answered Apr 11 '14 at 04:46 AM

avatar image

PeterLNewton
1.8k 69 28 100

avatar image SF Apr 11 '14 at 05:12 PM

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

avatar image PeterLNewton Apr 11 '14 at 05:38 PM

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.

avatar image Heisenburger Apr 17 '14 at 06:34 PM

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.

avatar image PeterLNewton Apr 18 '14 at 01:50 AM

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

avatar image ra_ar Apr 20 '14 at 11:07 PM

Thank you for this great solution, just one real quick question... I can't seem to find the "Cast To PhysicsVolume" node from list included with the level. Does anyone know where that comes from? I tried just creating a new project with the include starter content option, and did not see it there either.

edit: the only cast to node I can select is Cast To PlayerController

avatar image PeterLNewton Apr 20 '14 at 11:35 PM

Hey ra_ar,

You must pick from Array Element from the ForEachLoop node and you'll see "Cast to PhysicsVolume".

avatar image ra_ar Apr 21 '14 at 01:14 AM

SilentX, that worked, thank you very much.

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

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!

more ▼

answered Apr 09 '14 at 09:57 PM

avatar image

[Epic]Ori Cohen STAFF
1.3k 24 10 57

avatar image SF Apr 10 '14 at 03:40 AM

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.

avatar image [Epic]Ori Cohen STAFF Apr 11 '14 at 03:07 PM

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.

avatar image SF Apr 11 '14 at 05:15 PM

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!

avatar image Cynicat Apr 18 '14 at 05:11 AM

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

avatar image SF Apr 18 '14 at 05:58 AM

Is it possible to attach brushes to moving actors?

avatar image SF Apr 18 '14 at 04:49 AM

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.

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

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.

more ▼

answered Apr 05 '14 at 03:41 AM

avatar image

Zeustiak
1.7k 123 65 108

avatar image SF Apr 05 '14 at 05:05 AM

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.

avatar image PeterLNewton Apr 05 '14 at 11:17 PM

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.

avatar image SF Apr 06 '14 at 01:43 AM

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.

avatar image PeterLNewton Apr 06 '14 at 02:28 AM

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.

avatar image [Epic]Ori Cohen STAFF Apr 09 '14 at 10:01 PM

The limitation is inside UcharacterMovementComponent::PhysFalling

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

avatar image PeterLNewton Apr 10 '14 at 10:36 AM

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.

avatar image PeterLNewton Apr 06 '14 at 01:20 AM

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

https://docs.unrealengine.com/latest/INT/API/Runtime/Engine/GameFramework/UCharacterMovementComponent/index.html

(comments are locked)
10|2000 characters needed characters left
Viewable by all users
Your answer
toggle preview:

Up to 5 attachments (including images) can be used with a maximum of 5.2 MB each and 5.2 MB total.

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question