Search Unity

New in 2019.1 - Timeline Signals

Discussion in 'Timeline' started by julienb, Dec 6, 2018.

  1. julienb

    julienb

    Unity Technologies

    Joined:
    Sep 9, 2016
    Posts:
    123
    Since Timeline released in 2017.1, there has been a lot of requests for events. With good reason; it was something that was sorely missing. Some people implemented events through clips (by the way, thanks to everyone who offered their custom event implementation to the community), even if, in this use case, clips had their shortcomings.

    Well, the Timeline team is proud to offer you an early Christmas present: signals are now available in 2019.1.0a11!

    A new item has appeared: markers!

    A marker is new item that can be added to a timeline. It is used to represent a point in time.
    Markers can be added and manipulated on a timeline the same way as clips; selection, copy-paste, edit modes etc. should work. A marker also has a specialization, just like clips (Animation Clip, Activation Clip, Control Clip, etc.). In 2019.1, Timeline offers its first built-in marker: Signal Emitter marker.

    What are signal emitters?

    Signal emitters are used to trigger a change in state of the scene when the timeline passes a given point in time. We used the word signal instead of event because it supported the idea of "broadcast" while avoiding the confusion with the already existing Unity Event and Animation Event.

    Where can I add a Signal Emitter?

    A Signal Emitter can be added on the timeline and on tracks (with some restrictions).

    - On the timeline: This is a new concept for this release. Signals can be added on the timeline itself. No tracks are needed in this case.
    - On a track: Signals can also be added to any track, as long as the track accepts a binding. We’ve also introduced a new type of track, a Signal Track. This track accepts only signals but no clips.

    Keep in mind that where you place a signal emitter will define how this signal is received. More on that later.

    How does it work?

    In order to properly set up signals on a timeline, you need three pieces: a Signal Asset, a Signal Emitter and a Signal Receiver.

    graph.png
    • Signal Asset: This asset is the link between an emitter and a receiver. Basically, the Signal Asset acts as an identifier.
    • Signal Emitter: A Signal Emitter is placed on the Timeline. It contains a reference to a Signal Asset. When played, if the current time is greater than the emitter’s time, the emitter is triggered; it will send its Signal Asset to a Signal Receiver.
    • Signal Receiver: The Signal Receiver is a component that has a list of reactions, each of those reactions are bound to a Signal Asset. When a receiver is notified that a signal has been triggered, it will invoke the reaction bound to the corresponding Signal Asset.
    The main idea that guided our design was to make the piece that sends the signals (the emitter) as independent as possible from the piece that listens and reacts to signals (the receiver). This design adds a lot of flexibility and is very powerful. Let’s see in details how all those pieces work together.

    The Signal Emitter

    1. Create a timeline. Then, click on the pin button near the edit modes button.

    2. The Timeline Marker area is now displayed. Right-click in the area under the time ruler and choose Add Signal Emitter.
    3. In the Signal Emitter inspector, click on Create Signal… to create a new Signal Asset to your project.

    4. Still in the Signal Emitter inspector, click on Add Signal Receiver. The inspector should look like this:

    The Add Signal Receiver button did the following:
    • It added a new Signal Receiver component to the bound object. If the Signal Emitter is on a track, the component will be added to the track’s bound object. If the Signal Emitter is on the Timeline (like I did in my example) then the Gameobject which owns PlayableDirector will have a new Signal Receiver component.
    • It added a new reaction bound to the Signal Asset I just created.
    I can then use the Unity Event UI to define what should be invoked when the Signal Emitter is triggered.

    The important part is that the Signal Emitter inspector first shows you properties related to the Signal Emitter. It also displays, for your convenience, the Signal Receiver that will receive the signals.


    The Retroactive property, when enabled, will trigger the signal if the timeline begins playing after the signal’s time.
    The Emit Once property, when enabled, will trigger the signal only once when the timeline loops.

    The Signal Receiver

    Let’s take a look at the Signal Receiver component. Click on the Gameobject that owns the Signal Receiver.


    It shows you nearly exactly what we saw previously; the Explosion signal is bound to an empty UnityEvent.


    Let’s say we want to add a new Signal Asset. We can do it right here. Click the Add Reaction button. A new reaction was added, bound to nothing. Click on the dropdown and choose Create Signal...


    Here is my result after I created a new asset:


    The Signal Receiver is now setup to invoke reactions when it receivers the Explosion and Load Scene signals.

    If I go back to the Timeline, then I can add a Signal Emitter that either sends the Explosion or the Load Scene signals. I can also easily switch between the two.





    So in a nutshell, how do I setup my first signal?

    You need a grand total of 4 clicks:
    1. Right-click on a track which supports signals, then choose Add Signal Emitter
    2. In the Inspector window, click on Create Signal Asset, choose a file name and hit Enter (one less click :p)
    3. Still in the Inspector, click the Create Reaction button.
    That’s it! In the Unity Event UI, you can setup what is necessary for the reaction associated with the signal you just created.

    Can I create my own markers/signals?

    Yes, you can. See this thread: https://forum.unity.com/threads/new-in-2019-marker-customization.594712/

    I’m finished! It was a long wait, but we hope it was worth it. Enjoy!
     
    Last edited: Dec 7, 2018
    rakkarage, syscrusher, 5argon and 7 others like this.
  2. u7ku

    u7ku

    Joined:
    Jul 17, 2018
    Posts:
    3
    Sweet!!! I was worried this was dropped from the roadmap.
     
  3. julienb

    julienb

    Unity Technologies

    Joined:
    Sep 9, 2016
    Posts:
    123
    You can also check this video that will give you an idea of what is possible with signals:
     
    Last edited: Jan 21, 2019
  4. AndrewKaninchen

    AndrewKaninchen

    Joined:
    Oct 30, 2016
    Posts:
    80
    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.
     
    Last edited: Dec 7, 2018
  5. Vectrex

    Vectrex

    Joined:
    Oct 31, 2009
    Posts:
    204
    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.
     
    ledbetterman likes this.
  6. AndrewKaninchen

    AndrewKaninchen

    Joined:
    Oct 30, 2016
    Posts:
    80
    The idea is not randomness, it's actually quite the opposite.

    upload_2018-12-7_13-6-45.png

    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.
     
  7. Vectrex

    Vectrex

    Joined:
    Oct 31, 2009
    Posts:
    204
    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.
    upload_2018-12-8_4-13-46.png
     
  8. JakubSmaga

    JakubSmaga

    Joined:
    Aug 5, 2015
    Posts:
    416
    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.
     
  9. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,343
    Thanks a lot for the pressie - I think we might have to start making moves toward timeline integration now.
     
  10. julienb

    julienb

    Unity Technologies

    Joined:
    Sep 9, 2016
    Posts:
    123
    ledbetterman and Lars-Steenhoff like this.
  11. AndrewKaninchen

    AndrewKaninchen

    Joined:
    Oct 30, 2016
    Posts:
    80
    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.
     
  12. andybak

    andybak

    Joined:
    Jan 14, 2017
    Posts:
    143
    At first glance it does seem a tiny bit over-engineered... A bit 'enterprisey'...
     
  13. Kiupe

    Kiupe

    Joined:
    Feb 1, 2013
    Posts:
    523
    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
     
    awesomedata likes this.
  14. starikcetin

    starikcetin

    Joined:
    Dec 7, 2017
    Posts:
    224
    Yay Adobe Flash!
     
    jorrit5477 likes this.
  15. andybak

    andybak

    Joined:
    Jan 14, 2017
    Posts:
    143
    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.
     
  16. julienb

    julienb

    Unity Technologies

    Joined:
    Sep 9, 2016
    Posts:
    123
    Thanks for the precise and thoughtful feedback, it is very appreciated. I know I took a while to respond; we talked a lot about your feedback internally.

    @AndrewKaninchen

    I understand what you mean. We seriously thought about having a built-in message system in Timeline, but decided against it. Let me backtrack a little bit.

    When starting the Timeline Events feature, we saw early on that there are two main ways to implement events: Messages and Signals. The first one has all the data on the caller side, like Animation events. On the other hand, Signals let the callee manage what to do. Both have very valid use cases and both also have different setups. We decided to take the direction of Signals for the following reasons:
    • Flexibility: The decoupling between the emitter and the receiver enables a lot of use cases.

    • Reusability: Multiple timelines can use the same set of signals.

    • Multi-user workflow: The signals system can let one user create a set of signals and receivers. Another user then has a list of predefined signals that can be used to build a timeline. Having the signal assets independent of the timeline asset helps tremendously when working with big teams.

    • Ease of use: We saw that having all the reactions in the same object (the receiver) makes it easier to debug. It is also easier to follow what’s happening in the timeline because there is a clear separation between who reacts and who triggers a reactions.
    We strongly believe that the Signal system is the best way to trigger events in Timeline; we think this is what users should strive for, once the initial hurdle of understanding the three piece workflow is gone.

    It’s a tough balancing act for sure and that system may not please everyone. Using the Playable’s Notification API, it is possible for users to implement their own version, tailored for their workflow and their game if the built-in version does not fit. We also plan to release a package with code examples for Timeline (like an updated version of the Default Playables from the Asset Store), which will contain new types of markers, so that you can take those and reuse them.

    Signals Assets are just an id; they are the link between an emitter and a receiver. In your example, yes, you would need a different signal for a each different explosion. In our design, the role of the Timeline is to say “a big explosion happened’’ and it is up to the scene objects to react to that and to activate the correct subsystems (particle, audio, etc.) with the correct parameters.

    You are right, it is an issue; the dropdown could fill the whole screen height and it is hard to search for the correct signal in that case. We’ll address that for sure.

    We want users to be able to reuse signals between different timelines and to be able to create signals even before the timeline itself exists. Having signal assets embedded in the Timeline itself removes the ability to do that.
     
    Last edited: Dec 20, 2018
    Yozaro, syscrusher and recursive like this.
  17. julienb

    julienb

    Unity Technologies

    Joined:
    Sep 9, 2016
    Posts:
    123
    Yes, SignalAsset can be extended. If you want to add properties that will be picked up by the receiver, you can do so. However, you will also need to write your own receiver. You can also extend SignalEmitter to add custom data if you want.

    No. You can have multiple receivers bound to the same SignalAsset. Also, let’s say you have a track that has a binding and signal emitter. If you put multiple receivers on the bound object, all the receivers will receive the signal.

    image2.png
    In my example here, both Signal Receivers will receive MySignal.
     
    Yozaro and Kiupe like this.
  18. andybak

    andybak

    Joined:
    Jan 14, 2017
    Posts:
    143
    > 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?
     
  19. julienb

    julienb

    Unity Technologies

    Joined:
    Sep 9, 2016
    Posts:
    123
    Let's say you have a signal Asset Explosion in your project and you a receiver in the scene that reacts on the Explosion signal. Any timeline can send the Explosion signal; you can reuse that signal in multiple timelines. If the receiver is correctly set up, it will receive the Explosion signal, regardless of which timeline sent it.

    Concretely, it lets users work on multiple timelines at the same time while still using the same set of signals.
     
    tarahugger likes this.
  20. AndrewKaninchen

    AndrewKaninchen

    Joined:
    Oct 30, 2016
    Posts:
    80
    @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.

    upload_2018-12-20_16-15-10.png

    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.
     
    Last edited: Dec 21, 2018
  21. Vectrex

    Vectrex

    Joined:
    Oct 31, 2009
    Posts:
    204
    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)
     
  22. andybak

    andybak

    Joined:
    Jan 14, 2017
    Posts:
    143
    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.
     
  23. Ludiq

    Ludiq

    Joined:
    Mar 6, 2015
    Posts:
    572
    Funny you'd bring up Bolt, I'd been following this thread very attentively for another project of mine. :p

    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.
     
    tbriley, Shizola, awesomedata and 3 others like this.
  24. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    2,070
    @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 )
     
    Last edited: Jan 4, 2019
  25. sebastienlh

    sebastienlh

    Unity Technologies

    Joined:
    Sep 22, 2017
    Posts:
    23
    If I may chime in, there seems to be some confusion about the signal assets.

    The assets are only identifiers, think of them like the tags or layers systems: arbitrary project-wide predefined names. We wanted to allow users to either predefine signal names or create them on the fly while editing. We also needed a way to allow for mass renaming signals. We went with assets to allow for a drag and drop workflow: drag a signal asset on your timeline and it will create an emitter.

    It is important to keep in mind that the asset is not the emitter; the emitter is owned by the track (it's a bit more complex than that, but it's a good way of thinking about it). The asset is the "name" that the emitter uses to bind to a UnityEvent that resides on the receiver (the track's binding or the director). This is a normal UnityEvent to which you can add different callbacks with or without payloads.

    Hopefully, that clarifies things up a little.

    We strongly encourage you to come up with your own solutions if after playing with signals for a while, you decide it's not what you need. However, I think it's worth trying the signals system as-is first.

    Please see this thread about markers customization to get you started: https://forum.unity.com/threads/new-in-2019-marker-customization.594712/
     
    starikcetin and Lars-Steenhoff like this.
  26. andybak

    andybak

    Joined:
    Jan 14, 2017
    Posts:
    143
    @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 :-( )
     
  27. sebastienlh

    sebastienlh

    Unity Technologies

    Joined:
    Sep 22, 2017
    Posts:
    23
    @andybak Having simple configuration assets has always been encouraged in Unity. I think there is a lot of added value to having “basically a string” that you can drag and drop, reference, pre-define, organize based on the needs of your project, etc.

    We have spent a lot of effort making sure Signal Assets don’t add any more cognitive overhead than Tags or Sorting Layers do. In fact, there should be even less overhead to using them since they are part of the Asset Database. The tooling is built around the idea that you can do everything from the Timeline and Inspector windows, without ever touching the created assets if you don't want to.

    This is a new way of solving an old problem: play around with it and see how it goes. Maybe you’ll find that you see the appeal, or maybe this will solidify your position. Whatever the case, we’d love to hear more about your experience.
     
    Lars-Steenhoff likes this.
  28. zIyaGtVm

    zIyaGtVm

    Joined:
    Dec 27, 2017
    Posts:
    81
    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.
     
    Lars-Steenhoff likes this.
  29. seant_unity

    seant_unity

    Unity Technologies

    Joined:
    Aug 25, 2015
    Posts:
    916
    We've taken a step towards that in 2019.1. Timeline is now a built-in package. We'll be working to decouple it further from the editor and become a full package in the future.
     
    zIyaGtVm and Lars-Steenhoff like this.
  30. Kichang-Kim

    Kichang-Kim

    Joined:
    Oct 19, 2010
    Posts:
    275
    Hi, Is signal guaranteed to be invoked with low FPS? Classic Timeline event are skipped somtimes when application's FPS is low.
     
  31. sebastienlh

    sebastienlh

    Unity Technologies

    Joined:
    Sep 22, 2017
    Posts:
    23
    @Kichang-Kim Yes, all Signals are guaranteed to be invoked, no matter what the framerate is. Furthermore, if you implement your own events solution using INotification, they are also guaranteed to be invoked regardless of the framerate.
     
    Last edited: Jan 21, 2019
    Kichang-Kim likes this.
  32. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    795
    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.
     
    Last edited: Jan 28, 2019
  33. JohnSmith1915

    JohnSmith1915

    Joined:
    Apr 21, 2016
    Posts:
    143
    Very confusing feature.
     
  34. Cleverlie

    Cleverlie

    Joined:
    Dec 23, 2013
    Posts:
    194
    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.
     
    Last edited: Jan 31, 2019
    awesomedata likes this.
  35. sebastienlh

    sebastienlh

    Unity Technologies

    Joined:
    Sep 22, 2017
    Posts:
    23
    @Cleverlie
    1 - The main reason to go with assets is to support drag and drop. Everything is drag and drop enabled in Timeline and we decided signals should also be. There are a few other reasons, like the fact that assets are dependencies so if you package your timeline, the signal assets will follow; or the fact that you can organize them however you want in the project.

    2 - We are aware of the full-screen list of signals problem. The solution we are currently looking at is to not use a drop-down at all, but an object field. It has the added benefit of allowing you to search, if you ever end up with a ton of signals.

    Thanks for the feedback!
     
    Yozaro, hopeful and Cleverlie like this.
  36. JakubSmaga

    JakubSmaga

    Joined:
    Aug 5, 2015
    Posts:
    416
    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
     
    awesomedata likes this.
  37. sebastienlh

    sebastienlh

    Unity Technologies

    Joined:
    Sep 22, 2017
    Posts:
    23
    @JakubSmaga There are no plans to do that at the moment. We may review parts of the design once 2019.1 officially releases and people start actually using the feature in production.

    A lot of the comments seem to focus on the amount of assets this will generate, but I am honestly very curious how many signals are required on any given project. I certainly can't imagine this number being in the hundreds, but I may be way off. What were your plans with signals that would require 100+ unique names?
     
  38. JakubSmaga

    JakubSmaga

    Joined:
    Aug 5, 2015
    Posts:
    416
    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 :confused: 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?
     
    Last edited: Feb 1, 2019
  39. sebastienlh

    sebastienlh

    Unity Technologies

    Joined:
    Sep 22, 2017
    Posts:
    23
    The references to the Signal assets are serialized with the tracks, so duplicating a Timeline asset will preserve those references. This will not generate new Signal assets.
     
    awesomedata and JakubSmaga like this.
  40. yangjianhui8

    yangjianhui8

    Joined:
    Nov 28, 2014
    Posts:
    19
    In the future . Can I play timeline use like "Go to "signalss name" " ? jump to time.
     
    Last edited: Feb 2, 2019
  41. sebastienlh

    sebastienlh

    Unity Technologies

    Joined:
    Sep 22, 2017
    Posts:
    23
    @yangjianhui8 This is not something that will work out of the box, but we are planning on releasing a package of useful extensions to Timeline. The kind of marker-based navigation you are describing is on our list for sure.

    We have no solid ETA for it yet, but it will hopefuy be during the 2019.2 cycle.
     
    Yozaro and awesomedata like this.
  42. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    795
    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?
     
    MegamaDev likes this.
  43. sebastienlh

    sebastienlh

    Unity Technologies

    Joined:
    Sep 22, 2017
    Posts:
    23
    @awesomedata We're thinking about it, but I don't think it should necessarily be a Signals feature. I believe it should be its own specialized feature that handles time controls, like repeat markers and conditional loops. Nothing's in stone at the present though.
     
    awesomedata likes this.
  44. yangjianhui8

    yangjianhui8

    Joined:
    Nov 28, 2014
    Posts:
    19
    thanks very much ! :>
     
  45. Cleverlie

    Cleverlie

    Joined:
    Dec 23, 2013
    Posts:
    194

    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.
     
    awesomedata likes this.
  46. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    795
    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.
     
  47. Kabie

    Kabie

    Joined:
    Dec 29, 2015
    Posts:
    2
    Is the invoke order of receivers deterministic?
     
  48. xCyborg

    xCyborg

    Joined:
    Oct 4, 2010
    Posts:
    509
    @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.
     
  49. julienb

    julienb

    Unity Technologies

    Joined:
    Sep 9, 2016
    Posts:
    123
    Yes. Internally, we use GetComponents to know which SignalReceivers need to be processed.
    Components returned by GetComponents are in the same order as what is displayed in the inspector.

    If you want to precisely control the invocation order, you can manually add a receiver to the playable graph's output.
     
    Last edited: Feb 26, 2019
  50. tbriley

    tbriley

    Joined:
    Sep 10, 2013
    Posts:
    110
    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 ;)