Can I have the default PlayerPawn crouch smoothly by adjusting the 'Capsule Half Height' float?

I would like to make the default PlayerPawn crouch smoothly by changing the ‘Capsule Half Height’ float variable in Blueprint.

I tried using a Lerp with a Timeline and even a ‘Finterp To’ in order to smoothly go from standing to crouch (88.0 to 40.0), however no matter what technique I use, the capsule always pops from one value to another, with no smooth transition. Everything else works fine, meshes, cameras, etc., but for some reason the PlayerPawn capsule won’t smoothly interpolate from one value to another over time.

Does anyone know if this is some kind of obscure engine limitation?

Better yet, has anyone been able to create a smooth crouch with the Shooter Game ‘PlayerPawn’?

Appreciate any help! This one has had me hitting my head on the wall for the past week!

Within the lerp, have you set an Alpha?
Also lerp must be called multiple times to do this. ie it goes into a function/event that is called multiple times over time (like Tick).

Look at this thread. The blueprint given in the answer shows Lerp in action. In there it tried to rotate a cube over time.

So I did a test and found something out that I didn’t notice before. I am in fact Lerping the Capsule Half Height correctly, the problem is the following:

For some reason, the value of Capsule Half Height only updates if the player is moving; if the player just stands there, the value won’t Lerp properly. This is very strange, but at least it tells me that the problem might have something to do with the player collision capsule. I will keep searching for some parameter that makes the capsule not stop checking for activity when the player stops.

If someone knows more or has any ideas, please feel free to chime in, this one little problem is becoming a real headache.


I did some digging and found that there is an advanced option that fixes this. In case anyone else needs to find it, in the PlayerPawn BP, go to Components.
CharacterMovement>Character Movement>(advanced settings): check ON the flag for ‘Always Check Floor’. This is off by default. This will force the Lerp to work every tick even when the player is standing still.
Only problem (polish problem), is that when it “checks the floor”, the capsule collider can be a little jittery while interpolating between your float values. This is very visible if the values interpolate slowly, which means you will see jittering if your player takes 10 seconds to crouch, which never happens (at least I’ve never played an FPS game where you crouch that slow). If your crouch takes about a second and a half or something short, it should be fine.

If anyone has come up with other ways to achieve polished crouching, please feel free to share.

Could you elaborate more on option 1?

Are you referring to getting the change in the Lerp value of ‘Capsule Half Height’? What would you move in the negative Z axis? player camera?

I actually have my character’s crouch set up in a similar way. The problem goes like this: Physics only update when the character is moving. The way the default crouch works is by compensating the change in capsule height by moving the mesh down in the Z axis.

What I did was using a custom movement component to override the standard crouch functions in code (so that all blueprint nodes and variables work correctly and not having similar name variables and functions) and use a modified version of the built in crouch (only the detect floor and adjust mesh Z parts) that executes every frame during crouch.

The last post in my forum thread shows another way to do it which is probably more efficient than mine.

I didn’t notice this was in blueprint scripting section. You can still apply the general logic this way:

1)Get the change in the Lerp value and move the same amount in the negative Z axis (remember to set on sweep so the mesh doesn’t get stuck in the ground).

2)Another alternative I used as a quick fix before I implemented my code solution was to spawn an actor at the cameras position and set it to update location based on an interpto on the player’s mesh + camera z offset. Then attach the player’s 1st person camera to the spawned actor. This is just a quick fix and it has many problems such as clipping through walls if not used correctly.

Option 1 is a better option

Did you try conditionally enabling and disabling ‘Always Check Floor’?

ie Enable it when you start crouching and disable it when you are done with crouching. Same goes for the reverse animation. This will save some CPU cycles if possbile.

Converted your comment to an answer

The actual player mesh. The capsule half height has its center at the player’s center. That means if you scale it down, the player mesh will be floating in the air. You can use the console command Showcollision to see the actual collision capsule when this happens.

Basically you have to do this:
1)Lerp capsule half height.
2)Lerp character mesh negative Z half the amount to compensate.

This was the first idea I came up with as well, the problem is that the Shooter Game PlayerPawn doesn’t allow to access the FPS player mesh (Mesh1P) component in Blueprint.
Do you know of a way of accessing it? I was thinking I may have to go into C++, find the code for the Mesh1P component, edit it so it’s exposed to Blueprint, and then I can override it with BP. Do you think that’s the right thinking or am I missing something? Thanks for bouncing ideas around with me, really helps!

You don’t actually need to move Mesh1p. What you have to do is set the whole actor location. The capsule component, is the one which changes dimensions and since it is the root component, you have to move the whole actor. You can easily do that with SetActorLocation.

The capsule is the root component, if you move the whole actor, you are essentially moving the capsule. Having said that, moving the actor/capsule down to simulate crouching is a bad idea because the entire collision capsule moves down through the floor, which causes the player to fall out of world.

This is why I need access to just Mesh1P, so I can move the FPS mesh independently of the capsule, which would allow me to create a proper crouch. At the moment it doesn’t look like you can take control of Mesh1P through BP. If I’m wrong about this, I would like someone to come forward with some info on how to take control of Mesh1P away from the root component/capsule component.

It isn’t a bad idea. That is exactly the way it is done in the default crouch. If you move Mesh1P then nothing happens because the collision capsule is still floating in the air.
You can check Always Check for floor so the collision capsule moves automatically but this can sometimes bring problems.
You have the option to check for sweep in SetActorLocation so it won’t move through collision. Trust me, I have it set up like this and it works perfectly.
You can even do checks for when you are in air or moving so this only happens in this situations.

The way the default code does it is do a check for collision, distance traveled by crouch and then compensating move the whole actor. You can toggle the ShowCollision console command to check how it’s done.

I finally solved this.

It appears to have been a bug with the PlayerPawn. I installed UE4 4.3 and the problem was solved. I did the following to get a good crouch:

Set the capsule height with a Timeline that changes the height value over about a quarter of a second, from default 88 to 44 (figured half the value makes player feel like they’re crouching). The Timeline is set to play (88->44) when Crouch button pressed. When Crouch button hit again, Timeline plays in reverse (44->88) and the player “stands”. It’s a toggle right now, to mimic most first person shooters.

This method works perfectly and is exactly what I wanted from the start. This was one of my first solutions when I set out to program this two weeks ago, but it wouldn’t work. After updating to 4.3 a couple of days ago and seeing all the fixes and changes in the release notes, I decided to clean out my Crouch blueprint and try again using this simple method- to my amazement, it just worked exactly as it was supposed to.

I guess something was fixed in 4.3 that coincidentally solved this bug.