Timeline events?

@seant_unity

Would the fix for animation events allow one to setup a 1 frame animation that would execute a script that could pause or stop the currently playing Timeline, execute some kind of action, then resume the Timeline?

What would the workflow look like to get this behavior?

 

Do you have an idea which of the 2017.3 betas will include this fix? I've looked through the release notes up until "b4" but it's not mentioned in there.

 

@mgeorgedeveloper it's indeed on it's way for merge in the main branch right now. Hoepfully it will be available for 2017.3.0b4. The release notes are only updated when the merge actually happened.

 

I dont mean this in a sarcastic way so sorry if it comes across as this, but what exactly is the point of releasing a timeline system without events?

I mean it seems like the biggest waste of resources ever. Everything it can do can be done with a mecanim state system and just some simple programming (heck even just copy and pasting).

All this rubbish about it being the headline feature of 2017 and it turns out to be a semi finished cut scene tool and nothing more.

Why tout it as being a tool that will help designers become more proactive in development when you know deep down that due to the cuts you made right before release, it is now nothing more than a cut scene tool.

Very unhappy, every time I think "I might subscribe to paid unity" I see what terrible decisions are still being made and think "still no".

So many years and still the same terrain system? Still no nested prefabs? Some things are very backward here still, and thats why my money wont be going to unity yet. I would have paid for some of the extra services like Unity Teams but the engine is primarily why we come here and until that is the main focus again instead of stretching paychecks from users with all this extra paid ****, I just dont see value for money.

 

I can see where you're coming from -- BIG decisions are being made very poorly these days -- but I don't think it's the engineers at Unity Team's fault -- I think the problem is much more deeply rooted!


It likely comes down to the Unity app becoming a quick cash-grab for some big-wig investor with an exit strategy -- a guy (or group of guys) who don't plan to stick around to see it fail.



Sad thing is, the Asset Store has become their flagship product these days too, for a similar reason -- and even that isn't being handled well at all.

The easy-but-hard answer is that investors hierarchically force engineers to prioritize high-profile features (i.e Timeline) and get them out the door as fast as they can, while ignoring the long-term struggles with broken (or completely missing!) features that devs like us have to deal with when we try to use the 'features' we do have. The 'broken' features are dealt with somewhat, but the missing ones are put on the backburner indefinitely since it does Unity's investors no good to undermine the Asset Store, where creative users used to make things to supplement those 'missing' features for them AND make money for Unity big-wig investors on top of that from the 30% cut from anything the user sells!

Trouble is -- as an Asset Store developer who has made a great creative tool (Snapcam) to thwart some of the issues of moving around Unity scenes -- it is near-impossible for me to make money off of my asset because I have to charge YOU (my developer brethren) more money than I am comfortable with to make anything worthwhile on it due to Unity's 30% cut just to HOST my asset. Lowering this price wouldn't be as much of an issue if there were more customers, but there's NO marketing effort whatsoever on Unity's end, or any attempt to make creative assets like mine (that will genuinely HELP users enjoy THEIR product more) stand out and be more visible to potential customers (so I can safely lower my price). I've got no idea how they think making such a percentage is justified OR a good business strategy -- because, on top of that, it took them literally a MONTH to review it, and it just sits there collecting dust until I find time to market it myself. Even then, I have to compensate for their greed. This leads to devs like me to not want to create (or even share!) their creative tools on the Asset Store because they feel wrong for charging for what their work is actually worth without having to cheat someone (probably in the same boat as me financially) out of their money (in the investors' stead of course!) to get back that chunk of money those guys pretty much stole from us both. In response to this, users generally wait for the sales before they buy our work because they know we Asset Store devs have no choice but to eventually drop our price. -- It should be clear by now: this is just a system begging for disaster.

Maybe the long-term investors will boot the cash-grabbing ones out of the picture.

We can only hope.

 

Is this thread still the best reference for how to hack events with the Timeline or have people come up with a more robust approach?

