New in 2019.1 - Timeline Signals

This is where I'm at on (most -- but not all) Unity tools since Mecanim.

It seems like Unity's tool development process isn't much different than Nintendo's sometimes.

That is:

Develop in a vacuum, (with all external input being empty data points on someone's personal Excel spreadsheet), expect naysayers to eventually come around at some theoretical point in the future (our late 2000's track-record is spotless -- we noe what u want), put important features in a "maybe" category for potential release of version 2.0, (because we got no funds/budget/time available to deliver what you want -- what we wanted to deliver was always our first priority.)

This is fine for certain cases -- but not all tools can be approached in this "visionary" (read: aloof / artsy) way.
Great for investors (at first) -- but terrible for business (in the end.)
Why?
Timeline signals, for example, definitely have a "kinda cool" use-case as they are -- but the limited scope of their use (after waiting so long for them) turns out to be quite disappointing to some.

As users, some of us tend to feel a little betrayed a little too often by Unity thanks to this approach.

Like Nintendo, Unity seems to focus on chasing down "new" approaches and ideas, leading them to neglecting their simpler "bread-and-butter" empathy and technical knowhow that originally won their fans over to begin with.

 

This is what Clips are for. Markers are inherently "duration-less" (and in any software).

 

not true.

https://support.apple.com/kb/PH13186?locale=en_US

or

https://www.ableton.com/en/manual/arrangement-view/

see section 6.5, the arrangement loop ^^^

maybe just semantics to you, but when i am trying to take the tool seriously on a project i regularly bump into limitations where i can feel this sort of attitude in the software. it's also the general tone of this thread, users trying to communicate why something doesn't feel good and someone from unity essentially saying "you're holding it wrong".

and it's beside the point -> fine, let "signals" be duration-less. but when a user gives feedback my advice to you is to try to understand the full context of what they're attempting to communicate:

"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"

basic playback + arrangement controls (make it all duration-less if you feel that strongly about the design). signals with some embedded data. data types (and signal design) that play nice with DOTS / ECS. a way to make new clip types that doesn't still basically require a wizard to generate the code for you (or better yet, just include a stronger set of built-in clip types). i want the tool to feel like it's gone beyond its initial release / demo state and is in-line with unity's future. and to be clear, i'm not expecting something as fully-fledged as a standalone sequencer like ableton or logic. i also truly, truly understand that like any business unity has limited resources and everything you do is tradeoffs and every user has different expectations and you're never going to please everyone. more "wow"

 

Exactly. Well-put.

This is the reason why even users who _really_ want to support Unity, can't find themselves saying nice things about many of their tools -- The attitude users receive upon pointing out "problems" with major features (like where are true, flexible, Timeline Events?) is very clear:

"If it ain't working for anyone but me and my team -- that means it's not broken."

:'(

 

Is there any chance Signals are going to be backported to 2018.3 or would somehow work as an external package? We've started development on a project locked to 2018.3, but we would love to use Signals.

 

Hi,

I was wondering why a receiver should be in the Timeline ? I mean, I understand why it has to be in the Timeline regarding how it works. But if the signal asset would have handle/contain the event (unity event) it could have be different. The signal assets could expose a Unity events, signal receiver could subscribe to that event and an emitter could tell a signal asset that it has to fire its event. That way it would have been possible to notify an arbitrary of receiver in the scene without having to explicitly add them to a timeline track.

Does that make sense ?

 

Hello, really excited about Signals and Markers. Is it possible to make markers emit notifications in edit mode? Preferably while scrubbing the timeline?

I'm thinking I'd need to create a custom track and put the logic in there somehow... any help appreciated!

 

You know -- after @cirocontinisio's latest (too quick) run-through of the Timeline Signals & Markers, I am finally intrigued about the system you guys built. He said _just_ enough to make me wonder about it, but still not quite enough to actually show us _how_ you wanted us to use them.
I feel like you guys really should put out a detailed video or two showing what kinds of things you guys suggest we do with the markers/signals systems. They definitely seem novel, but they subvert people's expectations a little _too_ much for us to know exactly what kinds of projects or workflows they were intended for.

