> But I had been hoping to have something directly attached to the actor that’s moving, like a transform property on a custom component. This would make the association clearer in the UI, and it would be much easier to connect it in the runtime. I’m worried that the Sequencer UI will get confusing when there are multiple cinematic actors and multiple move targets. Hopefully all that can be addressed with less effort than a custom track type.
You could indeed have a MoveTarget component on the character itself, instead of using a separate actor… although of course that may become a problem if you don’t have a 1:1 match between move targets and characters. Also, don’t forget you can use APIs like component visualizers and other editor gizmoes to make your MoveTarget component look unique, with cool UX features for your users.
> I’m wondering how I would add functionality to existing tracks without just copy-pasting the code and making a new track type. Is there anything in the roadmap that would address this?
We don’t have anything on the roadmap to address anything like this, but we would need to figure out exactly what the use-cases are first. I wonder if you’re maybe mixing up the UX of animating your actor/component properties with the UX of working with your actor/component properties. Sequencer isn’t meant to have custom UX for animating a property of type XYZ on actor class A vs actor class B. Keyframing and animating a Transform property or a Float property or whatever is meant to have the exact same UX and underlying code regardless of what that property is and what object class it lives on… just like, say, a Blueprint node that sets a property of type Transform or Float is always going to look the same (a Transform or Float pin) regardless of the situation. This may actually be a good exercise: if your users could setup MoveTargets outside of Sequencer, using Blueprint or whatever, what would it look like?