I’m really at a loss for what their purpose is, other than firing multiple events at once…
If that’s the case, doesn’t that basically make it a just sequence node that executes events.
Which, if that’s what it is, that’s well and good, as I’m sure it keeps things a lot nicer than complex branching to determine exactly what events to fire in a given situation, but I feel like there’s something else about them that I’m missing, and it’s annoying the hell out of me!
Dispatchers allow you to add ‘listeners’ to your object.
For example, a UMG button has a dispatcher called: OnClicked. This is the same event that you can add to the UMG graph.
Other examples of dispatchers:
Begin Overlap
On Hit
On Mouse Over
What event dispatchers do is that you can link them to an event in some other BP, and have that event in another BP triggered when something happens in your first BP.
Another good thing is that the class with the dispatcher doesn’t need to know what classes are getting the event.
There are may ways of doing things but is an example of why you may want to use dispatchers. Say you place a television in a scene, there is AI Character in another room, you have a sound cue of a nice static tv noise, a material that changes from black screen to tv noise. Now when you run the game and your character walks to the television and turns it on. The screen springs to life, static noise emits from the speakers and the AI Character hears this and moves towards the television.
All this can can achieved with dispatchers. as mentioned above the dispatcher doesn’t need to know what classes are listening for the event and every little subsystem only need subscribe to the event and action on it when needed. Its great for keeping a separation of concerns and makes your blueprints easily manageable and you can change the tv as often as you like without worrying about messing up the classes listening for the event.