We expected a straightforward "Events" system, kinda like the Animation Events -- but on Timeline. We got something way different (but perhaps, a bit more robust -- we don't know -- we just need some better insights on what this system brings that Animation Events on a Timeline couldn't.)


I hope you guys consider shedding some light on this stuff so that those of us who couldn't follow your reasoning can finally be on-board with you guys. You've got a cool-looking setup, and you've obviously put in a lot of work, but I'm sure I'm not alone in feeling like I'm still not quite there with you...

 

Or an illustrated blog post. Please no more videos - I can skim an article 10x faster than I can listen to someone drone on through a damn video.

(Sorry - had to get that off my chest. Totally baffled by the reliance on videos for stuff that would be much more accessible and informative in other formats)

Anyway - @awesomedata makes a very eloquent and valid point. Lots of people here just haven't clicked with the new way of doing things, I'm personally still baffled what the advantage in making a single text string into an external asset file are despite a couple of attempts to explain it.

The complexity/flexibility trade-off just seems out of whack here but that's probably a lack of insight on my part so please illuminate us.

 

I agree about the ad-hoc / scatterbrained nature of some of these videos.

Honestly, having a random person try to hit on a small set of talking points might be easier on the production side, but it can be a pain for users to later have to scrub through to reference any "feature-relevant" information we need about otherwise undocumented features. The blog posts are hit-or-miss on quality too. Yes, a well-documented and illustrated post, _can_ be better than a video for reference, but the (often heavily-outdated) information never disappears. So as a source of learning _and_ reference, it's better to have both. New information is often more accessible and easier to produce in an ad-hoc video format for quick turnaround, but information not mentioned in one format may be mentioned or clarified in the other. Videos for quick learning and spreading of info, and (frequently-updated) blog posts for reference.


Whether through video _or_ illustrated text, there somehow still tends to be loads of very important (and very relevant) information "missing in translation" to end-users -- case in point: the current direction of this topic.

