Queued AnimNotifies skipped on Server
I am running an anim montage on server called by the client however at times the anim notifies on the server version of the character is skipped entirely! The anim notifies are custom made in C++
One workaround for this is to make the MontageTick Type as "Branching point" , however this is undesired.
An apparent pattern seems to be that anim notifies fail when the character is off screen (in other words not being actively rendered), So I changed the MeshComponentUpdateFlag of the character mesh to AlwaysTickPoseAndRefreshBones ,but that didn't change anything.
asked Mar 19 '18 at 11:18 PM in C++ Programming
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
Follow this question
Once you sign in you will be able to subscribe for any updates here