May potentially be caused with other types of move components which are not capsules. I personally think that the issue here is that mover declares to allow users to play with any shape they want, but instead in that utils class the component is casted to capsule and the ptr is not checked afterwards.
Steps to Reproduce
- Setup a project to use with mover
- Create a pawn that has sphere as it’s root component, setup it to work with mover component
- Run and jump around uneven terrain, the crash may happen quite randomly
- Observe crash in FloorQueryUtils.cpp:47, where CapsuleComponent is null
I’m not sure why callstack is not visible here, so I’ll just add it in this message
UFloorQueryUtils::ComputeFloorDist(const FMovingComponentSet &, float, float, float, const UE::Math::TVector<…> &, bool, FFloorCheckResult &) FloorQueryUtils.cpp:46
UFloorQueryUtils::FindFloor(const FMovingComponentSet &, float, float, bool, const UE::Math::TVector<…> &, FFloorCheckResult &) FloorQueryUtils.cpp:31
UAirMovementUtils::IsValidLandingSpot(const FMovingComponentSet &, const UE::Math::TVector<…> &, const FHitResult &, float, float, bool, FFloorCheckResult &) AirMovementUtils.cpp:61
UAirMovementUtils::TryMoveToFallAlongSurface(const FMovingComponentSet &, const UE::Math::TVector<…> &, float, TQuat<…>, const UE::Math::TVector<…> &, FHitResult &, bool, float, float, bool, FFloorCheckResult &, FMovementRecord &) AirMovementUtils.cpp:104
U***FallingMode::SimulationTick_Implementation(const FSimulationTickParams &, FMoverTickEndData &) ***FallingMode.cpp:337 <== our custom class that almost copies UFallingMode
UMovementModeStateMachine::OnSimulationTick(USceneComponent *, UPrimitiveComponent *, UMoverBlackboard *, const FMoverTickStartData &, const FMoverTimeStep &, FMoverTickEndData &) MovementModeStateMachine.cpp:395
UMoverComponent::SimulationTick(const FMoverTimeStep &, const FMoverTickStartData &, FMoverTickEndData &) MoverComponent.cpp:618
UMoverStandaloneLiaisonComponent::TickMovementSimulation(float) MoverStandaloneLiaison.cpp:373
[Inlined] FMoverStandaloneSimulateMovementTickFunction::ExecuteTick::__l2::<lambda_1>::operator()(float) MoverStandaloneLiaison.cpp:467
[Inlined] FActorComponentTickFunction::ExecuteTickHelper(UActorComponent *, bool, float, ELevelTick, const <lambda_1> &) Actor.h:4888
FMoverStandaloneSimulateMovementTickFunction::ExecuteTick(float, ELevelTick, Type, const TRefCountPtr<…> &) MoverStandaloneLiaison.cpp:465
[Inlined] FTickFunctionTask::DoTask(Type, const TRefCountPtr<…> &) TickTaskManager.cpp:334
TGraphTask::ExecuteTask() TaskGraphInterfaces.h:696
UE::Tasks::Private::FTaskBase::TryExecuteTask() TaskPrivate.h:518
[Inlined] FBaseGraphTask::Execute(TArray<…> &, Type, bool) TaskGraphInterfaces.h:495
FNamedTaskThread::ProcessTasksNamedThread(int, bool) TaskGraph.cpp:791
FNamedTaskThread::ProcessTasksUntilIdle(int) TaskGraph.cpp:690
[Inlined] FTaskGraphCompatibilityImplementation::ProcessThreadUntilIdle(Type) TaskGraph.cpp:1431
FTaskGraphCompatibilityImplementation::ProcessUntilTasksComplete(const TArray<…> &, Type, const TFunction<…> &) TaskGraph.cpp:1569
FTickTaskSequencer::ReleaseTickGroup(ETickingGroup, bool, TArray<…> &) TickTaskManager.cpp:1035
FTickTaskManager::RunTickGroup(ETickingGroup, bool) TickTaskManager.cpp:2128
UWorld::RunTickGroup(ETickingGroup, bool) LevelTick.cpp:784
UWorld::Tick(ELevelTick, float) LevelTick.cpp:1721
UEditorEngine::Tick(float, bool) EditorEngine.cpp:2169
UUnrealEdEngine::Tick(float, bool) UnrealEdEngine.cpp:534
U***EditorEngine::Tick(float, bool) ***EditorEngine.cpp:27
FEngineLoop::Tick() LaunchEngineLoop.cpp:5828
[Inlined] EngineTick() Launch.cpp:60
GuardedMain(const wchar_t *) Launch.cpp:192
LaunchWindowsStartup(HINSTANCE__ *, HINSTANCE__ *, char *, int, const wchar_t *) LaunchWindows.cpp:266
WinMain(HINSTANCE__ *, HINSTANCE__ *, char *, int) LaunchWindows.cpp:334
Hi Yehor,
Thank you for reporting this issue. I noticed from your callstack that you seem to be running a modified version of the engine, but I was able to repro the crash in the vanilla UE 5.7 from the launcher as well. For reference, my repro was using the assets from the Mover Examples plugin: I changed the root component of “AnimatedMannyPawn” to a sphere instead of a capsule, and then attempted to PIE on map “L_CharacterMovementBasics”.
Interestingly, the documentation states that the provided Default Character Movement Set (DCMS) does assume a vertical capsule primitive for all actors. Since you mentioned in the callstack that your custom mode almost copies UFallingMode from the DCMS, this probably explains the crash. On the other hand, since UFloorQueryUtils is not part of the DCMS, maybe its functions should not rely on that assumption. I noticed that the cast to UCapsuleComponent was added by CL 37095162 (git commit da32653) from October 2024, so this might be an oversight, or the devs might have shifted focus to the Capsule shape for now.
I am going to try to reach the devs of this system to see if this limitation on UFloorQueryUtils is intentional or not. And in any case, I am going to file an internal bug report for this issue so that they can take a look, and maybe at least handle non-capsule shapes by logging an error instead of crashing. Just remember that this is still an experimental feature, so a lot can still change. For now, I’m afraid you’ll have to stick to Capsule collision shapes if you need to use any of the following (where I saw casts to UCapsuleComponent being used):
- Anything from the DefaultMovementSet folder
- class UPhysicsCharacterMoverComponent
- UFloorQueryUtils::ComputeFloorDist()
- UGroundMovementUtils::TryMoveToStepUp()
- UGroundMovementUtils::TestMoveToStepOver()
I hope this is helpful. Please let me know if there is anything else I can do to assist you. And I’ll get back to you soon with a bug tracking number for the crash and as soon as I hear any word from the devs.
Best regards,
Vitor
Hey Vitor,
Thx for answering. Yeah, we decided to make our own utils class, not a big change. I think it’s more of an “ideology” thing to use capsule only or shape-agnostic approach, so I just wanted to signalize that I thought could’ve been an oversight indeed
Hi Yehor,
Glad you could work around this issue.
Here’s the tracking number for the bug report: UE-356713. The link should become accessible when the devs mark it as public.
All the best,
Vitor