That's really true -- We want to have faith in you guys, but with little information or insight on where you're coming from (or what you intended for us to do), plus the fact that we've been burned many times in the past (and have waited years to be heard!) -- it's really hard to just go on faith alone that you guys have really thought this through from our perspective. I see that there is a deeper idea now behind this new system (thanks to @cirocontinisio's talk), so I've personally regained some confidence, but I've yet to really gain the insight that you guys are expecting me to have on how you intended it to be used. By simply telling me "it's powerful", it doesn't really help me see _why_ subverting my expectations was better.

 

I actually agree that (literally/semantically) markers should have no duration. What you want in Ableton's "loop marker" sense is 2 markers that are constrained to each other. Maybe this is a more useful and concrete proposal for UT to consider :

- The left and right marker triggers different kind of notification, already in definition of a marker. In Ableton's loop marker sense the left marker do nothing but the right one sends back the playable graph time to the time of left marker. The left one may send a notification to begin record mode for the punch in feature.
- The first one's `time` must be equal to or lower than the second. You want this supported first class by having the Timeline GUI constrain this. So it is not possible to drag the right one past the left and have a "flipped" pair of markers, ruining the fixed function of left and right markers. Or if the flip is possible, left and right markers must automatically switch places.
- If the left and right marker is at the exact same time, you want the GUI to show this reasonably. It is still possible to grab either marker to pull them apart, currently not possible as overlapping markers are displayed with + sign.

I would name it "linked marker" of sorts, and it would be certainly useful if Unity made it. (

class LinkedMarker<L,R> where L : Marker, R : Marker

?)

I have one more related request too.

It would be useful if a clip playable asset could also be INotification that notifies on entering the left side and again on exiting the right side. (Set INotification as the clip itself that implements INotification just like when marker is a notification, but maybe make use of currently null `context` variable to tell if it was from the left or right side)

Use case for this is like the "dialogue clip" from this article https://blogs.unity3d.com/2018/04/05/creative-scripting-for-timeline/. Here (https://github.com/UnityTechnologie...mTimelineTracks/Dialogue/DialogueBehaviour.cs) when notification API wasn't available it simply embed the stop logic in the clip's processing.

Now that the notification API is available I would like to realize this logic using a notification and only with clip, so the notification fires properly on entering the left side and I could implement a stop there. I could certainly implement this with overlapping markers positioned at the left edge of the clip, but it would be ugly and make editing them in the Timeline GUI less ideal. Not to mention I have to carefully copy the marker-and-clip together everywhere.

It is also possible for me to make my clip's playable behaviour to do things like TimeNotificationBehaviour and just call PushNotification on the playable's output in addition to my own dialogue logic, but I think that's not ideal either.

Receivers are not in the timeline asset.

• Timeline has tracks.
• Any track could contain markers. MarkerTrack could only contain markers and not clips.
• When play head goes over a marker, it check the track's binding (any kind of track, marker or not). If that binding is a component, it finds that component's owning game object. If that track is a special "Marker" top track, the binding is assumed to be PlayableDirector component running the timeline asset's created playable graph, then it continue to find that director's owning game object.
• That found game object will finally broadcast a notification to all of its component that's with INotificationReceiver. If a SignalReceiver (is an INotificationReceiver) is on this game object, it will be notified. The SignalReceiver is not in the timeline asset but a MonoBehaviour on a game object, that should be sitting near PlayableDirector if you wish to use the top Marker track or near your binded component if the signal markers are coming from other tracks.

SignalAsset could not expose UnityEvent as it is an asset being, stored in asset folder without knowledge of scenes. UnityEvent needs to connect to something in the scene to invoke, so it needs to be on some kind of MonoBehaviour's exposed field. SignalReceiver fits this requirement, so SignalAsset's task is just for the SignalReceiver to check which specific signal in the timeline was sent as a notification. (TimelineAsset too is an asset being and has no knowledge of the scene at design time until PlayableDirector create a graph out of it. The timeline uses SignalAsset as a bridge so SignalReceiver could do something with the scene)

 

@5argon thanks for the answer, but I'm still wondering/thinking that they could have an approach more similar to Ryan Ripple

.

 

This is a really odd thing to me, like, i under stand more fundamental deeper features like the bone per vertext thing (desperately needed) or something like raytracing. But whats the point of stuff like package manager where things that could be highly beneficial like this are left only to newer unstable versions. And I have to wait a whole year just to gain a stable version cause i just wanted a few features and risk my whole project breaking as a result. I have to debate if i want to deal with a whole new thing in a new unity version just cause 4 bones per vertext (as i said understandable but still) is unberable or I want to be able to more effectively use the timeline (main issue).

Like is Unity built to grow with peoples projects, or is it built for the perpetual new projects that pop up or just for people to tinker with? I don't need SRP and all that other fancy technology stuff, but basic functionality for major features like timeline would make me feel a lot more confident in it. Cause otherwise it seems more like an inconvenience to use these unity features rather than buy an asset that is backwards compatible or have to program something myself. Maybe i'll just use it next game in 2-3 years.

But above all, why is 2018.3 mentioned in the GDC video if this is not the case?

 

The signal feature which is a part of Timeline (package) is depending on Timeline's Marker feature, which in turn depends on notification feature in UnityEngine.Playables added in 2019.1. Playables is not yet a package, it is implemented natively. I guess that's the reason why signals couldn't go back in version as a package.

 

Do you think it would be possible in the future out of the box, or easily implemented by myself that there is also a SignalEmitter as a Component?
I sometimes would need a Signal to be fired in the timeline or if some User Input happens before that through a game component.

Thanks,
Matthias

 

I ran into an issue with Signals: seems that they don't get called if you manually modify the time of the playable director and call Evaluate:

Code (CSharp):

1.            
2. Director.time +=Time.deltaTime;
3. Director.Evaluate();        
4.  

This won't call the signals.
Is there any method to call on the top to call the signals, or is that a bug?

 

Hi,
is it possible to use Signals to start playing UI element animation?
I have tried a couple of ways but no luck.

Thanks

 

Sorry for the long delayed answer.
Fair enough, I didn't know other software had the concept of markers with a duration. To me it sounds new, that's what I think clips are for (they offer a lot of control and events, on start, an update loop, on end, etc.). I personally don't see a big use in replicating the same functionality in Unity's Markers to get something very similar to the Clips, and then having people confused on when to use one or the other. But I'm not in the Timeline team so this is just a very personal opinion.

For the rest, you have some very good suggestions and criticism in your last paragraph. I'll ping the Timeline team to keep it in mind, if they haven't seen it already.

That video is mine. The slide refers to the fact other smaller improvements are also present in 18.3, but I do say in the video that Markers and Signals are available as of 19.1.

More than having a Component that fires a Signal notification pretending it's a marker, I'd do it a different way: have 1) a Component (or another bit of code) and 2) the SignalEmitter (on the Timeline) that can call the same function, which is in a third location. That way you centralise the functionality somewhere else.

