New in 2019.1 - Timeline Signals

I almost wish the playable director could hold bindings for Signal assets in the way it does for the tracks in the Timeline, almost like an array of signals that are associated with different references. Really annoying to think it could work like that.

 

Well I for one would love to see the results. So go ahead.

 

I'm actually very close to finishing the first iteration of the way I mentioned I'd like signals to be all that time ago, using basically just extension to the package. The only modifications, currently, are some public and virtual modifiers added some classes and methods in the package itself.

A preview:




The selection already works for both cases: signals embedded in the timeline as child assets automatically populate the dropdown for the Embed option, and Global can see all assets (I prefer it with the regular ObjectField to a dropdown list which excludes embedded ones because this way you get search functionality, which is very nice to have).

What I still need to do is:

- work out the creation of new Signals (the ones I embedded in my test timeline were done in a different version in which I modified the package, haven't done that yet in this one);
- work out the Convert button logic;
- figure out what to do if the user changes from Embed to Global and vice-versa, instead of clicking convert. I'm thinking of having two different references saved so it can be possible;
- figure out how to rename embedded signals in a not stupid way, because apparently you can't rename child assets within the Project View. Which is kind of stupid. I'll try to find out if I can forcefully re-add the functionality somehow, and if not, at least put it as a button next to the dropdown of the Embed option (Global doesn't need it, but would be bad for UX to not have it as well, so I might do it some other way).

 

nice workflow, similar to xsi's
now when scrubbing, how do event get called, let's say you scrub so fast that you skip the one frame that's got the event...

 

Looks really good -- I wonder how far you got on this?

 

I managed to solve some of the listed issues, but I ended up wanting to implement the lists of signals using Searcher.

First I thought of implementing Global signals using the regular Unity.Object picker, but doing so this way would include all local signals as well, so it wouldn't be very good (you can't really arbitrarily filter this search, apparently) .
Local signals I was okay with doing in a simple dropdown, like the original, because ideally they wouldn't be very big, but since I was planning on using Searcher for the global one, I'd prefer to use it for local signals as well (it is way better than dropdowns anyway).

So I tried it, and found some small problems, which led me to wait for a response from @willgoldstone, which never came. I was busy with some other stuff so I ended up just leaving it behind in hopes of Searcher being updated eventually, and as soon as I heard of it I'd come back and finish this.

I think it was that. I do have time now, so I might pick it up and finish it ignoring the limitations of the current Searcher, still just waiting for it to allow me to do it the way I want. Or if I feel crazy enough I could once again try to learn how to do it in a hacky way, which might be tricky (don't actually remember how much of an effort I made the first time).

 

Yeah -- this is what sucks for SO MANY tool design ideas I've had, and I don't know if it will ever actually be addressed. D:
This was 4.2 era I think when I asked for global/local search to be improved, and in every workflow improvement thread I have come across since.

As much as I would normally want to say "GO FOR IT!!!" -- I also know a tool like that would last two Unity builds before it got broken somehow, and the discouragement that brings builds up over time. D:

This seems like a better long-term approach that might benefit you most in the longrun. The searcher might be a cool thing, but I wouldn't wait for it. I think Unity is having a hard time making choices on the technology it wants to focus on, so nothing is actually getting the attention it really needs these days.

That being said -- one thing I've learned over the years is that purposefully limiting your own designs to fit within the limits of the constraints of what you've got to work with tends to lead to some nice innovations. Sadly, that doesn't help if what you've got is fundamentally broken though and through (and/or poorly designed and broken at the very foundations), but if you can step up just one level from a (functional) foundation, that is usually just enough to get you (not where, but at least somewhere) you want to be. And I tend to find that "somewhere" is an okay enough place to be in the end.

But that's just me -- your mileage may vary.

 

Hi,The TimelineSignal scripts conflicts with RenderPipelines' under URP 2019.3

"...\Tools\Signal\Editor\MessageInspector.cs(64,32): warning CS0437: The type 'Utilities' in '...\Tools\Signal\Editor\Utilities.cs' conflicts with the imported namespace 'Utilities' in 'Unity.RenderPipelines.Core.Runtime, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in '...\Tools\Signal\Editor\Utilities.cs'.

 

So finally got around to look at signals and after a bunch of reading I'm still confused about why the need to bind a signal receiver to a signal track / emitter. To me it defeats the purpose of having an event system where the event emitter doesn't have to know about who is receiving the event...

It seems that I need to make a bunch of signal tracks emitting the same signals to be able to have multiple objects receive the signals. Incredibly cumbersome to the point of uselessness. Or be forced to have a god object that receives the signals and then dispatches reactions to a ton of other objects, which is just a horrible practice. Or am I doing something wrong?

 

It is badly designed, really. Its impossible to use it right (unless you consider it right to be subjected to a gigantic list of Signal Assets in your dropddown)

I haven't messed with it for a while, but as far as I remember it, you should be able to trigger multiple Receivers through the same signal. They should show up as multiple entries in the view with allows you to setup said responses (in the inspector for um your SignalEmitter clip, I believe). Something like that.

 

If there is a better way to work with it, I would like to see it.
Maybe @Unity school us neanderthals.

As-is, this is pretty painful in general in a real project.

 

Right now it's just wrong: it clutters the assets + the workflow requires extra steps to create, name and store the signals.
The signal assets should be listed under the Timeline asset in the Project Window.
Or maybe integrate the data directly into the Timeline asset with no separate physical asset.
That's just bad engineering, period.

 

did this ever make it in? I would like to play and pause based on signals. I can pause no problem, but I'd like to START a timeline at specific signals instead of using .time

 

figured it out: https://forum.unity.com/threads/jumping-to-specific-points-on-timeline.999514/

 

Anything in the cards for this sort of thing yet?

Time-based control is definitely a weakness of the current Timeline situation -- and a native implementation would rock so hard.

 

nm~

 

I place markers and use this:

Code (CSharp):

1. var timelineAsset = playableDirector.playableAsset as TimelineAsset;
2.             var markers = timelineAsset.markerTrack.GetMarkers().ToArray();
3.             playableDirector.Play();
4.             playableDirector.time = markers[0].time;

playableDirector is whatever timeline you want to play with.

For play/pause and jumping to specific spots through markers, adding a signal, than having it fire off a script, literally changed my life.

It's a pretty legendary workflow. Never read time in your script ever again and have the signals do the work once the timeline hits a marker

 

This is a cool workflow. I was thinking something along these lines. Might be worth a little more explanation or step-by-step for those who don't understand how you mean for them to use this.

Thanks for sharing though!

 

Am I understanding correctly that you can't use events in Timeline at all without using signals? I've read the explanations about why signals work the way they do -- but didn't really see any reason why the most basic and intuitive use-case for them isn't supported. IMO it should be default behavior to act like the event system.

 

Using built-in systems, yes, you need to create a SignalAsset and use a SignalEmitter marker which is then reacted to by a SignalReceiver component.
It is possible to build a utility that allows circumventing SignalAssets and configure reactions directly to markers. But editor support is tedious to implement, because the timeline editor tools are all internal classes that are not reusable.

Also consider the advantage of signals. Without them you end up with a receiver component that has a very large amount of reactions, because it needs one for each marker. So instead of many SignalAssets, you have many reactions. It's not necessarily better.

On a different note, we would really need data-carrying emitters. And that is something that could be combined with SignalAssets as well. That way we could use the advantages of SignalAssets and still make reactions depend on the SignalEmitter. I think by default, SignalReceivers should pass on the emitter object as an argument. Events should always pass their source as an argument.

 

Is there some way to give multiple parameters in a signal ?

For example a reaction with two strings as parameters ^^

 

So, Timeline signals are extensible and we can extend SignalEmitters + implement our own SignalReceivers.
This way, we can actually add parameters directly to a SignalEmitter (and not on the receiver!!) on the Timeline.

Thanks to this full tutorial :
https://gametorrahod.com/how-to-make-a-custom-signal-receiver-with-emitter-parameter/

That's a shame I haven't found it documented anywhere, this is really useful and probably very helpful for a lot of people !

EDIT : better yet solution for most use case (info directly in the Timeline, no need to directly set data and behaviour on final receivers) is just to extend Markers

 

A couple of questions to the Unity devs.

Why is the relationship between the SignalEmitters and the SignalReceivers many-to-1? Why do I need to bind a signal track to a specific game object? The SignalReceiver component that you attach to a GameObject subscribes to one or more SignalAssets. So what is the point in also binding the SignalTrack to a GameObject? If only one GameObject can receive an event from a SignalEmitter, why have the SignalAsset at all? If I have a SignalAsset on disk/in memory, why can't multiple GameObjects subscribe through it simultaneously without needing separate signal tracks for each GameObject?

The Timeline Signals system is so very close to being brilliant, if only it wasn't hobbled by having a many-to-1 dataflow. If instead it was a many-to-many relationship, with a data/event flow of "many SignalEmitters -> one SignalAsset -> many SignalReceivers" it would be a lot more flexible and concise. With the SignalAsset in the middle, all I should need to do is place the SignalEmitters in the correct place on the timeline on a single SignalTrack, and then add SignalReceiver components to any/all GameObjects that I need to receive the events.

 

Yes. The current workflow manages to neatly sidestep the twin risks of "simplicity" and "flexibility". Quite an achievement. ;-)

Either get rid of SignalRecievers entirely or make them useful.

Ideally - both! Have a quick and simple workflow and a more flexible, optional one.

 

This looks very cool.

Just for context - my issues with timeline signals came from a time when I was running workshops and interacting a lot with non-coders curious about Unity - so I was very focused on the out of the box experience. I'm aware of how customizable most of Unity is - but defaults still matter.

 

@DavidGeoffroy

This is definitely an improvement. It makes it much easier to add listeners without requiring separate signal tracks for each listener. Thanks so much for this!

The only definite bug I can find, at least with a quick glance as it's almost my bedtime, is that while runtime events from the SignalBroadcaster will fire, editor events won't. There's one other that might be a UX shortcoming with the fast implementation, I seem to be unable to have one SignalListener respond to different events with different behaviours.

For example, if I had a CutsceneStart and CutsceneEnd signal emitter that disable and then later enable a component, with the SignalReceiver I could easily set it up like in the image below.
In this image, when a CutsceneStart signal is received, the Camera and Audio Listener components on the Main Camera should be disabled, and when the CutsceneEnd signal is received they should be enabled again. Eg, if I'm changing to a cutscene specific camera.

However I'm not sure I can't seem to set up the same behaviour with the SignalListener.
In this image, I can add the Camera and Audio Listener disable, but I can't filter it so that the Cutscene Start disables the camera, and Cutscene End enables it, in the same way I could with a SignalReceiver.

On the timeline itself, it would look like this. With the first marker being Cutscene Start, and the second Cutscene End.


It's definitely a huge step forward regardless though, and I very much appreciate the work you've put in!

 

As I said above, it's definitely an improvement. It moves from a many-to-1 to a many-to-many, which is exactly what I said having just re-read my first post and realised I completely forgot to mention a one-to-many relationship!

My bad, I'm sorry for leaving that out. Definitely should be in bed at 1am!

 

This whole "Scriptable Object" instancing aspect of Unity, especially where scenes are involved, needs to be reworked -- and not just in Timeline.

This "scene-based" setup has a number of problems for more ambitious use-cases:

• makes streaming worlds impossible without HUGE investment in architecture / editor workarounds
• forces users to use scenes when subscenes are preferred most of the time
• global application variables are difficult and hard to manage / track
• obviously Timeline Events struggle and are frustrating to work with due to the tech limitations
• the idea of what a 'scene' is -- and the workflow itself in practice -- is not the same as what it is implied to be, despite the technology leaning toward the _implied_ scene concept of being a simple "data-storage" mechanism
  
  
• a gameobject is, arguably, a much BETTER data-storage mechanism (for transient data) than a "scene" is, and could double as a 'scene' functionally, if given a flag that allows it to do so (sort of like what is done with DOTS and Megacity in a way)

The Visual Scripting team's "Application Variables" and "Scene Variables" per graph needs a Unity Editor equivalent. The gameobject approach mentioned in that final bullet-point could address this (and help world-streaming use-cases, which are the one reason (out of an ever-growing list of reasons) why I'm looking hard at UE5 right now... D:

Something like this issue with scenes is a great reason why this needs MUCH more attention, and why gameobjects, if you guys are really committed to them, need to be a first-class citizen for transient data-storage. Data should be easy to access _and_ make sense where it is stored. Just like you have a "Prefab" and a standard "GameObject", you could also have a "DatabaseObject" which can be anything -- including an actual "Scene" in this case.

The whole "Scene" concept has changed over the years, and with "Subscenes" (preferably a "hierarchy" of scenes -- akin to a collection of gameobjects) is MUCH preferred for the sake of reusability and flexibility. And not just as your standard hierarchical "gameobject" data storage -- there wouldn't be an inherent hierarchy unless the user decides it to be the case -- again, kind of like Prefabs can be "Nested" -- or not -- while still being their own thing (except in this case, your gameobject "Components" would be the additional prefabs for a flat data-structure like a scene).

I can't see how this couldn't be done with the technology as it is right now. -- It just takes thinking outside the box.

 

I really like using an asset to represent a signal, the benefits over passing a String etc are clear, and it's also a good approach to avoid any issues with GUIDs and cross-scene references etc. Since we're already using assets, it feels like Unity has done most of the work needed to offer a global signalling system where the asset is used to mediate it. Kind of like how some people use scriptable objects as persistent global variables that stay synced across the project.

There's a reason so many games and several top assets implement some kind of global messaging pipe or event dispatcher, it's a highly useful pattern. While the classic Signal Track limited to a single bound object is definitely necessary for many use cases, I think we need something like a Global Signal track that dispatches an event to all valid receivers.

I'll run through a few examples of potential usage:

Example 1: One-to-one with separate playable directors
Say we have a timeline for an Enemy that just moves on a set path and then explodes. We drag 10 enemy prefabs into the scene and each has a PlayableDirector on it using the same timeline asset, with the bindings for each enemy hooked up. If I understand correctly, we can already do this by making a signal track bound to an Enemy object that tells that specific enemy to explode. The signal asset here isn't really doing anything though, it may as well just be a string.

Example 2: many-to-one (not currently possible)
Say we want to add screen shake when an enemy explodes. We now need to create a separate signal track bound to the main camera in order to tell a script on the camera to do its shake thing. In this case it's the binding that's problematic -- there's no specific reason we should need a reference to the camera in here, and it may not even be possible to set this up in the editor if we're using a multi-scene or procgen environment where the PlayableDirector and Camera aren't in the same scene. We should instead be able to send out a global signal out called CameraShake or something and then put a receiver on the camera to catch it.

Example 3: One-to-many (not currently possible)
Say we have a timeline for a rain event that switches on a bunch of effects and then tells all the trees and rocks to switch to wet versions of themselves, and then at the end it swaps everything back. Currently we would have to drag every single one of those effects and every tree and rock into its own separate signal track because Unity only sends the signal to the bound object. We should be able to simply fire off a Rain event from the timeline and then put signal receivers to catch it on the prefabs for the rocks and trees and all those effects. The problem would be scaling and efficiency with call overheads depending on how it's implemented, but that's solvable.

 

I'd just like to reiterate that as much as handling scaling issues and complexity is important, any solution should also have a simple path. Many use cases are ad-hoc and one-off and providing complex solutions for complex situations shouldn't affect the simple case.

I'm not even sure if timelines should have been assets in the first place, rather than scene or prefab level components. A lot of the problems would have gone away if timelines had a similar life-cycle to other components and bindings existed within a scene or prefab. We have tools and workflows for managing cross-prefab bindings and it's hurt the common case a lot.

YAGNI

There seems to be a lot of Unity feature design aimed at a mythical user who:

a) can't code C#
b) doesn't have a team with a C# dev on it to create custom tooling
c) but is working on a project complex enough to need a lot of modularity and reuse.

