I am currently attempting to play around with some physics objects and noticed an interesting issue I was hoping people here could help me with.
So I have a child class of ACharacter that has the default character CapsuleComponent as its root. I am running some logic that launches the character forward (I’ve tried using AddImpulse as well as the Character class’ LaunchCharacter). I notice that when the character runs into a wall of physics objects, they don’t move much at all and the character’s movement basically stops at the wall of the physics objects.
What is interesting, is that if I copy my CapsuleComponent root component exactly and I make it slightly larger than the already existing CapsuleComponent, the collisions with the physics objects are as I want.
My ACharacter subclass does utilize the character movement component and I’ve seen code in the base Character class that sets the CapsuleComponent as the movement component’s UpdatedComponent.
This gets me to my question, is there a way I can use the ACharacterCapsuleComponent and get the physics object interactions I was seeing with a separate capsule component? I’d love to avoid a situation where my character would have their base CapsuleComponent and a slightly larger capsule component to emulate that behavior.
I’ve added some videos below of the single capsule and double capsule that would showcase the issues I am seeing.
I am suspecting that there is a specific code in the movement component that zeroes the character velocity when you hit something mid-air. That’s why you can push them with a bit larger collision - it interacts with the boxes before the inner collider registers a blocking hit and zeroes the velocity.
Check what is happening in CharacterMovementComponent.cpp
After taking a look into the UCharacterMovementComponent::PhysFalling function, I noticed that there is a big if clause in there that is triggered if after updating movement we have a blocking hit. This if clause does something similar to what you were saying, where it either uses the target velocity on impact as defined by the CVAR CharacterMovementCVars::UseTargetVelocityOnImpact or if the subTimeTickRemaining > UE_KINDA_SMALL_NUMBER && !bJustTeleported. This typically halts the ongoing velocity quite a bit and seemingly is the cause of the odd physics collision behavior when running into objects during the Falling movement mode.
So far, my solution has been to just comment those lines out to see if they will actually fix the issue I want, and in doing so it seems like it makes the collision better (but not entirely as if I had a separate component that was larger).
I will post updates in this thread as I discover new things. Please let me know if you have any further suggestions or anyone else has ideas on how this might be solved!
I would advice against changing the movement component. You already have several ways to circumvent this which although “hacky” are not as bad as commenting lines in engine provided code:
Use your initial approach with 2 colliders. If the size difference bothers you, make the original collider not interact with the boxes at all or disable it while launching.
Make your own movement component and override the method in question. Quite involved and some methods are not virtual.
Change the movement method - use Set Actor position each tick to avoid going through character movement component at all.