Sorry it was quick, that was a 20 minutes talk at GDC and I had to cram a lot of stuff in it. I'm glad it was useful though!

We hear your feedback on the videos. In case you missed it, Julien posted a blog post: https://blogs.unity3d.com/2019/05/21/how-to-use-timeline-signals/ with more details.

 

The reason why your 20 minute talk was so much better than the blog post (imo) was because you gave a holistic overview of the reasoning and possible use-cases behind the signals workflow -- and how they were intended to be applied in workflows.

For this, you did a great job!

This tiny part about workflow is all too easily missed by Unity as a whole everytime a new feature or tool is released. It took YEARS for Mecanim users to finally have enough trial-and-error behind them to finally suss it (and its blackbox API) out (and it's still not entirely understood what's going on behind the scenes). Mecanim's wildly-specific workflow for animation was proposed, but there were huge problems with it in practice once users began to finally understand it -- but, by that time, Unity's development efforts had long-since shifted elsewhere because Unity assumed people loved it due to their silence. However, I assure you that this silence was mostly because many people couldn't make heads-or-tails of what they would have to do in order to fit this into their workflows -- and this was Unity's answer to animation at the time (and currently, the only solution, for the moment) -- including for stuff like procedural animation and facial animation for most people. Nothing broader than state-change was considered in its design, not even logic -- nor was the poor usability of having to manually create trigger variables in the editor window (without lots of backend code) to do the inevitable logic alongside overly-complicated scripts.
Things have gotten better since with Mecanim, but the fundamental workflow is still very flawed in practice.
It seems like someone comes up willy-nilly with the suggested workflow, then everyone just nods, so it gets greenlit, then it fails to ever get mentioned to users what the originally-intended workflow was, since it has probably mutated greatly by the end of a feature's development and release.

I wonder if this is what happened to Timeline's signals/markers workflow?


It really seems like Unity in general expects everyone to think: "Wow! That's really cool! -- Let's use it!"

While the (real) reaction is typically: "Wow! That's really cool! -- How many days (or weeks!) is it realistically going to take me to get my head around their specific workflow and apply this (again, very specific) workflow to my own workflows? -- I need a better workflow, but is this new concept/workflow really that much better? They didn't tell me how it could apply to other workflows. How can I know it's even worth the time for me to learn? -- I've got so many other tools/skills I need to learn, and documentation is sparse. I'll probably just learn it later."


There is usually no more than one suggested workflow, and no "here are ways how you could generally use this (as-is) to do various things like..." types of examples (usually step-by-step is good -- but from multiple usage scenarios/perspectives). That arrow-key input video in the blog about Timeline signals really didn't help much in this. It was oddly-specific, really fast, and didn't tell me anything about how I might use signals for something else -- something more complex.


TL;DR:

Your holistic overview and general suggestions were a lot more useful, @cirocontinisio -- I could learn the steps to do the integration later.
For now, I mainly need to be shown the possibilities -- particularly how the system could be used.
Being shown different usage scenarios is the only real way I can evaluate whether or not learning the new system would better-serve my workflow.
This is what can spark people's imagination to use it in their own projects/workflows -- and get you better (more timely) feedback.

 

Wow. I think you lot should hire @awesomedata

;-)

 

I'm curious about this also - If I set the PlayableDirector timeUpdateMode to DirectorUpdateMode.Manual and call Evaluate() myself, my signals don't seem to trigger.

 