I'd argue that if (c) is true then one of a or b is also likely to be true.

I'm not sure if this person exists in sufficient numbers to bend design to their interests.

 

So just before Christmas @DavidGeoffroy provided a UnityPackage with a SignalBroadcaster/Listener for Timeline, that allowed for a single SignalTrack to trigger events on multiple game objects outside the Timeline.

The primary limitation with this package, at least from my use-case perspective was that while a GO could receive multiple signals from a signal track, it couldn't filter them. Any events added added to the list would be triggered for all signals the listener is listening for. It turns out that this was a UI limitation because the SignalListener did not have a custom inspector.

So, attached to this post is a UnityPackage that takes the SignalBroadcaster/Listener that David provided previously, and adds the custom inspector used by the Timeline built in SignalReceiver. There is a couple of limitations/bugs with this listed at the end of this reply, but it adds a lot of flexibility to the signal track. I've only tested this with Timeline version 1.6.3 but it should work with other versions that use the same SignalReceiver base class.

Hopefully this helps some of ya'all with making signals in Timeline more flexible. I probably won't be able to fix the two known bugs below, the second one in particular isn't affecting my own use-case for this so I don't have time to invest in it, but if you think you can feel free to modify the code.

Install instructions.
1. Embed the version of Timeline that you are using into your project.
2. Import the Unity Package. It will extract seven scripts into "Assets\Timeline" nested in a couple of subfolders.
3. Outside of Unity, in your OS file manager, move the contents of "Assets\Timeline" to "Packages\com.unity.timeline" preserving the folder structure.
4. Enjoy!

