The data is not deserialized yet in PostInitProperties so this would have never done anything previously.
#rb Ludovic.Chabant, Max.Chen
[CL 30953320 by andrew rodham in ue5-main branch]
The APIs to get sequences in the sequence hierarchy only work for sub-sequences, not root sequences. Root sequences need to be checked separately...
#rb Max.Chen
[CL 30894074 by ludovic chabant in ue5-main branch]
* Adding some first pass UI for editing the Universal Object Locators that are used to bind objects to tracks in Sequencer. This is currently in the form of:
* An 'Add Empty Binding' item in the + Actor to Sequencer menu
* A 'Binding Properties' sub-menu in the object binding track properties that allows you to modify the array of UOL's that bind objects to the track. This allows you to specifically select certain UOL types and then fill in the data that makes up that UOL. This is necessary for example for the FortAIPlayerPawn binding we plan on adding for UEFN.
* Major refactor of MovieScene binding code to more seamlessly allow for the use of the Locator resolution, especially in the case of supporting locators that spawn actors, either in the case of editor preview actors or future runtime 'spawnables'. This was necessary to consolidate the cases where locator resolve params were being created to as few places as possible for simplicity.
* Add the concept of 'default' editor and runtime flags to locators to make it easier for Sequencer to know how to interact with bindings of different types. These flags are then stored with the binding in Sequencer and editable by users as necessary. Sequencer treats 'load'/'unload' in this case similar to 'spawn'/'despawn' and generally speaking resolving a locator with editor flags of 'load' will expect the locator to spawn an actor for preview, while resolving a locator with runtime flags of 'load' will expect the locator to create a 'spawnable' character.
* To manage lifetime of these preview/spawnable characters, created an interface for a 'LocatorSpawnedCache' which the locators interact with when creating or destroying an actor. This allows the resolver of locators to differentiate between cases where they expect multiple resolves of the same locator to create duplicate actors vs. resolve to the same actor and track the lifetimes of these spawned actors.
* Sequencer implements the above cache within its own object cache in evaluation state.
* Expand the role of the previously created Binding Lifetime track to trigger loading/unloading via locators in the cache. The Binding Lifetime track will now automatically be added to a binding if its locator type contains 'Load' as a default editor or runtime flag.
* Some other editor updates to support the above.
Future issues to be resolved:
* We want to more easily expose the editing of binding properties when necessary rather than having it buried in a sub-menu. Ideas for this include some kind of UI on the track itself, for example a combo box with binding types on it, as well as potentially the properties menu appearing on hovering over the possessable icon on the object binding track. We also want to expose properties based on selection, for example object binding properties, track properties, and section properties, in another external window.
* We want to eventually replace the 'Actor to Sequencer' and 'Assign Actor' menu with this once the UX is better.
The above was all tested with a Fortnite NPC Locator type which will be added in a separate changelist.
[REVIEW] [at]ue-sequencer
#jira UE-199299
[CL 30596833 by david bromberg in ue5-main branch]
The fix here is to just call InitializePlayer() which is already doing the necessary checks. This fixes an issue where if the player has been torn down (ie. EndPlay has been called on the Level Sequence Actor), the player will be reinitialized when it is reconstructed.
#rb Andrew.Rodham
[CL 30540244 by max chen in ue5-main branch]
Upgrade the overrides and callsites in all of Epic's code.
Every class that can be subclassed by licensees that has its override change needs to keep the old version of the function as deprecated. Otherwise subclasses that call Super::GetAssetRegistryTags will have a compile error instead of a deprecation warning.
Several classes had their own extension method for GetAssetRegistryTags being passed on to user data classes. Updated all of those to take FAssetRegistryTagsContext just like GetAssetRegistryTags does.
#rnx
#rb Francis.Hurteau
[CL 30224166 by matt peters in ue5-main branch]
Level Sequences now use UOLs for their bindings.
Level Sequence player context is now an ALevelSequenceActor if possible.
All bindings (including the extreme-legacy lazy object ptr bindings) are now upgraded to use the UOL binding mechanism.
Introduced a new concept for reasoning about object hierarchies in Sequencer: object schemas. Schemas allow customization of how Sequencer handles finding 'parent' and 'child' objects, which allows us to genericize lots of the hard-coded Actor-Component logic. This is just a first pass - there are still many places that directly deal with AActor and UActorComponent, which will be gradually migrated with upcoming work.
#jira UE-199305
#rb david.bromberg, ludovic.chabant
[CL 29932924 by andrew rodham in ue5-main branch]
This is the third step in the overall refactor to remove the dependency of Sequencer evaluation code on IMovieScenePlayer. It puts most of the spawnables/possessables logic into playback capabilities, so that systems concerned with them can find them there instead of depending on the player interface. In order to do this, many APIs previously taking a player pointer now take a shared playback state reference, which is where they find the playback capabilities.
To keep the changelist to a manageable size, we don't deprecate the previous APIs right away except where we don't have much choice, such as the virtual methods of the spawn register. Everywhere else, passing a player is still a valid call.
Some other APIs have also changed, because the shared playback state structure often gives all the information someone may ever need, and this renders many parameters obsolete. This is for instance the case with sequence updaters.
One aspect of this change that needs to be carefully handled is the initialization and re-initialization of a sequence hierarchy prior to playback. Now that evaluation code relies on playback capabilities, these capabilities need to be added to the sequence hierarchy's shared playback state in a timely manner, and they need to react to changes in the hierarchy. The following changes have therefore been made:
- Playback capabilities can implement callbacks for initialization and for when a new sub-sequence instance is added.
- Sequence instances have a new Initialize method that needs to be called shortly after creation. This is especially needed for root instances, as it gives time for the caller to setup their playback capabilities before finishing the initialization.
Another aspect of this change is that it unearthed a problem with the capability storage, where we could stomp memory and crash while relocating capabilities to make room for a new one. This happened if we did not reallocate a new buffer (i.e. relocating in place). Moving headers could stomp the space of the first couple capabilities before we had a chance to move them. The code now moves things from back to front, first the capabilities, and second the headers.
Finally, this change adds the ability to overwrite a capability with a new value. This is needed for the way the level sequence player initializes itself (see the comment in the code).
The following things have been made into playback capabilities, or have had a new capability interface created around them:
- FMovieSceneEvaluationState, for access into object caches.
- IMovieScenePlaybackClient, for dynamic binding overrides.
- The player index, for retrieving the player interface, if any (mostly for legacy evaluators).
- Notification callbacks for when object bindings change.
- Static binding overrides.
- Storage and management of sequence director blueprints.
Since the player interface is now an optional playback capability, some progress has been made to gracefully handle the case of no such player existing.
#jira UE-199669
#jira UE-199668
#rb Andrew.Rodham
[CL 29895537 by ludovic chabant in ue5-main branch]
The Binding Lifetime track is an optional track that can be added to any object binding. It allows the user to set time range(s) for when the object in question will be bound by Sequencer. Outside of those ranges, the object will be released, and any tracks underneath it will restore state/keep state as set.
Currently this track works for both spawnables and possessables. This track is a precursor to other binding types coming to Sequencer, and in the future this track will allow the user to trigger events as part of the binding activation/deactivation so that changes like AI control for example can be set when binding/unbinding NPC characters or player characters.
As part of this change, it was necessary to clean up some of the sequencer UI color settings on labels, as well as a few changes to the layer bar UI to facilitate a hatch overlay for the sections of the binding tracks that are in a deactivated area.
[REVIEW] [at]ue-sequencer
#jira UE-200088, UE-199857, UE-199299
#rb ludovic.chabant
[CL 29636485 by david bromberg in ue5-main branch]
[FYI] Mike.Zyracki
Original CL Desc
-----------------------------------------------------------------
Sequencer: Linked Anim Instances. Delete links if we can't resolve(by loading) the object referenced.
#jira UE-198720
#rb max.chen
[CL 29212798 by bob tellez in ue5-main branch]
This fixes the UI not updating when calling AddSpawnableFromClass from an Editor Utility Widget
#jira UE-197601
#rb ludovic.chabant
#rnx
[CL 28651047 by max chen in ue5-main branch]
This can happen if a level sequence is re-initialized with a sequence that it was already set to.
#rb max.chen
[CL 28141287 by ludovic chabant in ue5-main branch]
This change tries to address various problems with the camera cut evaluation logic:
- Use the pre-animated state API to properly handle restoring things, instead of doing it partially "by hand". This removes the need for a few hacks like the carry-over of previous view-targets from one sequence to the next.
- Move the code from FSequencer and ULevelSequencePlayer into the track instance (and some related helper classes). Not only does this remove a bit of code duplication, this also lets us take a first step towards removing the dependency of evaluation code on the player API.
#rb max.chen
#jira UE-194692
[CL 28093600 by ludovic chabant in ue5-main branch]