This is problematic because it means it is impossible to use signals when manually playing the timeline: could we have some API access in order to evaluate the signals, or anything close to that?

When you say that the timeline must be playing, the problem is that if I move the time manually, it is in fact "playing" so that seems like an inconsistent behaviour to me, especially because PlayableDirector has the "manual" update mode exposed.

 

I see that makes sense.
It would be great to have a way to perform this independently of tracks.
A method like EvaluateFromTo(float startTime, float endTime) would be awesome for instance
I will take a look at the track method you mentioned, thanks!

 

@sebastienlh Hi, I found that playing timeline in timeline editor does not triggers custom marker, but signals are triggerred. Is this intended behaviour? Playing scene correctly triggers both marker and signals. I used Unity 2019.2.0f1.

Edit: Implementing INotificationOptionProvider makes my custom marker is triggerred in editor mode.

 

Great feature is Timeline and Signals give greater potential however with respect there's more legwork to make them useable at great length.

I am desiging a Unity system to help me streamline my film makng system. I basically have a setup where I can drag mutiple characters (Actors) into a scene. Each Actor has a script attached that controls the following:
1. Head LookAt Object
2. LipSync to a GameObject Audio Source (via volume levels to blendshapes, quite primitive but good enough)
3. Trigger various animations on character to emulate emotions. (Combination of Blenshapes and Animations)

I'm working on using timeline to control these parameters on each character in scene.
Everything works from one Audio Track which is a vocal conversation track. Overtalking is not a big issue for me.

Using signals I assign on each character track I can effectively call scripts functions to activate/deactivate lipsync, change Lookat Object and change current animation on a specific Actor (character). Great!

Problem is managing the signals in an efficient and identifyable way as they soon grow. The biggest cause of this is having to create NEW Signals and RECEIVERS for each such event. Imagine 3 or more characters (actors) in scene chatting and doing their bit. I have many signals at timed events making them respond to the audio lipsync, lookat and animations. Its soon becomes tiresome to see which signal does what even with good naming convention.

Not sure if this asset will help but I'm going to look at it - https://assetstore.unity.com/packages/3d/characters/timeline-events-115300

The Signals would be better if there was something easier to follow on timeline and reusable in some way. i.e. One Signal that I could copy and paste and set some custom events on per what I need to control on a that character at a given time. Some form of customisable Signal otherwise they are quite restrictive in heavy useage.

Just a thought!
Cheers

 

I understand why you'd want a system with separate signals and emitters, but to blow off the simplicity of a system like animation events and to claim that's not the right way to do it is really frustrating. There's a lot of power in a system being simple and intuitive and for me the intuitive nature of systems is what I loved about Unity back in the 3.x and 4.x days.

I also don't see a reason why you can't support the legacy animation event workflow within signals. Let signals be defined as simple POD types (no behaviour) that can define serializable properties that are exposed and saved in the timeline. Then let signals on clips emit and bubble-up to receivers above them in the timeline hierarchy. Then you can just have a root level receiver to route all unhandled signals of type x to method y and you handle the most common case of animation event systems of a many-to-one relationship without a convoluted, confusing and really slow workflow.

 

Seconded.

 

I built these videos using a system I have been developing in Unity .. it allows me a piecemeal of flexibility wotking from one single vocal track (the 1st step) to which I then timeline my characters to respond via events and call from a number of public functions Ihave coded. Basically it ends up a realtime animation system to which I then render/record to MP4 1080HD. The only minor issue is that it disables audio while rendering (for efficiency I guess) so its not so great if I want to do some realtime control like cam move or control a particular character. But all in all Unity has now become my film making system rather than using iClone which I hated.

It's a constant work in progress system (more a suite of tools) I've been developing for the past year. Plenty of new ideas that I'll add as time goes along.

 

I realize I'm late to the party, but I'm finally on a project where I can use Timeline and signals. I'm disappointed that this is the best that Unity could have done with this system. I'm working on a system using signals that need to allow for branching timelines based on dialog choices and I thought I could handle that with signals when the end of the timeline needs to move to another branch. If I define these branches in an array for a given cutscene monobheaviour, there's not a good way to use specific branch logic without creating signal for every index possible in the game. (Branch0, Branch1, etc.) When honestly this could have been resolved with a single emitter that has an index argument BranchX.