Known bugs.
1. If you add both a SignalReceiver and SignalListener to a single GameObject, one of the two will be blank in the inspector. I believe this is a limitation of the default SignalReceiver custom inspector, as it only expects a single Receiver on a GO. The workaround is to ensure you only have either a SignalReceiver or a SignalListener on a GO. Not both.
2. While the custom inspector has a dropdown allowing you to select whether the event should be triggered in runtime only, or editor and runtime, only runtime only events are triggered at present. This is a limitation of the underlying SignalListener implementation, that I haven't been able to figure out a quick solution for.

 

I think its kinda silly how I can't pass different parameters to different emissions of the same signal. I want to use signals for dialogue, and each time dialogue is sent it should be with a different scriptable object containing that information. but now i have to go and make a custom signal solution for that...

 

You can build utilities to do this. You need to write custom implementations of Marker and INotification, and
INotificationReceiver. You can even have custom icons for markers, configure reactions to individual markers, etc.

I use this a lot for my characters where every ability is represented by a timeline and I got fed up by the tons of signal assets that I had to create and that felt very redundant. The screenshot is an example with a marker that holds data of type float. The dropdown shows the two markers of that type with the name of the timeline and marker, as well as their respective position in the timeline.

Maybe I should extract my timeline extensions from my internal utility package and publish this. It turned out quite useful.

 

I feel the opposite. A [AA] game may have 10,000 line of dialogue, why would you want 10,000 scriptable objects in your project folder? It's not like you will re-use any of those lines of dialogue again.
Just like a method that multiplies 2 numbers together, you'd create 1 method with parameters instead of a new method for each combination of numbers you want to multiply.

I had to do this exact thing yesterday for speech bubbles and create a custom signal type. While it was relatively easy, this functionality absolutely 100% should be already in the engine. There should be half a dozen custom signal types for basic parameters types that would help starting developers.

 

Sounds intriguing.
Might a Signal Asset at any point be reached out to add it properties that can be recovered by a Signal Listener ?
Does that intend that with the ongoing work process just a single Signal Receiver can be "tie" to a SignalAsset ?
There were a ton of recordings and promotion about Scriptable Object to deal with properties and occasions - it would have been cool to have a SignalAsset to be this way - importance have the option to set off when the SignalEmitter is "consumed". SignalReceiver could essentially enlisted to the SignalAsset. It would permit to have more than one SignalReceiver "tuning in" to an equivalent SignalAsset.
Much obliged
May Allah protect all of us from evil eyes, Nazar ki Dua