Event Dispatchers explained - Finally!

Ever since I started working on Unreal Engine 4, I have come across a few roadblocks from time to time which have no solutions on the internet or the official documentation. ‘Event dispatchers’ was one of them and the official documentation regarding the topic is really vague to say the least. So, after a lot of experimentation with Event Dispatchers, I am writing this post where I will try to explain as clearly as I can about Event Dispatchers and why it should be used. So lets begin!

[Also, note: All the names I have used are my own and might not necessarily turn up any good results on google]
[SIZE=6]Event Dispatchers - What on God’s green earth are they?[/SIZE]

This type of event dispatchers are like message-sponges. They will listen to any messages that are being broadcasted. Think of these event dispatchers as the creepy guy in school who keeps eavesdropping on different conversation. Wanna know which girl just turned singe? Just ask the creepy guy. Here is an image to better describe how the Open-ear Event dispatchers work.

To create an Open-Ear event dispatcher in Unreal, perform the following steps:

  1. Open the blueprint which is going to be the listener and declare an Event Dispatcher from the ‘Event Dispatchers’ panel on the left in the event graph.

  2. Once that is done, drag and drop the event dispatcher onto the graph in the following fashion. Note that here, I have used the ‘BeginPlay’ event to initialize the event dispatcher. However, you can initialize it from anywhere you want. Basically, once the event dispatcher is initialized from a blueprint in this way, it will forever keep listening to messages.
    542e776cb8441d55d8e1a7393cbeea2e1260781a.jpeg 3f1c5edfb19b08b26563c47e0ea1b6fefd017c4a.jpeg
    [I will talk about what all the options do in a moment. Bear with me for now.]

  3. Once this setup is done, the event ‘TestEventDispatcher_Event’ will fire every time some other blueprint sends a message to ‘TestEventDispatcher’ and as a result, any nodes connected to ‘TestEventDispatcher_Event’ will fire.

  4. To send a message to this event dispatcher from other blueprints, reference the listener GameObject from each and every blueprint that you want to send messages from and Call the event dispatcher in the following fashion. Note that for the sake for simplicity, I am using a custom event named ‘Something happens’. However, feel free to call the event dispatcher from anywhere in the code according to the operations you need to perform. Also, note that you might need to turn off ‘Context Sensitivity’ to find the event dispatcher node in the other blueprints.
    Calling from BP.jpg

  5. Now everytime ‘Something happens’ the listener object will be getting a message from the other ‘speaking’ blueprints, which is a very handy function to use. This same process can be done from multiple blueprints.

This type of event dispatchers are like loudmouths. They will broadcast any message to anyone who is listening on demand. Think of this as the annoying guy in school who always keeps on blabbering about his life, his love interests and what not just to get the attention of everyone in the room. The following image will demonstrate how an open-mouth event dispatcher works.
[Notice that unlike the open-ear event dispatchers, who only listens from others, this one talks to others without giving a **** if they are interested or not.]

To create an Open-Mouth event dispatcher in Unreal, perform the following steps:

  1. Open the blueprint which is going to be the talking GameObject and declare an event dispatcher.
  2. Then, drag and drop the event dispatcher onto the graph in the following fashion. Note, here I have used the beginplay event, however, feel free to call the event dispatcher from any part of the code according to the logic.
    154fc1c811b5e6f4c10e5f2e850f29d3bf5115dd.jpeg aa53672ecbe91632ddc67d0cbf8a745f5387c236.jpeg
  3. The above blueprint will give a shout as soon as talking object is spawned in the game world to notify the nearby listening blueprints.
  4. To listen to the message from other blueprints, set them up in the following fashion. Note that you might need to turn off ‘Context sensitivity’ in the other blueprints to find the event dispatcher options. Again, this can be done on multiple blueprints and they will all respond to the shouts of the talking gameObject simultaneously.
  5. Once that is done, the blueprint will become a ‘listener’ blueprint which will constant keep listening for any messages from the ‘talking’ blueprint unless deactivated.

[SIZE=6]Anatomy of event dispatchers[/SIZE]

A number of actions are possible using an event dispatchers:

  1. Call
    Choosing this option will return a node to call a specific event dispatcher. This call node basically sends out a message through the event dispatcher which will go to any object which is listening.

  2. Bind
    Choosing this option will return the body of the event dispatcher. This body is the main receiver of messages and will require another event to be ‘delegated’ to it for it to work. Basically, drag a red wire from the small red slot on the node and connect it to a similar slot on any event. Once that is done, whenever the event dispatcher receives a message, it will run the delegated event and run all the nodes connected to it.

  3. Unbind
    Choosing this option will return a node which will basically unbind any previously delegated event. It might sometimes be necessary to stop an event dispatcher from listening to further messages. In a similar fashion as the ‘Bind’ node, just drag a red wire from the small red slot and connect it to a previously ‘delegated’ event.

  4. Unbind all
    This node will unbind all previously delegated events from an event dispatcher.
    Unbind all.jpg

  5. Event
    This node makes the event which can be bounded to an event dispatcher. In most cases, this option is not necessary. However, if the event dispatcher has some inputs parameters (I’ll come to this in a little while), it will generate an event which will output the similar parameters.

  6. Assign
    This option basically does the job of the ‘Bind’ and the ‘Assign’ together saving a few clicks.

