This is useful in gameplay especially for debugging per frame evaluations
#rb matt.hoffman
#preflight 6136ea65d9c85a00010008e1
#ROBOMERGE-AUTHOR: max.chen
#ROBOMERGE-SOURCE: CL 17448303 via CL 17902803 via CL 18360631 via CL 18360781
#ROBOMERGE-BOT: STARSHIP (Release-Engine-Staging -> Release-Engine-Test) (v895-18170469)
[CL 18360848 by max chen in ue5-release-engine-test branch]
This represents UE4/Main @17774255, Release-5.0 @17791557 and Dev-PerfTest @17789485
[CL 17794212 by aurel cordonnier in ue5-release-engine-test branch]
By "client-only" sequences here we refer to sequences whose actor has no network authority (client side in a networked game), but doesn't need replicated playback, so it can do whatever it wants.
#jira UE-126176
#rb max.chen
#ROBOMERGE-AUTHOR: ludovic.chabant
#ROBOMERGE-SOURCE: CL 17553223 via CL 17554030 via CL 17554115
#ROBOMERGE-BOT: STARSHIP (Release-Engine-Staging -> Release-Engine-Test) (v870-17433530)
#ROBOMERGE[STARSHIP]: UE5-Main
[CL 17554143 by ludovic chabant 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]
- Added a LogMovieSceneECS and moved entity system logs to it - this helps distinguish between ECS notifications vs frame/timing information
- Added client name to Evaluating sequence log
- Remove outdaded "Clock Tick" words from TimeController log
LogMovieScene: VeryVerbose: Evaluating sequence SimpleSequence at frame 133, subframe 0.999992 (30.000000 fps).
LogMovieScene: VeryVerbose: Evaluating sequence SimpleSequence (client 0) at frame 109, subframe 0.999993 (30.000000 fps).
LogMovieScene: VeryVerbose: Evaluating sequence SimpleSequence (client 1) at frame 106, subframe 0.999994 (30.000000 fps).
#rb ludovic.chabant, matt.hoffman
#preflight 611d9e933a81b0000143aacd
#ROBOMERGE-SOURCE: CL 17226594 via CL 17226661
#ROBOMERGE-BOT: STARSHIP (Main -> Release-Engine-Test) (v855-17104924)
[CL 17226667 by max chen in ue5-release-engine-test branch]
Additionally, this fixes some issues with how PlayTo handles the last frame. Previously it would issue a 'Jump' command which skips calling events on the frame being jumped to. But the Jump state also skips sweeping over time ranges. This means that event keys on the last frame of a section (or more depending on framerate) could get skipped, ie:
Playhead is at frame 43. Event key on 44. PlayTo(45). If the delta time was large enough to go from 43 => 45.5 the system would historically issue a Jump command to jump to 45, skipping the event key on 44. It now issues a Play command to cover the gap (which will evaluate the event keys).
The reason a different params struct was added to PlayTo (instead of extending the existing one) is that inclusive/exclusive doesn't make sense for Jump/Seek (which are directionless), and is a params struct so that if future parameters are needed it is easier to add one without breaking blueprints.
#jira UE-119063
#rb Max.Chen
#preflight 610ac2ea5738260001b08767
#ROBOMERGE-SOURCE: CL 17055917 in //UE5/Main/...
#ROBOMERGE-BOT: STARSHIP (Main -> Release-Engine-Test) (v850-17047176)
[CL 17055937 by matt hoffman in ue5-release-engine-test branch]
- This change introduces two separate types for dealing with binding IDs in different spaces explicitly: FFixedObjectBindingID and FRelativeObjectBindingID. The latter is portable if the sequence it was created within is nested inside another foreign hierarchy.
- FMovieSceneObjectBindingID remains, and is able to represent both of the new types, but should only be used for serialization to ensure compatability and consistency with editor tools that operate in different spaces.
- Any manual ResolveLocalToRoot or GetSequenceID processing has now been replaced with the new ResolveBoundObjects API, which provides a less error-prone way of resolving bindings that live in different sequences
#jira UE-74450
#rb Max.Chen, Ludovic.Chabant
[CL 14915667 by Andrew Rodham in ue5-main branch]
