Event Dispatchers explained - Finally!

[TheCouch]

@Quexlaw;722377

I’m sorry for necroing this thread, but I felt the need to add something to it, with the hope of getting answers.

I actually do not see the point in those Event Dispatchers. The only thing they have going for them opposed to normal events are that they are a collection of events. You save yourself a few nodes but that is it.
I’m relatively new to UE4, but what I’m currently missing as a feature is static event dispatchers.
Currently, every listening object needs (!) a reference to the object that owns the dispatcher.

If I have, for example, a StatsComponent which has HP and an OnHit Event Dispatcher, I can link HP loss and the dispatcher just fine, but what if I wanted to have another component that does something else when the OnHit dispatcher is called? For example, change the camera settings. I can not just put a node in “OnHitEvent” which then changes the camera settings; I need a reference to a StatsComponent first. In LibGDX, a java code-based game engine, this worked just fine; I would call the OnHit Event (dispatcher in this case) and any system that wanted to have some input once OnHit gets called could just register itself as a listener, without the need to “know” of an object first. The actors which were then manipulated by the event were then given as parameters.

To give an example of the workflow I want to have in UE4:
I have an event dispatcher called “Get Hit” in my StatsComponent. This dispatcher has several inputs: ActorA, ActorB, and damage. ActorA is the attacker, ActorB the attacked.
Inside the StatsComponent I bind an event to this Get Hit dispatcher to actually deal with the damage.
Later on, I decide I need to add more flashiness when someone gets hit. I want to show a blood splatter on my HUD. But since I want my code/bp to be organized and tidy, I want to handle this in a different blueprint. Otherwise, I would have to reference my HUD object inside my StatsComponent to activate this blood splatter. This isn’t good style, as the whole thing could become very messy very fast, as there is a lot of functionality you could theoretically handle. Camera effects like screen shake, sounds, particle effects, material instance parameter changes and so on. You don’t want those in your StatsComponent.
Rather, you want to just catch this OnHit event and be given all the things you need to know about.
So, I want to go to my HUD blueprint and make a node “OnHitEvent”, which is a node that gets triggered once the OnHit dispatcher gets called. If I need to know who was hit by whom, this event can just have the necessary inputs, so you can plug in whom is damaged by whom instead of you needing a reference to some object that has a StatsComponent. How would I get this component in, for example, a SoundComponent that is supposed to handle different sounds under different scenarios?

Is there something I’m not getting or does UE4 simply not have this kind of functionality (yet)? It seems counterintuitive that we can bind events to dispatchers, when we, in the end, still need to reference the object owning the dispatcher in each and every single case. You could just call a normal event then. Is there some kind of functionality that I don’t know of that can replicate the behavior I described above?

EDIT:
To precisely say where the fault lies: it’s the target node when binding an event. If we didn’t need that and instead could just call it statically, we could easily add functionality without bloating up single blueprints with content where it doesn’t belong to.
I could go to my SoundComponent and bind the “PlaySound” event to the “OnHit” Event Dispatcher without having to know about WHICH object’s OnHit Dispatcher I’m calling. You could transfer the target to a parameter. This way, you could just use “self” as a parameter if you had to know about the blueprint the dispatcher is owned by.

What you’ve described is pretty much how UR4 works, so I’m confused about why you’re confused. I think you need to study the collision mechanism more closely.

Using the OnHit Event

This:

Collision Filtering in Unreal Engine 4

has been absolutely worth its weight in gold to me. I mean, that’s not right because it’s just a bunch of bits on a webserver somewhere; more like it’s worth a lot, I guess.

As far as event dispatchers go, I don’t think you’ve quite got it. Event dispatchers aren’t (usually) used for one-to-one events (e.g., pawn->controller->hud) but for one-to-many, many-to-one and many-to-many events.

For example, suppose you had a game in which there were two teams.

Without event dispatchers: Each member of a team might have an array of pawns (or controllers) to keep track of their teammates (or, more likely all players). When a member of team gets in trouble (e.g., taking fire, needs healing, etc.) you would loop through the teammate array calling an event on each same-team pawn (or controller) to indicate to the team to help (the HelpMe event). This is pretty complicated and doesn’t scale very well. Each player has an array of pawns/controllers, has their own for loop, etc. Now it’s not terrible, but suppose you had 20 such events. Yuck. Now suppose one of those players dies. You need to do one of two things: either ignore the dead player (your for loop now has a new conditional) or you remove the player from each array “owned” by the player by calling yet another event on each pawn/controller (“PlayerDied”).

With event dispatchers: On pawn/controller BeginPlay you bind to globally available event dispatchers to receive the HelpMe, and whatever other events you need to receive globally (you probably don’t actually need a PlayerDied event). The HelpMe event has as a parameter the player/controller to indicate who needs help. If the player/controller is on your team you respond one way and otherwise ignore it (or whatever). When a player dies you unbind all events from that player/controller.

So, with event dispatchers there’s no looping, no arrays, nothing to keep track of other than THIS player. You can certainly keep track of other things if you need to, but with event dispatchers, it’s not required in the same ways as without them. One way you can think about it is that the event dispatchers keep track of the arrays and performs the loops you would.

Event dispatchers tend to make your code/BP cleaner and more concise and keep your class variables less cluttered (the event dispatchers will tell you who/what “needs the thing”, rather than you iterating through a list to figure it out).