Event Dispatchers explained - Finally!

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.

  1. 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.

  2. 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.