Input parameters on event dispatchers
Event dispatchers can also pass some input parameters as messages which can be picked up by any listening objects and used accordingly. This can be very helpful in a lot of scenarios and in-fact, is used most of the time (atleast by me). For example, if the player takes some damage, the UMG should display a red overlay and also the remaining health. This can be done by sending the remaining health as an input parameter through an event dispatcher.
Input parameters can be added by selecting the event dispatcher under the ‘Event dispatchers’ list on the left panel of a blueprint. Once selected, in the details panel there will be a section called inputs where pretty much input parameters of any type can be added.

[SIZE=6]Why would I even use event dispatchers?[/SIZE]
Now that you have a thorough understanding of what event dispatchers are, one question rises. Why would you even go to all the trouble of using event dispatchers? Well, the answer is simple. Event dispatchers are the only way to use communication where you dont care about the target object. In other cases of blueprint communication such as the direct communication and interfaces, you must know who you are sending information to and the target object must know who to receive information from. In a lot of cases, this is not possible. Hence, event dispatchers are used.

If the above paragraph is not very clear, I will try to give some examples of perfect usage of Event dispatchers and hopefully, you’ll have a better understanding.

  1. Let’s say that in GTA, the player character has just got a 1 star wanted level. So, whenever there is a star wanted level, event dispatchers could be used to notify any nearby police cars about the current location and the wanted level so that they can come chasing. If the wanted level rises to 4 stars, the same event dispatchers can be used but this time, the helicopters will also be notified about the user’s location and they will come chasing.
  2. In a room, there are 100 lights which can be turned off and on by a single switch. One method would be to store all the lights in an array and access each of them using a for loop and turn them off individually. However, this not only takes up more memory, it also takes up more processing power and a larger amount of time. Instead, a simple event dispatcher can be used where the switch is broadcasting the message and all the lights are listening to the switch. This makes the process much easier and efficient.
  3. Lets say in an RPG game, all gates need to unlock when the player reaches level 30. So, as the player reaches level 30, the player object sends out a message through an event dispatchers. This message is read by all the gate objects who were listening to the player and thus, get unlocked.

As always, all of the above text are based on some experimentation I did with event dispatchers. Correct me if I am wrong anywhere. I hope you are able to take away something useful from this post. Also, if you have some crazy way you have been using event dispatchers, please write them as comments. I’d love to know all the crazy ways event dispatchers could be used.



Ha great that somebody finally write about it. Now do same about interfaces. :wink:
For some weird reason simple explanation about unreal aspects like this one is very hard to find.

Yeah that is the plan. I’ll handle interfaces next. :slight_smile:

Yes, please do one for Interfaces. I still don’t get it. Or a simple comparison chart for Cast To, Interfaces and Event Dispatchers.

Interfaces are like dispatchers without that event binding. They also can be class independent, you cast to interface, instead of casting to blueprint class that is in.

Or they are like functions that you can call same way no matter of other end class.

And then there are components, they go great with dispatchers and interfaces.

Very nice write up, i look forward to seeing more from you in the future.

Excellent! Should also be in the tutorial forum if not already there. :slight_smile:

How do I add it to the tutorial forum? Copy and paste?

Add this to wiki too please. Very nice explanation! :slight_smile:

Posted on my blog.

Thanks for posting it on the blog. Glad you found it helpful. :slight_smile:

Hey, excellent tut - like the writing style too. Just one thing I’m still a little hung up on…

You wrote “Event dispatchers are the only way to use communication where you don’t care about the target object. In other cases of blueprint communication such as the direct communication and interfaces, you must know who you are sending information to and the target object must know who to receive information from. In a lot of cases, this is not possible.”

Seems to me like there’s still at least some of those steps going on. In the first example (step 4), the talkers have to “reference the listener GameObject from each and every blueprint that you want to send messages from”. That sounds like they should care who their targets are. In the second example (step 4), all the listeners have to reference the talker as a Target in their binding steps. That sounds like they should care who they’re receiving from. Maybe I’m not reading thru it carefully enough. Anyways, thanks for expanding the knowledge out there. I feel more confident to tinker with it at least. Probably will make more sense after I try it a few times.

Wow! You made me understand in 3 minutes that concept i’ve been struggling to grasp for months :smiley: Thanks a lot.

Great examples! Simple and direct!

Really glad to see an explanation as clear as this one. Very well done.

Hey 1|2Hawk,

I’m glad that you found the explanation helpful.
While using event dispatchers, one of the objects (the one in which the dispatcher is actually defined) do not have to care who they are receiving information from or giving information to. For example, in the case of Listening Dispatchers, they will listen to everyone without caring who they are listening from. And in Talking Dispatchers, they will send the information to everyone without caring about if they are listening or not. Obviously, one of the ends need a target reference, otherwise the whole system would be total chaos.

Hope that answers your question.

1 Like

Yeah it does, thanks - been experimenting and what you wrote makes sense now. Going to use the event dispatchers now in my HUD class instead of standard bindings which tick every frame.

wow nice , thx.
im just commenting this to have it in my historic tread :wink:

Cant the same effect be achieved with custom events?

In order for a custom event to have the same reach as the event dispatcher you would have to manually call that custom event for every single actor that you need it to fire in.

With an event dispatcher, you just fire once and all the listening objects execute.

Just wanted to say thanks for posting this, as others have. Due to finally figuring this out I am able to do so much more than I previously was and much more efficiently. You have my gratitude :slight_smile: