Just thank you, really the way event dispatchers are made was very counter-intuitive to me, now you cleared it all. Cheers! More of these we need…
Well done! I’ve been an Unreal user since the UDK days, and I’ve never seen dispatchers explained this well. Hope to see more from you. Thanks for the resource!!!
Hi DNADrone, thanks a lot for that great tutorial - this is very helpful for me still being a beginner. Now I’m just a little bit confused about the “open ear” version of event dispatcher - maybe you can clarify things.
-
It makes perfectly sense for me to create an event dispatcher (you call it “open mouth”) on a sender, that does not even know who might be on the receiving side and moving the responsibility to any receiver blueprint to a) gather a reference to the sender and b) use that reference to “subscribe” to an event by binding a custom event to it. The sender just calls the without being aware of who might be receiving.
-
As for the “open ear” one: you describe a receiver, that subscribes (binds a custom event) to an Event Dispatcher created on itself (thus using self for the bind). On the other side, each sender now needs to have a reference to the receiver in order to call this event dispatcher. This call triggers the bound custom event on the receiver in order to perform some action.
And here’s my problem with this: As we need to have the receiver reference anyway for the dispatcher call on our sender, what is the advantage of the “open ear” dispatcher logic compared to just calling a receiver side function using that reference via direct communication?
One might argue, that “functions” do not allow to have latent nodes like delay, but in this case, the sender also could call a custom event on the receiver side.
Watching Zak Parrish in “Blueprint Communications | Live Training | Unreal Engine” at https://www…com/?v=EM_HYqQdToE&feature=youtu.be&t=500does tell me, that event dispatchers are the way to go, “if only the receivers can get a reference to the sender” - basically the “open mouth” variant.
I tested all variations, and of course, “open ear” dispatcher works fine, no question. But same for direct communication using function or custom event, which lowers code complexity. In addition, from what I have read, in terms of overhead, the order from lowest to highest is 1. direct comm 2. interfaces 3. event dispatchers, so direct comm should be lowest cost choice.
I suspect, that there’s some important point I’m blind to see regarding the “open ear” dispatcher advantage and/or situations, where this is absolutely necessary. One might be, that the dispatcher version allows to “unbind” - but that could be achieved using a simple flag in the called function as well making it inactive.
Looking forward for some light and thoughts on this.
Same here, I think the “Open Ear” example is not a good one and is not what dispatchers are intended for. If you have a single “Listener” and multiple “Callers,” there is no difference between calling the dispatcher on the Listener and calling the event directly, except that dispatchers are possibly slower? At least, there is no functional difference in the example he provided.
The “Open Mouth” example is similar to an Observer pattern and seems to be what dispatchers are designed for.
I actually think that the open ear example should be replaced completely with interface calls. The “if implements interface” then it calls the function within the blueprint referenced class is always my method of doing anything open eared.
After thinking about this for a week now I have come to the conclusion that both the event dispatcher and interfaces are out dated and need to be deprecated. If you need to talk with an actor just use get all actor of class or if you need to indirectly talk to an actor that you do not have a reference to just create a variable in the Game Instance.
1 Like
the worst reply i have ever read regarding event dispatchers or interfaces
[QUOTE=
Currently, every listening object needs (!) a reference to the object that owns the dispatcher.
[/QUOTE]
Exactly. If you need to maintain references to all objects dispatching events then what’s the point?
If I have players coming in and out of a multiplayer game, and I want these player to dispatch events to a HUD… then the HUD needs to maintain a list of all these players.
Either that or each player needs a reference to the local players HUD. Then in both cases I could just call a custom event on the object.
What I need are true broadcast events, where the caller has no idea who’s listening, and vice-versa.
everything is very crazy in this post including the first one where he first explains the LISTENERS and then the TALKERS.
The examples don’t help either, and I wouldn’t use the Event Dispatchers for any of the examples.
But that does not mean that they are not super important and very useful if you do not want to fill the code with cross references and crazy workarounds.
[QUOTE =
Currently, every listening object needs (!) A reference to the object that owns the dispatcher.
[/ QUOTE]
That is not true, unless I misunderstand the phrase.
1 Like
Seconded. I found the above explanations unnecessary confusing; e*specially *that it omits this functionality:
A component (top) updating a widget (bottom); neither of which stores references to the other. More here.
I loved the explanation and thank you kindly for it. However you did the same thing in your examples, just named the convention differently. Also to refer to blueprint communication you have working (sending) and target (receiver) blueprints, that way we know which BP you’re talking about.
[QUOTE=DNADrone;n72814
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.
[ATTACH=CONFIG]
78969[/ATTACH]
[/QUOTE]
Hi, I’m really struggling with what to reference as “BP test” in my blueprints, if I try a specific blueprint object reference I get an error, but I can’t seem to figure out what I’m meant to be referencing to make it work. I dunno if it’s the right thing, but I’m trying to trigger a directional light to rotate based on the clicking of a play button in the widget blueprint. Really struggling to make blueprints talk to each other in this way and I thought event dispatchers was the way to go but I’m not sure. I could set up an event tick with branches toggled with game instance but that seems quite heavy.
Cheers, Ed.
1 Like
Thank you very much, that’s what I needed. I’m setting it up with a sun sky blueprint with months and days its really awesome thanks to you.
you are breaktaking!!
The images on the original post have disappeared for me! This is a core resource for me - anybody else having this issue?
Thank you so much for the wonderful explanation @DNADrone 
1 Like
Everyone.
It’s another one of the things you can thank the Epic team for…
You can try to see if bothering @Amanda.Schade or @VictorLerp ends up getting it fixed.
BUT… with the way the team behind it has handled the whole forum thing so far, I wouldn’t be surprised if they just deleted the data by now.
That’s unfortunate, this is truly the best resource on Event Dispatchers I’ve found.
Wish I’d saved it somewhere for reference
I wish i could have read it at least once. 
1 Like
Forum migration deleted most of the images in the original post, if you need info about Dispatchers and Delegates, this could be helpful:
Cheers