The whole concept of a reusable "signal" object doesn't make any sense to me. I'm not sure I buy the argument that decoupling the receiver from the signal was a good idea, since you need to define the target object receiver, and on the receiver bind that signal to a method call (direct coupling). What's the abstraction benefit here exactly? So that you can reuse an emitter type in multiple timelines? Great, but you still need to do the leg work of binding those signals to specific receivers thus creating coupling. The idea of reusing timelines and dynamically rebinding the output of tracks is a use case that is much more infrequent that you think it is. Should dynamic rebinding of signal targets be supported? Absolutely, but do it through code (which you need to rebind the track to a new object anyways)! Should it make the primary use case of the signaling system more convoluted/less flexible as a result? I would definitely say no.

 

This is kind of why I still feel this whole project was half-hearted in its final execution. I think branching Timelines is a very good use-case for Timelines even in their current state. Their design, however, makes this use-case very difficult as you have already mentioned.

I can imagine making a general Timeline that "branches" by "becoming" a specific Timeline (depending on a choice), but in this use-case, Timelines would need to be treated as a sort of an extendable-prefab system for this to be a nice experience for the user.

All in all -- Unity is not thinking generically enough for its larger systems, but at the same time, it is thinking too generically for smaller parts of those same larger systems (like the Timeline Signals system versus Timeline itself).

Pigeonhole features like Timeline Signals really restrains the possibilities of the Unity Editor.

 

After the first time I watched this talk about game architecture with Scriptable Objects, I immediately implemented the idea for event assets that pass calls to listener scripts and, by extension, their UnityEvents. I found that being able to simply drag an event asset into any UnityEvent and call its invoke method, treating it like any other reference, was quite intuitive, convenient, and flexible. Anywhere a UnityEvent exists, I have the option to invoke any number of signal-like, asset-based events. But, I can just as easily use any UnityEvent without referencing an asset. Or, I can do both, referencing GameObjects and event assets in the same UnityEvent. If Timeline events and signals were separate, this would be possible. But, seeing as they're not, I want a separate, basic event.

This is because basic events are still necessary to account for multiple instances of Timeline-animated prefabs or other procedural content. For example, I've used Timeline to animate enemies, of which there can be an arbitrary number. Indeed, most of the applications I consider for Timeline are for objects likely to be instantiated an unknown number of times. Props and enemies often require small animations and general time-based sequences.

Maybe a custom marker with a basic event wouldn't be too hard to make. But, it's fundamental enough that it absolutely should be part of the base package.

 

