We don’t initialize the ChannelProxy because the runtime evaluation occurs when UMovieSceneEventTriggerSection::ImportEntityImplimports the event data directly into the ECS system from the sequence. Historically, we don’t want to be able to modify this data directly at runtime because of that and because it typically runs other blueprint code in the director.
What are the problems you’ve been seeing? That might help us understand the issue more.
We’re discussing internally that we may still want to add this. The issue with access to event triggers is that folks may want to adjust what they are calling signature-wise, and that is a no-go. But retiming could be alright. You are most likely safe to add that line in your situation. We may or may not take that suggestion though.
Very clear thanks, it must be very specific to our use case then.
We do actually need to detect and adjust all keys timing at runtime, as our sequences involved many characters with user defined voices (so user defined voice line durations). All sequences are volatile and we have an algorithm in place to retime all content - sections, channels, subsequences (and subcontent recursively) - to fit the changed voice line durations.
Due to the fact the proxy were not initialized, event triggers would be the only element not adjusted, which would cause very problematic desyncs at runtime.
Initializing the proxy does allow use to fix event timings just as the sequence is about to start though, so not sure if UMovieSceneEventTriggerSection::ImportEntityImplwould have issues from this?
We don’t see any negative side effects on our end.
Maybe there would be a cleaner way to retime EventTriggers specifically?