Search Unity

  1. We are migrating the Unity Forums to Unity Discussions. On July 12, the Unity Forums will become read-only.

    Please, do not make any changes to your username or email addresses at id.unity.com during this transition time.

    It's still possible to reply to existing private message conversations during the migration, but any new replies you post will be missing after the main migration is complete. We'll do our best to migrate these messages in a follow-up step.

    On July 15, Unity Discussions will become read-only until July 18, when the new design and the migrated forum contents will go live.


    Read our full announcement for more information and let us know if you have any questions.

New in 2019.1 - Timeline Signals

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

  1. ROBYER1

    ROBYER1

    Joined:
    Oct 9, 2015
    Posts:
    1,455
    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.
     
  2. andybak

    andybak

    Joined:
    Jan 14, 2017
    Posts:
    569
    Well I for one would love to see the results. So go ahead. :)
     
  3. AndrewKaninchen

    AndrewKaninchen

    Joined:
    Oct 30, 2016
    Posts:
    149
    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:
    upload_2020-6-25_15-45-40.png

    upload_2020-6-25_15-46-47.png

    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).
     
    awesomedata, seant_unity and andybak like this.
  4. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    6,473
    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...
     
    awesomedata and hippocoder like this.
  5. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,419
    Looks really good -- I wonder how far you got on this?
     
  6. AndrewKaninchen

    AndrewKaninchen

    Joined:
    Oct 30, 2016
    Posts:
    149
    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).
     
    awesomedata likes this.
  7. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,419
    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. :)
     
  8. zIyaGtVm

    zIyaGtVm

    Joined:
    Dec 27, 2017
    Posts:
    131
    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'.
     
  9. DavidGeoffroy

    DavidGeoffroy

    Unity Technologies

    Joined:
    Sep 9, 2014
    Posts:
    542
    It's fairly easy to just rename it to something else if it's conflicting with something else that you are using. It is sample code, it's not guaranteed to do anything else but provide an example that works in that context.

    That said, since it's extremely easy to change, I have updated it with a renamed version that doesn't conflict.
     
  10. Hypertectonic

    Hypertectonic

    Joined:
    Dec 16, 2016
    Posts:
    75
    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?
     
  11. AndrewKaninchen

    AndrewKaninchen

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

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,419
    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. :(
     
  13. xCyborg

    xCyborg

    Joined:
    Oct 4, 2010
    Posts:
    634
    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.
     
  14. Blarp

    Blarp

    Joined:
    May 13, 2014
    Posts:
    270
    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
     
  15. Blarp

    Blarp

    Joined:
    May 13, 2014
    Posts:
    270
  16. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,419

    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.
     
    Blarp likes this.
  17. Blarp

    Blarp

    Joined:
    May 13, 2014
    Posts:
    270
    nm~
     
    Last edited: Jun 28, 2021
  18. Blarp

    Blarp

    Joined:
    May 13, 2014
    Posts:
    270

    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
     
    awesomedata and andybak like this.
  19. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,419
    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!
     
    Blarp likes this.
  20. JonTerp

    JonTerp

    Joined:
    Aug 20, 2014
    Posts:
    9
    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.
     
    Last edited: Jul 9, 2021
    andybak and awesomedata like this.
  21. olejuer

    olejuer

    Joined:
    Dec 1, 2014
    Posts:
    211
    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.
     
  22. Midiphony-panda

    Midiphony-panda

    Joined:
    Feb 10, 2020
    Posts:
    243
    Is there some way to give multiple parameters in a signal ?

    For example a reaction with two strings as parameters ^^
     
    awesomedata likes this.
  23. Midiphony-panda

    Midiphony-panda

    Joined:
    Feb 10, 2020
    Posts:
    243
    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 ! :D

    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
     
    Last edited: Sep 30, 2021
    Blarp likes this.
  24. SideSwipe9th

    SideSwipe9th

    Joined:
    Jan 10, 2019
    Posts:
    46
    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.
     
    awesomedata likes this.
  25. andybak

    andybak

    Joined:
    Jan 14, 2017
    Posts:
    569
    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.
     
    awesomedata likes this.
  26. DavidGeoffroy

    DavidGeoffroy

    Unity Technologies

    Joined:
    Sep 9, 2014
    Posts:
    542
    @SideSwipe9th
    I whipped this unitypackage together in about 30 minutes, so the UX is nonexistent and there are certainly bugs, but tell me if it does (mostly) what you want:
    • You can bind the SignalBroadcaster to your signal track, and it will broadcast the signal to any registered SignalListener.
    • You can add the SignalListener component to any GO, and it will automatically listen to all the signal assets in the "Signals" list, no matter where they are fired and trigger the associated Events.
     

    Attached Files:

    awesomedata, SideSwipe9th and andybak like this.
  27. andybak

    andybak

    Joined:
    Jan 14, 2017
    Posts:
    569
    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.
     
    Lars-Steenhoff and SideSwipe9th like this.
  28. SideSwipe9th

    SideSwipe9th

    Joined:
    Jan 10, 2019
    Posts:
    46
    @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. upload_2021-12-17_0-34-8.png
    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. upload_2021-12-17_0-33-55.png
    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.
    upload_2021-12-17_0-35-34.png

    It's definitely a huge step forward regardless though, and I very much appreciate the work you've put in!
     
    awesomedata likes this.
  29. DavidGeoffroy

    DavidGeoffroy

    Unity Technologies

    Joined:
    Sep 9, 2014
    Posts:
    542
    @andybak
    We're well aware that signals are cumbersome, annoying, and generally frustrating to work with.

    But there are limitations with the current tech on what we can do about it.
    • Playables ultimately need to write to Components, GameObjects, or ScriptableObjects. Any other solution has shown to be unreliable, or not to scale well.
    • AnimationEvent-style callbacks really scale poorly, and are terrible for non-programmers.
    • Assets cannot refer to objects in scenes, so there needs to be somewhere in the scene that holds the binding between events and actual scene objects.
    • Global callbacks are generally a bad idea (as convenient as they can be).
    • Assets are annoying to manage, but they are the best at surviving rename, move, etc.. and don't require a programmer to work.
    So every once in a while, we try and figure out a solution for this, but we haven't found a really good one yet.

    I like this prototype though, and maybe we can build something more solid out of it, assuming people like it.
     
    NIOS, awesomedata and SideSwipe9th like this.
  30. SideSwipe9th

    SideSwipe9th

    Joined:
    Jan 10, 2019
    Posts:
    46
    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! :)
     
  31. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,419
    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. :(
     
    Midiphony-panda likes this.
  32. Nyphur

    Nyphur

    Joined:
    Jan 29, 2016
    Posts:
    98
    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.
     
    SideSwipe9th likes this.
  33. andybak

    andybak

    Joined:
    Jan 14, 2017
    Posts:
    569
    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.
     
    Lars-Steenhoff likes this.
  34. SideSwipe9th

    SideSwipe9th

    Joined:
    Jan 10, 2019
    Posts:
    46
    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.
     

    Attached Files:

    Nyphur likes this.
  35. ETGgames

    ETGgames

    Joined:
    Jul 10, 2015
    Posts:
    104
    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...
     
  36. olejuer

    olejuer

    Joined:
    Dec 1, 2014
    Posts:
    211
    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.

    upload_2023-6-30_10-40-8.png
     
  37. Ziplock9000

    Ziplock9000

    Joined:
    Jan 26, 2016
    Posts:
    360
    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.
     
  38. Awan212

    Awan212

    Joined:
    Mar 1, 2024
    Posts:
    4
    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
     
    Last edited: Mar 8, 2024