New in 2019.1 - Timeline Signals

Sweet!!! I was worried this was dropped from the roadmap.

 

Having signals be empty objects seems counter-intuitive to me. Shouldn't there be, by default, a way for signals to have information embedded in them?

Say I wanted to have a Timeline with multiple explosions, to go in line with your example. But say I also wanted all of those explosions to be slightly different. Would I need to create, for every explosion, a different signal?

And then, worst of all, whenever I created any other Timeline, would all those signals be shown in their dropdowns, even if they have nothing to do with those signals at all? This last part seems to be easily solved, at least in the abstract, by embedding Timeline and Signal objects in their Scenes instead of their own separate assets. That way everything that matters could be referenced easily and you wouldn't fill you dropdowns with an endless number of useless things.

But really, even having to create multiple signals for basically the same thing in the same Timeline bothers me conceptually. I'd very much rather have the marker itself be responsible for the parameters used by the Emitter, or whatever other abstraction which would allow me not to need creating a million Signals for very simple things.

Markers, Signals, Emitters and Receivers being 4 separate things looks like a lot of overkill to me and kind of seems to break the purpose of having everything that happens neatly packed in a timeline. I think I understand the wish to have decoupling from Scene references into Assets (it's something that comes a lot into my mind), but it'd be much better to have it be an option, not a necessity.

 

Great job. I like the decoupling of actions.
Andrew: If you wanted that you could just make a custom script and control the randomness from normal variables etc.
I presume, since it's UnityEvent the timeline can also pass variables into function calls, which would allow it to control complex functions without having to hack in programming like functionality into timeline.

 

The idea is not randomness, it's actually quite the opposite.



Basically, I don't want to have to create a different Signal Asset for every single set of slightly different function calls. It would pollute the signal dropdown stupidly fast.

 

Ok, I assumed it worked like the Animation events, where you could call any function and EACH call could have unique parameter values passed through. It seems like this doesn't do that.

Also these functions work except the multi-parameter ones. Which I think should be supported. The old events only took one and it was quite a hassle.

Code (CSharp):

1.  
2.     public void DoThings()
3.     {
4.         print("DOthings");
5.     }
6.     public void DoThings2(int num)
7.     {
8.         print("DOthings "+num);
9.     }
10.     public void DoThings3(string str)
11.     {
12.         print("DOthings "+str);
13.     }
14.     public void DoThingsGO(GameObject go)
15.     {
16.         print("DOthings "+go.name);
17.     }
18.     public void DoThings4(int i, string s)
19.     {
20.         print("DOthings");
21.     }
22.     public void DoThings5(int i, string s, GameObject go)
23.     {
24.         print("DOthings");
25.     }
26.  

It appears that each keyframe shares the parameter values with the Signal file? I was wondering why he created two signals for each foot, when I assumed it'd be just adjusting the parameter values passed to the function.

Trying to set the 3 keyframes to different values failed for me.

 

Shouldn't the Timeline .playable asset hold all of the signals instead of us having to create and save each signal asset inside the Assets folder? Because for me it looks like the whole signals system just isn't how it should be done.

 

Thanks a lot for the pressie - I think we might have to start making moves toward timeline integration now.

 

The example project in this thread is exactly what I was talking about! Shouldn't something more like that be offered as default behaviour alongside the signal stuff? I can see it's mostly quite simple stuff to implement by yourself if you know what you're doing, but not having this as a built-in and recommended way of doing it only serves to preemptively destroy any possible consistency between projects.

 

At first glance it does seem a tiny bit over-engineered... A bit 'enterprisey'...

 

Sounds interesting.

Can an SignalAsset be extended in order to add it properties that can be retrieved by a SignalListener ?

Does that mean that with the current workflow only one SignalReceiver can be "bind" to a SignalAsset ?

There were a lot of videos and hype about ScriptableObject to handle properties and events - it would have been cool to have a SignalAsset to be like this - meaning be able to trigger when the SignalEmitter is "consumed". SignalReceiver could simply registered to the SignalAsset. It would allow to have more than one SignalReceiver "listening" to a same SignalAsset.

Thanks

 

Yay Adobe Flash!

 

Lol. I must admit to sometimes missing timeline based style of development. It became unfashionable in the same way VB6 click and drag dev did - for some good reasons - but you can't beat it for speed and convenience and accessibility.

 

> Signals Assets are just an id

then

> We want users to be able to reuse signals between different timelines

I might be misunderstanding here - if signals are just an ID then what's the benefit in enabling reuse?

 

@julienb, thanks for the response, even if it took some time.

I do understand the advantages of the system and, given that you agree the dropdown problem is a thing and plan to solve it, I do agree it's the best overall approach.

What I still don't like about it, though, is the fact that it is obligatory. There are usecases for embedded signals and messages. Most signals I can think of actually make more sense if embedded in a Timeline. What I think should be possible is the choice between embedding them or not, and the ability to Convert between them automaticaly, kinda like how Bolt allows you to do between Embed or Macro sources.



And the thing is, the workflow around it would not even differ a lot. It's just a matter of allowing Signal Assets to be embedded into Timeline Assets and have Signal Emitters and Receivers choose between a "global" list of signal assets or the one from inside the TimelineAsset itself (in the case of Emitters) or a given Timeline Asset (in the case of Receivers).

If you started using an embedded approach for simplicity and later decided to give the event for someone else to work on while you are still working on the Timeline, a simple "Convert" button would give you the dialog to create the Signal Asset outside of the Timeline Asset and fix all references on emitters and receivers to follow the new approach.

The same thing could actually apply to Timeline Assets themselves, and to most other asset dependent approaches, like Post Processing Profiles or Animator Controllers. These don't have much of the same problem as Signals are bound to have, as the amount of assets you create for each type is probably not that big for any given project, but to have that extra bit of control would be marvelous for dealing with huge amounts of single-use assets.

I don't know how you would solve the dropdown problem, but I do think this is a good direction for it. It's not direct messaging, which would still be nice for the simplest of things, but it doesn't complicate the system any more than it should. I'd argue it even simplifies it. And it would be compatible with other ways to aggregate Signal Assets.

Well, I think that's all I have to say for now.

 

I agree with everything said here. It's really more of a UI issue.
How about allowing the user to directly enter the parameter values like the old system, but for each DIFFERENT set of parameters you'd just generate a new file. You could pop up a dialogue if this was too much 'magic' for UX purposes.

I also agree with @AndrewKaninchen that the option of embedding the actions in the timeline itself is good, because I'd guess a lot of use cases would be unique to that one timeline (eg your example of footsteps) and yet more files to organise isn't good if it's never going to be reused. I'd default it to embed even. "Nodecanvas" allows embedded or files, for its BT's and FSM's and it's very handy.

I actually think all animations/timelines should default/have the option to embed the animation file into a GameObject. To allow tidy one-off animations. eg a simple cube turning, shouldn't generate external files to manage.
A lot of people will use an AnimationCurve to get the 'embedded animation' feature. This is a nasty hack when the animation window should be better 100% of the time (ps Animation/AnimationCurve etc component should output c# events for generic value data). Unreal does this well with the generic Timeline node (BUT you CAN'T separate that into a reusable file, so a convert button would be great)

 

If you always solve the most general case, it comes at a cost for the common case.

"Simple things should be simple, complex things should be possible."

Beauty, clarity and readability in API design is often way too far down people's list.

 

Funny you'd bring up Bolt, I'd been following this thread very attentively for another project of mine.

I agree with all your feedback, although I'm not too worried about asset cluttering or the dropdowns. The easy solution is just folders: place your signals in proper subfolders, and have the signals dropdown respect folder hierarchy as submenus. (Although I doubt that UI quirk will be fixed anytime soon, seeing how the dropdown menu for Script Execution Order or even long enums like KeyCode have been horrid to navigate for years and nobody did anything about it. There's a reason why Odin and Bolt both include their own dropdown/fuzzy finder!)

What does bother me is that I fail to see the benefits listed by @julienb (flexibility, reusability, etc.) outweighing the abstraction that would be provided by parameters. The lack of parameters & arguments will probably mean I'll never use the built-in signal system. And I mean that. In almost all my use cases, I need some configurable float, string or game object to be passed along the event, something that Animation Events and Unity Events both already allowed. That's what made them powerful: abstraction, albeit rudimentary. Design-wise, this seems like a major regression.

What puzzles me to no end is that the timeline team went to great lengths to introduce the concept of object bindings, which allowed scene reference from asset files. (That's amazing, by the way!) But the signals architecture goes in the entirely opposite direction, by using scene-agnostic assets instead. With bindings, it seems to me that triggering Unity Events (with or without parameters) directly on the track binding would have been trivial, both to implement and to use. With signals assets, emitters and receivers, there's much more bloat inside the engine and a lot of new concepts to learn for users, on top of the existing Unity Events and Animation Events.

As a long-term Unity user I'll find my way around (or rather: I'll implement my own markers that send UnityEvents directly to the track binding), but I can't imagine a beginner being presented with animation events, Unity events, signal assets, signal receivers, and signal emitters and having to figure out which piece of the puzzle matches the other.

 

@Ludiq please consider releasing your solution so others can make use of it too, sounds like you really know the use cases well.

( If unity does not implement something like you mentioned )

 

@sebastienlh If signal assets only exist to allow consistent naming and mass renaming isn't that the rather a case of "using a sledge-hammer to crack a nut"?

I assumed that anything using an external asset did so because a) that asset had a certain degree of internal complexity and b) there's strong reasons to allow reuse between scenes in a way that isn't handled by other means such as prefabs etc.

