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]
OPEN-EAR EVENT DISPATCHERS (OR LISTENERS)
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:
-
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.
-
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.
[I will talk about what all the options do in a moment. Bear with me for now.] -
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.
-
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.
-
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.
OPEN-MOUTH EVENT DISPATCHERS (OR TALKERS)
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:
- Open the blueprint which is going to be the talking GameObject and declare an event dispatcher.
- 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.
- The above blueprint will give a shout as soon as talking object is spawned in the game world to notify the nearby listening blueprints.
- 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.
- 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:
-
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.
-
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.
-
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.
-
Unbind all
This node will unbind all previously delegated events from an event dispatcher.
-
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.
-
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.
- 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.
- 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.
- 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.
Thanks,
DNADrone
Thanks a lot.