Programmatically set up timeline


#1

It would be great to be able to set up or change a timeline programmatically.
For example,

timeline.addProperty(node.position);//add node’s position transform to timeline
timeline.KeyFrame(node.position, [0, 0, 0], 0);//add or change keyframe that sets node’s position to [0, 0, 0] at time 0

The main advantage of this is using variables to set up timelines instead of hardcoded values. Basically being able to adapt a timeline to specific conditions. In fact, extend this to controllers and states. I don’t see why you can programmatically set up nodes but not controllers, states, and timelines.

EDIT
I guess I love timelines, this is my third timeline suggestion :joy:


How to use timelines to animate variables that aren't "properties"?
Timelines with multiple start/end values
#2

Hi @marks,

Thanks for the feature suggestion.

Our timeline functionality was designed to be user-friendly and allow for visual feedback of the user’s timeline setup, so I don’t believe we’ll be adding this feature for the foreseeable future, as it would make it less accessible to our users.

However, I’ll mention this to the team and see what their thoughts are on it :slight_smile:

Thanks again,
Seb


#3

Our timeline functionality was designed to be user-friendly and allow for visual feedback of the user’s timeline setup, so I don’t believe we’ll be adding this feature for the foreseeable future, as it would make it less accessible to our users.

Hm, I think I didn’t explain it well. I don’t want any of the existing functionality to stop working, everything can continue to work as it is. But by adding this feature it would allow more power to the users. So who wants to keep using timelines as it is they can, but the feature would unlock more flexibility for those who want it. You can set up the nodes in the hierarchy visually by dragging the assets, but you can also do it with pure coding. So just more possibilities doesn’t take away the user friendliness. I fail to see that :thinking:


#4

I second @marks’s request - this would be a valuable addition. I disagree with @Seb’s suggestion it’d make things less accessible; if you don’t want to use this functionality, you don’t have to :slight_smile: But more importantly, Zap Studio is the most advanced of several authoring tools you provide us with, so “may make things more complicated for users who decide to try exploring this complicated new feature” shouldn’t ever be part of the criteria for rejecting something. Bring on the complexity! We can handle it

¯\_(ツ)_/¯

(𝗐𝗁𝗂𝖼𝗁 𝗂𝗌𝗇’𝗍 𝗍𝗈 𝗌𝖺𝗒 𝗐𝖾 𝗐𝗈𝗎𝗅𝖽𝗇’𝗍 𝗅𝗂𝗄𝖾 𝗀𝗈𝗈𝖽 𝖽𝗈𝖼𝗎𝗆𝖾𝗇𝗍𝖺𝗍𝗂𝗈𝗇 𝗍𝗈𝗈 𝗄 𝗍𝗁𝗑 𝗑)