This looks related to UCharacterMovementComponent::ServerMoveDual_Implementation which calls UCharacterMovementComponent::ServerMove_Implementation twice. ServerMove_Implementation can call MoveAutonmous, which then calls PerformMovement, which can call TickCharacterPose. This call to tick the character pose can queue up animation notifies, which are not immediately dispatched. When the second ServerMove is called, the queue gets emptied, getting rid of the notifies from the previous ServerMove. If, however, the notify gets picked up in the second call to ServerMove, it can stay in the notify queue until the mesh component calls FinalizeAnimationUpdates later, where it is dispatched. So depending on where the notify gets processed, it may or may not be skipped.
At a glance, it looks possible that this may have been an issue in the past. After the call to PerformMovement, there's another place in MoveAutonomous where TickCharacterPose can be called, which has an immediate call after it to dispatch any queued animation events. This also has the comment "Trigger Events right away, as we could be receiving multiple ServerMoves per frame."
As a tentative fix, inside of UCharacterMovementComponent::TickCharacterPose, I've been looking at calling CharacterMesh->ConditionallyDispatchQueuedAnimEvents right after CharacterMesh->TickPose to eliminate this and possibly similar issues from occurring. It's totally possible that there is a better place to put this call, or that there is a reason why, for the previous case, they placed it outside of TickCharacterPose. But, it does seem to solve the issue.
answered
Oct 12 '18 at 04:13 PM
rcarper-defiant
31
●
1
●
3
●
6
Same question.