We're using the approach described by @WikkidEdd1 and it does the job but it feels weird to essentially duplicate the functionality of the graph/mixer that makes the underlying timeline playables work but not actually replace it. Perhaps there's a way to prevent it from generating the normal graph and just have a single Playable that does the work instead?

 

@WikkidEdd1 that works great for getting hold of exposed references for the clip. Is there is a similar way to access the "track binding" object within the property drawer? You know, the main output object on the left of the track that is exposed to the track mixer?

 

(EDIT: further down is an updated post with a Unity package.)

By combining techniques given on this and other threads with a healthy dose of reflection and some delegates stuff, I've managed to come up with a fairly robust events system that works as shown in the image.

(It's actually really simple, but all the damned lines in the image makes it look overly complicated.)

In short:
- Add a "Timeline Events" track (or more than one if you want)
- Add some clips on the track.
- Associate any GameObject with any clip (optional on a clip to clip basis).
- Call event handlers at the start and end of each clip, targeting....
- ....the associated GameObject per clip
- ....the track's GameObject (track binding on the left).

Notes:
- Event handlers are populated via reflection.
- Event handlers are invoked via delegates at runtime.

Pending some further testing, I will make the code available if anyone will find this useful.
Let me know your thoughts.

 

Looks very nice -- thanks for the color-coding too!

I think I speak for everyone when I say it would be much appreciated if you released this. Lots of us don't have time to dig into this right now to roll our own solution and reinvent the wheel, so anything you would be willing to share with us, it's just that much of a leg up we'd have until Unity 'fixes' this issue one day arbitrarily in the future.

If you were looking for ideas on improvement, the only thing I could see that could be 'better' is perhaps a label or two in the inspector that separates the "this" gameobject (in the clip) from the "that" gameobject.(allocated as the explicit target).

2 questions:

• As it stands now, I'm mildly confused as to what "FancyCubeBehavior" represents. Is that an EventHandler? What does "GoBig" come from in this case? Is it an animation, another timeline, a script, or what?
  
• Also, what is the difference between the gameobject associated with the track vs. the gameobject associated with the "target" or whatever -- don't they both do the same thing essentially simply because you can only have one per track -- or am I missing something?

 

FancyCubeBehaviour is just a MonoBehaviour like any other, with some public methods on it (in this case, GoBig() and GoSmall()). The reflection bit looks for any MonoBehaviours on the associated objects, then exposes any public void methods without parameters. (currently no support for parameters in this first version)

On the left of the track, you will see Cube1 is referenced there. That's the main output binding for the track. For example, when you have an audio track, there would be an audio source there, and the audio clips running along the track would be mixed through there. For the events system, we don't "mix" anything, so I just use that track binding as an alternative target for events, accessible per clip (orange stuff).

Then, if you look at the clip inspector in the screenshot (the first clip on the track is selected), you will see there is a slot for dragging any GameObject there as well. In the example, Cube2 has been dragged there. So for each clip along the track, you can reference any other scene object as well, and it would usually not be the same one as the track binding on the left.

So, ALL clips can fire events on the track binding (Cube1), and EACH clip can fire events on its own associated scene object as well, thus a total of 4 possible event handlers per clip.

 

@awesomedata,

Unity Package (WIP): http://farflunggames.com/download/Far-flungCreations_Timeline_Events_v0.1.zip

Unity project with demo scene (includes the contents of the package): http://farflunggames.com/download/FarflungTimelineDemos.zip

Fixed some things, and improved the inspector UI - it should make things clearer. It also has various warning/help messages built in that will pop up in different circumstances.

This is still WIP though.

 

This is really great. Thanks man.

Definitely a lot easier to understand now! -- There is only one thing not entirely clear interface-wise, but I think it may just be a matter of grouping -- would you mind adding something like this for each control group?

https://docs.unity3d.com/ScriptReference/HeaderAttribute.html

So, as I'm understanding it, this can fire either track events, clip events, or both simultaneously right?

Can you pick just one or the other to ignore events for?

Also, how difficult would it be to add arguments to these methods through the editor/inspector there?



Just FYI -- your .unitypackage link is not working, though the demo one is.


Thanks again for your hard work dude. This seems like it's exactly what many people here are looking for. Very usable, even as-is.

 

I will have a look, no problem.

Correct - use track handlers and/or clip handlers within one clip, and optionally fire events at start of clip and/or end of clip. Any combination. Pretty flexible.

I will play around with that instead of saying "simple" or "super impossible".
I will refine things over the coming days as I'm experimenting with actually using it in our game
It helps all the pain points to be identified.

Fixed package link: http://farflunggames.com/download/Far-flungCreations_Timeline_Events_v0.1.zip

No problem!

 

Hi,

Sorry.. tldr.

But.. do you have a link to the https://feedback.unity3d.com post where I can vote for this ?


Best
Greetings

 

Just wanted to share what I do to call events. I am using the text switcher from the Default Playables package, from there I have a Manager script on an empty game object which is set up to be pointed to all the functions I need called. the manager script points to the text object that is linked to all my text switcher tracks so that when a certain id string gets called through the switcher track my manager knows what function to fire. its very straight forward and awesome because I can have the text object on screen during testing so I can see what's firing and where problems lie.

 

Clever! Worked great for me. Thanks.

 

Great solution, thanks!

 

@mgeorgedeveloper

Awesome work! Your approach is more flexible than what I was working on. Would you mind if I use your event system im my project? Would really save me much headache

 

I don't mind at all, please go ahead. I dumped a package somewhere above. I still have to add parameter support to the event handlers, but at this moment the stuff I'm doing with this system thankfully works OK so far on event handlers requiring no parameters, so I've been holding off.

 

Thank you!

 

Just wanted to emphasize the need of triggering events from timeline.
Hopefully a solution is in progress.

 

@mgeorgedeveloper Thanks for your package. It works very well!

 

@mgeorgedeveloper -- I totally second that! -- Seems Timeline isn't going to have events in 2017.3 either is it?

 

2018.1/2018.2, Early-mid 2018.

 

Unity please get some speed into your imemtentation of events!

I had this working in production in games already 5 years ago with the help of aperure plugin, which is now depricated.

 

To be totally honest -- that's quite irritating. Sure, it's coming, but why put Timeline out there as a "new feature" when it's clearly not finished? -- In the software-dev world, this style of implementation is usually called "experimental" -- or am I wrong for this label? -- After all, if Unity Team is nearly redoing the whole thing, then how can this be considered done?


If that's legitimately their timeframe and they are *not* redoing most of it all over again, wth are they looking to accomplish in the meantime?? -- If this was an independent dev making an asset, that's one thing, but this is A HUGE CORPORATION, with lots of employees, but apparently not ever enough employees to manage all these important tiny-but-practical features -- only the next new "super cool new VR featurez!!" seem to matter these days. :/

Granted, it's not like we can't wait patiently (and usually indefinitely too) until we're forced to just roll out our own solutions -- but why should we always have to supplement Unity's half-implemented features?


Not everyone has a team of engineers working for them... but... wait. -- I guess Unity does.



Sorry for being so pointed guys -- but this just seems like a trend that is never going to stop.

 

Had to finally look into Timelines and could not believe that such an important feature is missing. At least we can implement our own playables. Thumbs up from that!

There are some good and some not so good implementations suggested here. Being able to call custom functions from a timeline is one thing, but for me much of the power of events is based on publish-subscribe pattern, where the publisher (or in our case the timeline event) does not have to be aware of the subscribers. This is why I mostly use native C# events.

In my opinion the simplest method is to use the OnBehaviourPlay and OnBehaviourPause callbacks to launch static C# events. To make static events any useful, we need to get the reference to the PlayableDirector, which is playing the timeline. The reference to it can be grasped in CreatePlayable method. It may also be handy to have a reference to an additional target object and to have some parameters.

You can then listen to any timeline without having to setup references in the editor simply by registering to TimelineEvent.Playing and TimelineEvent.Paused events. The event has to be static, but we still need to know which timeline is sending the events. That's why we have the reference to the director, which is provided to the listeners as an argument. Via the director, we can also query it's state etc.

Partial code:

Code (CSharp):

1. [Serializable]
2. public class TimelineEventAsset : PlayableAsset, ITimelineClipAsset
3. {
4.     public bool launchEventsInEditorMode = true;
5.     public ExposedReference<GameObject> optionalTarget;
6.     public string optionalArgs = string.Empty;
7.  
8.     private TimelineEvent template = new TimelineEvent();
9.  
10.     public ClipCaps clipCaps
11.     {
12.         get { return ClipCaps.None; }
13.     }
14.  
15.     public override Playable CreatePlayable(PlayableGraph graph, GameObject owner)
16.     {
17.         var playable = ScriptPlayable<TimelineEvent>.Create(graph, template);
18.         var instance = playable.GetBehaviour();
19.         instance.launchEventsInEditorMode = launchEventsInEditorMode;
20.         instance.director = owner.GetComponent<PlayableDirector>();
21.         instance.optionalTarget = optionalTarget.Resolve(graph.GetResolver());
22.         instance.optionalArgs = optionalArgs;
23.         return playable;
24.     }
25. }
26.  
27. public class TimelineEvent : PlayableBehaviour
28. {
29.     public PlayableDirector director;
30.     public GameObject optionalTarget;
31.     public string optionalArgs = string.Empty;
32.     public bool launchEventsInEditorMode;
33.  
34.     public static event EventHandler<TimelineEventArgs> Playing = (sender, args) => { };
35.     public static event EventHandler<TimelineEventArgs> Paused = (sender, args) => { };
36.  
37.     public override void OnBehaviourPlay(Playable playable, FrameData info)
38.     {
39.         if (launchEventsInEditorMode || Application.isPlaying)
40.         {
41.             Playing(this, new TimelineEventArgs(director, info, optionalTarget, optionalArgs));
42.         }
43.     }
44.  
45.     public override void OnBehaviourPause(Playable playable, FrameData info)
46.     {
47.         if (launchEventsInEditorMode || Application.isPlaying)
48.         {
49.             Paused(this, new TimelineEventArgs(director, info, optionalTarget, optionalArgs));
50.         }
51.     }

 

http://hutonggames.com/playmakerforum/index.php?topic=15465.0

Here's something for people who use playmaker.

 

The way I've used events in my games is this code that I add to a gameobject.

Code (csharp):

1. public class TimelineEvent : MonoBehaviour {
2.  
3.    public bool FireEvent1;
4.    public bool FireEvent2;
5.  
6.    void Start () {
7.        if(FireEvent1) { Debug.Log("FireEvent1"); }
8.        if(FireEvent2) { Debug.Log("FireEvent2"); }
9.    }
10.  
11. }

Then I drag this gameobject to the timeline to the place I want it as Activation Track. This way you need to add one gameobject per event for scene, but since in my game I only use timeline for cutscenes they don't usually have that many events that I need.

 

It would have been better to release with events, and later make a bug fix than to cut it.
At least we could have worked in the mean time, now we just have to wait another 6 months.

 

I'm a bit confused as to why the Timeline events are such a technical challenge. Surely it's a case of Event here, call this, pass this. Whats the big deal? It's almost like it's left out to annoy everyone, maybe it was just too powerful for the public to use. Maybe we need to buy it from the asset store.

 

This is currently my solution to Unity Timeline lack of event triggers. The idea is so you don't have to hard code an event.

Edited: Now that I think about it, you can do the same approach but with just a boolean and it'll be a lot easier than setting numbers.

 

How did you do the unity Event listener? I tried for _HOURS_ to get a unityEvent to work; but it wouldn't let me bind to anything in the scene; only assets. Would love to know how you did this!!

@Unity devs - how long till events make it in - still not in 2018 !?? we've got 3 half-baked solutions here; surely you guys have nailed this by now?

 

Good news!
Hope the 2018.2 will not take that long to land, ( probably 5 months )
And 9 months for 2018.3.

 

That is atrocious. Dont market it as the headline feature then of 2017.x then! Who is making these ridiculous marketing decisions, its making people lose faith not gain it!

 

As of 2017.3, animations played via timeline still do not execute their own events. I've tried to drive event triggers by using OnEnable as the trigger in a script attached to a game object being toggled by a Timeline activation track. My final results show that activation tracks only execute about 75% of the time (even worse when CPU is under heavy load). How did Timeline ever get into Beta (let alone release) if activation tracks do not work 100% of the time?

 

We're now firing events via coroutine in C# instead, so Timeline may as well not exist in our current project. Many hours were wasted on it. I thought for sure there must be a way to get it working, otherwise it would not be touted as a released feature. I was wrong.

I'm a Unity dev w/ 8 years experience on this platform, and I currently use Unity every day at one of the largest VFX studios in the world. If my vote counts for anything, then I vote for Timeline to be put back into experimental status until it is ready for professional use.

 

I've seen something like that when using a similar workaround. Were you using very short activation clips by any chance? It seemed to me that my clips were being skipped when under load because the frames that included my activation clip were being skipped.

 

Even if they're super-tiny, there should be a preprocessing pass of the timeline track to be sure that nothing gets skipped.

They may be small, but they should at least register.

Either it should internally snap the clip to a given precision, lengthen the clip size, or make a notation that there is a clip at that point in time on a separate (parallel) track so that the system recognizes it existed. This is a standard issue with framerate-dependent things, and although Timeline is, to some extent, framerate-dependent it should at least "snap" to nearby events in some way to avoid completely skipping them if they're tiny.

Unity's Animation Window has had trouble with this for years, which is why they are so against "stepped" animation curves (for stuff like stop-motion or 2D animation framerate simulation).

 

Many of them were 0.1 seconds each. I hadn't noticed a correlation between short clip length and execution failure, but that's certainly possible in our case.

 

You have to know ... FLASH has TimelineEvents since 1999 ! We are in 2018, right now !

 

Just came across this thread and installed the Event Track extension posted by @seant_unity

Thank you so much for posting!

Also, is there such a thing as a repository for such extensions? would be very helpful for many, I'm sure.

 

There's a extension made by him? Can you post a link to it?

@seant_unity
Very short activation tracks (and later possibly events as well) not being triggered sounds like a bug.
Can you confirm that this is not "by design" and will be adressed eventually?
Also thanks for your hard work!

 

@dadude123

https://forum.unity.com/threads/timelin ... st-3185580

It's basically an event trigger for the timeline. It's so insanely useful I wonder why it's not included with the main package.

 

And all events in the time between would get collected and called? So no event ever gets skipped?

Being a dev myself I can see that it wouldn't be as "neat" or easy to do, but I think its the same old story of "do you want your code to be fast and easy to reat? Or do you want it to actually be correct?", no?

There are lots of things that could be done. For example only doing the "sweep" for tracks that actually want it!

If we have a cutscene that has an event which triggers some kind of interaction, and then that event gets skipped for whatever reason and a player is simply locked into the cutscene without any way to advance or break out of it... that'd be a bug that would be horrible to diagnose and fix.

This stuff shouldn't be by design.
People will use it for things you didn't anticipate - as is always the case - and furthermore timeline is (or will be) a core component of Unity, not just some random asset store package.

So personally I think that at some point sometimes we have to pay some price (in terms of code complexity, special cases) to get a solution we actually want.

There doesn't have to be any state machine setup. You already have a place (or rather multiple place) where you can do a sweep from old position to new; and only certain tracks will be affected anyway (tracks like activation tracks, whose ONLY purpose is to get triggered correctly)

 

I can understand where @seant_unity is coming from with Events being intended to handle this issue -- but as you said, "is it correct?"

Really, if the user cannot add really tiny clips without issues, at least throw him a bone when he's trying to add the really small clip that lets him know the problem and also the alternative + workaround with a warning message. (Perhaps a checkbox with the "ClipCaps" associated with the track/clip internally as @seant_unity suggested the other user to code for himself? I'm sure there are other users out there who will try small clips in Timeline and also wonder why it's not working, so why not make it available to everyone by default??)


That said -- I think the answer to the question of "is it correct" comes from how it is seen by those closest to the end-result (i.e. the devs using Unity for real products).

And due to the fact that it is (reasonably) seen as a "bug" by most Unity users, and just as "sloppy coding standards" by more veteran Unity users who have presented a "quality" code-based product to their users and have had to deal with "design" issues like this both from demands from their users -- as well as required heavy "workaround code" demands from some poorly-designed Unity + API features they require on a regular basis. Either way, I really feel stuff like this is genuinely a problem and should be proactively addressed without always hand-waving it aside.

I guess it boils down to the eternal question -- "Who should win this battle -- Unity devs or gamedevs?"



In this case, I think "the customer" should fit the bill... since they are "footing the bill" too aren't they? You Unity guys are customers too -- You guys don't want the smashed loaf of bread -- You want the perfectly good one right next to the smashed loaf of bread for /your/ money. Why should anyone here be any different? -- Sure, the smashed loaf of bread can make the same kind of toast -- but it's not great for sandwiches anymore. I guess we've all got to use the smashed bread (Unity) to make toast just because the Unity devs can't see why we might want to make sandwiches with "our" bread?

I really don't think it's so unreasonable to expect "fixes" for small things like this that are "only issues to one or two" because MOST people who have these don't ever speak of them. There's larger fish to fry, and a bug report is a pain in the ass when you've got deadlines.



I respect you guys' hard work for real -- I'm a developer myself. But because I'm a developer, I know from experience that this sort of thing can be dealt with before it's ever an issue as long as you are seriously thinking about the end-user from the very outset and onward throughout the project.



If you design something properly (that is -- if you design with the worst possible user in mind who exists solely to destroy your system and then complain it's broken), your code truly will become "correct" and smaller fixes like this are a LOT easier to manage. Perhaps that wisdom can at least be applied to the next "big feature" Unity plans to release? -- That, or fix your team / workflow / overall-mindset if it is a personal / manpower issue. Either way -- the product (Unity) needs to be handled (and programmed) correctly. Although "correct programming" is relative -- "correct to the user" is pretty clear:

If it seems like it /should/ work -- it /should/ work.

Tiny clips in the timeline /should/ work in an editor that clearly shows them there -- or at least give an error message / warning + workaround for things like this when the user tries to place a tiny clip in the timeline if you plan to have an alternative way to deal with them (i.e. Events). This is so that the user knows he might have to do some sort of obtuse code-workaround if he ends up "needing" something that breaks your system (such as tiny clips.) There should always be thought in this sort of thing -- and there would be if you were thinking of your users before yourself. Treat them like an old granny who has never touched a PC before. You'll generally be pleased at how pleased your users will be with you. -- Just my two cents.

 

I see that in a similar way.

Sounds to me like the devs have one specific use case in mind and for other problems they want to offer dumb "workarounds".

Everyone here already knows how this will end: people complaining, and simply dropping Timeline for their projects. ¯\_(ツ)_/¯

But when your actual customers don't use Timeline because it does not work for them*, then who are you even developing it for??
Isn't it a waste of time and money to develop something that people will find broken?

(*) It is a critical bug, even if you argue that its by design or whatever. Sure you can argue about design decisions and philosophy and whatnot, but at the end of the day people will expect this to work and they are simply not interested in the reasoning why it is like it is.

That being said, I do appreciate the hard work! And I don't want this to come off as an "attack", but there's a mistake being made here and it has to be called out.