This represents UE4/Main @18073326, Release-5.0 @18081140 and Dev-PerfTest @18045971
[CL 18081471 by aurel cordonnier in ue5-release-engine-test branch]
The first problem was with client sequences that are re-synced to the server time.
If a re-sync sends the client sequence a few frames back, it will re-evaluate these frames as it plays over them a second time. If this happens around an event, this event will fire again. So we set a timestamp to where we were at before the re-sync, which tells the event system to ignore any events before that timestamp.
The second problem was with client sequences who are *late* compared to the server.
When the server sends a Stop RPC message, if the sequence is a bit behind it would only advance to the stop time if the difference was above a threshold. But we could miss firing an event that's on the very last bit of the last frame. So now we advance to the stop time exactly.
The third problem was with client sequences who are *ahead* of the server.
When the client sequence would reach the end of playback, it would stop and reset time to the beginning all on it own. But the server would still be running the last couple frames, so it would send some network message telling the client sequence to do that. The client sequence would go back into play mode, and play all the way from the start to one of these last frames. This means it would re-evaluate the entire sequence again, including re-triggering all the events! So now, non-authoritative sequences don't stop-and-reset-time when they reach the end of playback. Instead, they stay on the last frame and wait for the server to send them the explicit "end of playback" message.
#jira UE-118153
#jira UE-118375
#rb max.chen
#ROBOMERGE-SOURCE: CL 17354009 in //UE5/Main/...
#ROBOMERGE-BOT: STARSHIP (Main -> Release-Engine-Test) (v865-17346139)
[CL 17354028 by ludovic chabant in ue5-release-engine-test branch]
