is timeline being abandoned?

i'm asking that in earnest, figure out the toolset for the net project
perception that it's abandoned stems from multiple comments of inactivity and regressions in current package

 

Is it not possible to have parameters on those signal emitters? That seems like such a basic thing that you would first think about when doing this system. CBA writing boiler plate code for each signal.

 

Considering most of this thread is about the hated event implementation - something that has been complained about since it was released how come thats not listed?

Is someone at Unity still defending the design of this feature? If so could they please engage here and describe the use case that made this level of indirection neccessary? I've been watching this issues for a long time and all I've even heard is some vague handwaving that never really made much sense.

How much feedback do you need to reconsider the design of a feature?

 

These are only editor fixes though, they don't address fundamental issues like hiccups during async load.
If I'm making a cinematic and use it to load a bunch of stuff i can't use timeline, I have to preload everything which defeats the purpose of a cinematic. Such bug should be priority over lipgloss.

Even when i consider editor i see no fundamental ergonomics like the ability to manipulate a group like a clip - this is trax 101, XSI back 20 years ago had that.

 

Oh, I see, now I understand the changelist, thanks for clarifying.

 

playable.GetTime() is always less than playable.GetDuration() even on the last frame. This makes my Timeline extension never reach the last frame. How many years will it take you to solve this problem？

 

I would assume this is mandatory behavior or else the next clip butted up immediately adjacent would result in the old and new clip both being called. I assume the rule is you get called start <= t < end.

But I would agree it’s useful to know if last frame of a clip. I am trying to show a progress bar and it does not reach 100% because I want 0% to 100% inclusive. So planning to pretend duration of clip is end time minus fps or something. Want an inclusive duration for the clip. (But I have not looked yet!)

 

We can use custom blending to decide what to do when clips overlap. So there will be no conflict.

 

Hmm. For my case (not others) that would probably not help as I want to freeze-frame on the last frame at have it at 100%. E.g. I use Unity recorder in another track to make a recording, not flow into a subsequence animation. Overlapping with the next clip is not useful as the recorder would have to do that as well. So I think I just need the easier solution of "progress_bar_duration = clip_duration - delta_time" (probably delta_time * 1.5 for rounding errors) so the last frame before the clip end is 100%.