The cognitive and management overhead of having standalone assets is fairly high for something that's basically a string.

(Even in cases where a and b where valid assumptions I've found creeping assetification (to coin a phrase) just makes life harder. I've now got to carry a complex mental list in my head about what's safe to edit without breaking other scenes and what isn't. Looking at you post-processing... Now add in version control and multiple people working on a project - there's loads of fun to be had :-( )

 

That's also what I want to say.We need timeline signals badly.
Will Timeline be a part of PackageManager someday?So that we could upgrade timeline features individually.

 

Hi, Is signal guaranteed to be invoked with low FPS? Classic Timeline event are skipped somtimes when application's FPS is low.

 

No offense, but I'm not seeing this at first glance.

It sounds like you are assuming everyone has already adopted the Asset database workflow you briefly mention here -- and I assure you, that is _not_ already the case for most users.

Unity is like a big puzzle to new and old users alike. And that rarely changes since Unity itself is always changing. Some parts are easy to put together out of the box. Others are better served by the Asset Store, and still others are better served by one's own solutions.
Unity is inconsistent (at best) in clarifying which approach a user should be using as default.

IMO, when offering a solution, it is Unity's main responsibility to point out that there is one singular and particular workflow that makes the default option viable in the way it was engineered or envisioned. We keep running into this same cycle of overly complex (in appearance) engineering efforts, followed by justification on the hows and why's. Expecting users to intuit the very-specific workflow (in its entirely) that was specifically envisioned by Unity engineers (without broad input from the community) is dangerous. I've only heard about asset databases being part of the ideal way of using this workflow via an offhand comment by Unity team in _defense_ of the seemingly-convoluted feature. Your decisions make sense now that they were explained here, but how else would anyone but the engineers be able to intuit the proper workflow?
This is not a one-time lack of communication either...

Thanks for your efforts guys. I really mean that.
I just think we need to improve on the "this is great for _you_ because we did ___ to improve your workflow on ___ and ___ use cases." Just simply saying "decoupling stuff is good" isn't enough to answer the hows and why's of _my_ desired use cases.

 

Very confusing feature.

 

I have two questions, or more like suggestions maybe, regarding this all signal asset thing:

if signal assets are just a way to add tags to a list of tags, such as we add layer names or sorting layer names, on a per-project basis, why don't stick to the already well known workflow? why don't just add a window that edits a persistent table project-wise where we define signal names, instead of having to keep track of actual individual files, even more where the filename is restricted by the OS file characters limitations? also consider what happens if the user by mistake deletes a folder that he considers no more usable but that folder contains signal assets? this method introduces a lot of human error to the workflow, having a unified list of names somewhere in the project settings maybe, or wherever the list of sorting layers is saved, is simpler, less confusing and less prone to error I think.

second suggestion: whether you keep with the signal asset design or change it to a more centralized or unified window in a project, the signal names could accept names with backslashes, such as "explosions/big explosion" or "characters/john/screams", and then you could make the signal name dropdown menu UI similar to the "Add component" button of gameobjects, where you can search for components in an organized, hierarchy-like manner. this can solve at least the problem of having a gigantic list of names that occupies the full screen height. and encourages a good practice of organization to the user.

EDIT: I also realize even more design problems with using files as identifiers, this means you are adding even another step of computation to the infamous "Checking for changes" loading bar of unity, since you need to do a project-wide search of files to find all signal assets every time you open unity, or in case this is cached, every time the library folder gets deleted, or every time a user downloads a fresh Collab commit, I really like the improvements in the signals area of timeline and the hardwork, but I still can't find any use case where keeping individual files is more useful or intuitive than just keeping a list in the project settings, see when people started confusing signal assets with something else and not understanding they are just identifiers/tags, that's when you can suspect the design is over engineered.

 

Hello Sebastien,

Are there any plans on supporting a Timeline Signals system version that has signals embedded inside the Timeline asset itself? (I'm not really a fan of having +100 signal assets inside my Assets folder, and well, it looks like a lot of people in this thread would prefer this way)

Greetings,
Jakub

 

Actually when I was writing this I was very wrong. I have an OnMissionEnd() method that I need to call at the end of each mission ending cut-scene and I was thinking that I would have to create 100+ unique assets for that (Since my game will have +100 missions), now I realized that I only need 1 asset for that Sh*t. So that now I actually think about this It's actually better to select an asset from the Dropdown rather than to select MissionManager in the hierarchy, drag into the UnityEvent field and then select that method every single time. I didn't had time to test it out yet (I tried upgrading to 2019.1 but I got some errors so I reverted back to 2018.3) and I wanted to ask, will the signals copy when I will try to duplicate the Timeline asset?

 

In the future . Can I play timeline use like "Go to "signalss name" " ? jump to time.

 

How about simply being able to pause the timeline via signal and jump to another moment (or signal) on the current timeline (or to another timeline entirely?) How about if you need to evaluate an expression at that moment, then if it's false go to another moment on the timeline? I've not yet seen a built-in solution for this kind of thing, so what's the officially-suggested process?

 

thanks very much ! :>

 

I have something working like this in 2018.2, you can just create your custom track and clips and program them to act like this, I had taken as a starting point the github project https://github.com/UnityTechnologies/ATerribleKingdom

there you can check how to create custom tracks that work the way you want. Yeah, it would be nice if this comes out of the box from unity, but that will probably not happen, they can't create functionality for every special use case, instead they expose the API's and interfaces for us to create our custom solutions under their framework.

 

This should work great, assuming a script could be run at any point on the timeline that lets one take multiple arguments (from any gameobject), then tells Timeline to hop to a given repeat point in the timeline.
A nice treeview / graph-node visualization (for the conditionals) could be great for referring to particular "repeat" points on this particular Timeline too.

@Cleverlie mentioned the "ATerribleKingdom" project --
I definitely think this "repeat marker" and "conditional loops" feature could definitely give more people a different view of Timeline in regards to the idea that "What? It can _easily_ be used for more than just _cutscenes_??"

Just my two-cents.

 

Is the invoke order of receivers deterministic?

 

@julienb @sebastienlh Please remove the Signal Asset, I find it so redundant, unnecessary and cumbersome.
Just an empty id scriptable object that you must create and link to everytime you use a signal!
Can't you link the emitter and receiver directly or write/read the emitter in the Timeline asset directly?
Please simplify it before release.

 

while i appreciate the effort and find some things i like about the design, like many others here i'm already finding more to dislike... we finally get signals, but:

1. it's 2019.1 only (!?), meaning i'll still need to maintain my custom markers + events solution for legacy and in production projects. meaning i'll have maintain two different systems through 2019 for something that feels like it should have been a part of timeline back in 5.x or 2017.x or whenever it was fully released.

2. lack of built-in parameters. like others here this means i'll probably never use the built-in signals. this really should be part of the core package and NOT in the asset store, where official unity packages seem to go to die (and become unsupported).

3. markers have no duration. i can totally understand why they were designed this way but it doesn't take long to come across use cases where it makes sense for certain marker types to have this. so i'm back to my custom solution which supports this already, and having to use that wizard :/

it really does feel too much like solving the general case vs the common case. we're getting something kinda cool but that i'll never use and meanwhile other vital things that should be part of any basic sequencer are still missing, like marker based controls for intelligent stopping, starting, looping, etc, which are maybe-kinda-sorta scheduled for 2019.2.

play with other sequencing tools, like exists in unreal. play with tools from also other domains, like logic, ableton, protools, etc. live in them. watch your users play with them. watch them live with them. watch them play with timeline. watch them try to live with timeline. i don't doubt you're not already doing a lot of this. and i understand the task is complicated. and i understand good things take time. but it feels like this tool (and frankly, a number of other tools) are perpetually stuck in whatever point in time they were released.

burn that oil