Inconsistency in relative timelines (Symbol actions vs. Timeline actions vs. API)

There is this inconsistency of using relative timelines in different settings:

Some prerequisites:

  • Triggering a (relative) timeline from the Main Timeline (using Timeline actions) doesn't show an IDE preview and works as expected when publishing
  • Triggering relative timeline from the Main Timeline in a symbol (symbol action) shows an IDE preview and resets the timeline to a base state instead of animating from its last position

For IDE key frames:
I am not sure why we get the preview in one case but in the other not and if we get the preview I understand that playing forward would create a specific set of events that would be different than the computed ones going backwards if relative key frames are involved. Basically, without the preview it would be two different timelines when baked. If one wants consistency with a preview at least one could bake the predominate timeline (going forward) and play that baked version backwards when scrubbing or reversing via action but currently the relative timelines in symbols are treated as regular ones when fired using Symbol actions dismissing their potential.

The API is actually working as expected:
Hence, when triggering relative Symbol or Scene timelines everything works as expected and probably shouldn’t be changed as this is anyway dynamic and there is no named timeline to bake.

Playing relative timelines backwards through the API:
The moment one triggers a relative timeline using the API or on a timeline action and running it backwards it takes a property temporary snapshot of the object at the moment of firing the command and sets the values to the endposition of the animation regressing back to the temporary snapshot. Thats fine and a probably the best solution…

Thanks for this report. To restate and make sure I have what you are saying:

  • the problem boils down to the fact that in Hype's Scene Editor, timeline actions do not run (and thus timeline-related actions don't do anything) but symbol actions (which are only timeline-related) do run?
  • Then this is compounded by the fact that the relative timelines kicked off by symbol actions will always display as absolute?

Its not that the actions don't run it is more about the inconsistency between symbolActions and timelineActions. But even with that I can handle as symbolAction with their previews are helpful sometimes. It's more about the second feedback (see below)

If symbolAction are treated differently than I would love them to somehow support relative timelines. Currently, the relative timelines used on symboActions are rendered as regular timelines or at least they don't pick up the last relative position and rather reset. As I suspected/guessed in the first post, relative timelines when "baked" (computed) would probably differ when rendered forwards or backwards if it was treated like a timeline action but as Hype previews the symbolActions … so, at least it could "bake" the relative timelines in the forward direction (most people would expect that) and then just play that "baked" version backward when user scrub. (37,3 KB)

1 Like

Correct; a relative keyframe is "reset" when the timeline is started (not continued) or a go to time in timeline is called. There's not really a way to 100% be like the running document, but that's not to say we couldn't choose something.

I'm not sure we'd ever have timeline actions run since this opens a whole can of worms. One aspect of multiple timelines is "property ownership" which would interfere with editing if an alternate timeline starts controlling a property animated on the main timeline. With symbols it isn't really a problem since when you enter a symbol we go back to a specific editor state.

This does remind me of another problem - that if you're on an alternate timeline, even a non-relative one, the originating state may not be what you expect. Right now we use the current playhead position of the main timeline as the basis for displayed properties, but this isn't always desirable. I've considered adding controls to manually choose a basis, but the UI complexity of this makes me shudder.

1 Like