Someone from Unity did promise some extra kinds of Timeline Event-ish stuff was on the roadmap way back in the old Timeline Events thread (probably because a lot of people were raging then because the events Unity demonstrated before the Jobs system was introduced wasn't at all what was delivered, yet basic events were what everyone was expecting).

However, they never delivered. -- And, as usual, we're still waiting.

 

Just digging into Signals now, and wow, you guys have made some real head scratching design decisions.

If the goal was to not impart additional cognitive load, or to easily support typical use cases, well you have totally failed at that. I think the total lack of adoption by the community, and nearly unanimous feedback here have settled this debate, I hope you will take this on board.

What are some typical use cases?

* I have 50 FX setup, pooled, each with their own enum, and a function called `ShowFx(FxType)`, I want to show many Fx during a timeline. I have many timelines, they all show different Fx.

* I have some function SetIntensity(float). I want to call SetIntensity many times for an animation.

* Have an UpdateText(String) fxn, that takes some Text, I call it many times in a cut scene.

How do I even do that with Signals? Since it's not possible have different handlers for the same Signal type, If I want to change SetIntensity 10 times in one timeline, I have to create 10 assets!? If I set text 10 times, I need SetText1-10? You can't really be serious...

If I have 50 FX, defined by enum, I now need to make 50 assets to match the enum names? And maintain those as FX change? Or do I just throw my timeline readability our the window, and make completely useless and generic Signals, like Fx1, Fx2, Fx3, and assign different handlers in every animation?

The entire idea of "reusing" event id's or names is fairly non-sensical, this is the least important part of data, and no one actually cares what the name is. The project wide nature of it renders them so generic as to be useless, or so specific that everything becomes cluttered.

98% of the time, this is the only use-case we need:
* I want to call a Fxn, as many times as needed, with as many params as needed.

This plugin shows the exact require featureset, that should be first-class:

https://assetstore.unity.com/packages/tools/integration/timeline-ez-events-126484

* Robust Callback Implementation
* Filter on Static, Accessor, Private, Inherited and Virtual Fxns
* Conditional Fxn, check, with branching Fxn calls
* Support multiple params
* Named Events as spans in Timeline so the Timeline Events are actually readable along with the rest of the content
* Toggle evaluation in edit mode
* Toggle enabled/disabled
* Toggle OnEnter, or OnFrame callback

^ This is what an implementation is written like when it's designed for productivity. It is not opinionated, it is not esoteric, it doesn't need 6 paragraphs of rationale to explain it. It is simple, robust, flexible and built with scale in mind.

Please adopt something like this natively, it can't be too hard, the design is done, it's all right there, you would be showered with praise and love and we can just pretend that whole Signals thing never happened

 

The worst part is their insistence that somehow the "Teams" decisions should outweigh the needs and asks of their paying customers who are trying to ship product.

Like we get it, you love your architecture that you sat around and crafted. But we don't. And we're the ones trying to ship product here. So with all due respect, please get out of your own heads, and respect the paying customers opinions a bit more.

I've seen a lot of talk in this thread by Unity engineers, saying that we don't understand the system, but actually, it's the Unity Engineers that are totally failing to understand the desired use cases, to admit their chosen solution has massive holes, or to explain even how those totally typical use cases can be enabled.

Like if you were going to switch to a major re-design like this, and actually cared about your users, you'd think the VERY FIRST thing you do, is rock-solid implementation of a generic event handler, as to not interrupt (or maybe even improve) the workflows of your developers, who you supposedly care about.

Then build whatever frameworky thing you want on top of that, and see if people like it or not. But forcing it on us like this? It's almost aggressively dismissive of existing workflows and typical use cases. You must know deep down this is not actually what most of us want or need...

 

I honestly thought that at this point they would have already done something to make Signals less terrible. I've had a few times when I used Timeline since this was introduced, and every time I fell into the idea of using Signals, I've almost instantly regretted it. Just by opening it now to see if anything at all has changed, everything I said a year and a half ago comes back to me.

In fact, having had a little more experience with it, I find it even worse now. As an example: you can't really emit multiple signals with the same marker. You will have to either create 2 markers at the exact same spot in the timeline, or create a third signal which logically means the composition of both others (which means, even in a rare case where you could actually make use of the fact that the Receiver's reaction being separate means it could be reused, you'll now have to duplicate both reactions into the third).

Signals are bad, man. It makes me sad. They could very well not be.

 

Timeline follows the path of many Unity features - once it's shipped that's the end of the line.

I was really excited when it first released as I could see the potential but the development of it seemed to dry up within a couple of months.

They delivered a really nice starting point but then someone said "Hey! Drop everything! We're doing DOTS now!" and that was the end of it.

 

I highly encourage people frustrated by signals to use customized markers instead!

https://forum.unity.com/threads/new-in-2019-1-marker-customization.594712/

They are not as well integrated (require a bit of code) but they give you a lot more flexibility. The marker customization should have been the feature they better integrated as the editor solution. Signals are such a niche/limited use case, you will hit a wall with them almost immediately. Don’t waste your time with signals.

 

Yeah, that tends to be how I see it as well. Which sucks, because as I said almost a year and a half ago, it kills standardization.

Every time I think about Signals I start thinking if I can write myself something to be used in it's place and share it, if Unity won't do it. It won't solve the lack of stardardization, but at least it could make the lives of anyone who bumps into it a little better, not having to deal with extending Timeline (which is kind of a nightmare for anything above trivial). I honestly have the time right now, if not enough motivation.

 

You should see DOTS Visual Scripting Drop 8 -- It's become less "DOTS", and more "Blueprints", which is exactly why people have been complaining about it. I (and many other users) fought with the engineers ten ways to Sunday to get them to see the light, but they've failed to take a hint.

I think somebody might point these two threads out to @willgoldstone so maybe Unity can get some ears behind it.


I'd hate for people to switch to another engine just because some engineers won't listen. :/

 

So, I've actually gone through the code for Signals since saying this and it's actually ridiculously easy to do the signal asset embedding inside the timeline asset. It doesn't break anything. I might actually do it in a nicer way tomorrow, and if I do, I'll put it on my Github and share here. I have some ideas for different levels of effort I could put to enhance the UX as well, so it might get better as I feel like working more on it.

 

Just to add another bit of feedback on this: I have a use case for Signals, but the way it's been implemented makes the workflow fairly cumbersome compared to how I imaged they would work, so they're not very nice to work with for me. I have a small behavior script that manages lines of dialogue spoken by some NPCs in a scene. I want to be able to trigger lines from the timeline to line up with other animations happening in the scene. I can't play an AudioClip from the timeline as I have code and other events triggering dialogue and the characters may already be speaking when the timeline starts so I want my dialogue controller to be able to handle the interruption. Signals would be the best built-in option for me to achieve this out of the box, but the way Signals work I would have to create a signal asset that corresponds to every line I want to trigger, place the signal on the timeline, wire it up to the NPC, then add a reaction for the specific line I want to trigger. There's no benefit for me in creating the signals as assets since the lines I'm triggering are all unique and will never be shared between timelines, so the extra assets will just be extra work and a layer of indirection that won't pay off for me later in reuse or ease of renaming.

I've read the other comments in this thread from people having the same problem and I feel basically the same. The ideal workflow for me would be to have each signal marker work like the equivalent of an individual UnityEvent binding. I have what I'd consider a straightforward use case for Timeline - sequencing a series of scripted NPC actions and dialogue - so I hope my example shows there's reasonable situations where there's some friction using the current system.

 

It seems pretty clear that the team intended these to be the equivalent of Tags, or Sorting Layers, or that sorta thing, where you would create a bunch of generic "types", and then share those across all your timelines.

It's not horrible if you come at it from that approach, it's just an odd, slightly pointless way to do it. Not sure why they couldn't solve the basic use-case first, which is directly calling an event, and then if they wanna add these project wide 'types' then go for it....

The team should realize that this approach is less readable than just exposing an event, and letting us name it. Then see those names in the timline:
```
[Bob Says Hi] ---- [Susan Replies Rudely] ---- [Bob Yells] ---- [A bomb explodes]
```
Vs
```
[Talk1] ---- [Talk2] ---- [Talk 3] ---- [SceneEvent1]
```

So,
1. Harder to use
2. Less readable
3. Not scalable

Where is the win again? We save the typing of generic names?? Thats really it. And the ability to easily trigger the same event with the same params multiple times in one sequence... which is pretty rare anyways.

 

Has much changed from this? I am finding myself having to make loads of different signals for small things, or making them call a function which advances itself based on how many times it has been called rather than being able to change the parameters on instances of Signal assets on my timeline.

 

Not officially yet, no. Signals look to be about the same today as they were when released.

EDIT: as for my solution, I've been distracted and unmotivated recently, so that's why I didn't share it yet. Turns out it's quite a bit more trouble to make it work as an addition to the Timeline package instead of an alteration of it.

I would have to duplicate a lot of code to not force change on anything from it to allow public access for what I need, and I honestly don't feel it is rewarding to do so when the solution is so simple by changing the package. I'm having the same trouble with another thing also related with timeline, actually. It's quite frustrating.

 

Maybe we should start forking neglected parts of Unity. Even if it's just "a fork with some things made public" it would send a clear message that there are gaps that need some TLC.

 

If I was working on projects in a company, I'd definitely do something like that, even if only internally. Specially with Timeline, which is something I've grown very used to hacking around. I'm this close at actually doing it just for myself and for proving some points about how much better the UX of the whole thing could be.