I don't understand Event Dispatchers

I don’t understand what the advantage to an event dispatcher is. It seems like an unnecessary extra step that requires either a cast or an interface call, even though I can already call a function or event with either of those methods without the dispatcher.

When and why should you use event dispatchers?

1 Like

Dispatchers are for when you want many actors waiting for a signal from one actor. They all get the signal at the same time.

2 Likes

In addition to what ClockworkOcean said, dispatchers allow objects to communicate even if they don’t know about each other (or each other’s classes). You can have an actor A broadcast something on a manager actor M and actor B listens to that broadcast, without knowing about A. Alternatively, actor A broadcast its own dispatcher and B listens to it, without A knowing about B at all.

That’s the thing I’m confused about. Doesn’t Call require the blueprint that is doing the calling to know the actor it’s calling too? At which point we wouldn’t need the dispatcher at all?

1 Like

So you would not use one in the reverse situation, for example:

  1. Player breaks open a box with 30 coins in it.
  2. Each coin contacts the game state to store the player’s score

But you would for something like:

  1. Player lays down 30 remote explosives
  2. Player triggers the remote explosives, sending a call to each individual explosive actor?

Scenario 1:
Object A has dispatcher D. Object A broadcasts its dispatcher D whenever something important happens, not knowing about any other objects.
Objects 1, 2, 3, 4, 5 all know about A and its dispatcher D and register to it. They all receive the call, even though A’s logic didn’t explicitly “store” any of them (they registered themselves).

Scenario 2:
Manager M has dispatcher D. The manager doesn’t explicitly have logic for specific other objects.
Object A registers itself as a listener on the manager’s dispatcher D. It doesn’t know about any other objects.
Object B broadcasts dispatcher D. It doesn’t know about A, but A receives this broadcast.

(edit: this wasn’t a reply to your last message, these scenarios aren’t related to your coins/explosives, will write another one related to that)

You’re not obligated to use dispatchers anywhere, they’re just a convenience thing. You can use them in both your examples, but the second example would probably benefit more:

Let’s say the player has a dispatcher OnDetonate. Explosives on their BeginPlay get the player and register as listeners to the player’s OnDetonate. The player broadcasts OnDetonate, triggering all explosives, without logic for manually enumerating all of them.

1 Like

So if I’m reading Scenario 2 right, Manager M has the Event Dispatcher itself, Object A is bound to the event, Object B can call the event even though it doesn’t know about object A, so Object B affects Object A without ever knowing about it?

1 Like

Thanks, this makes more sense to me now!

1 Like

I’m pretty sure you need the class to bind?

You need to know the class of the one owning the dispatcher (in order to get the dispatcher), but not necessarily the one broadcasting the dispatcher. The broadcaster doesn’t need to know any other class.

1 Like

Yes, but the binders do, that’s the downside of this.

Maybe we have a misunderstanding, if you feel like it you can post some pseudocode and we can clarify, but we probably both know how to use these so you don’t have to, and the original poster seems to have gotten the big picture anyway. :stuck_out_tongue:

2 Likes

he’s talking about a lightweight manager class,

ie i have EventManagers as actor components on the GameState which are tiny. So you go GetGameState->GetComponent()-Call/Bind Event

interestingly you can bind via interface if you define the signature in c++ , so you can use a modular event like
GameplayTag EventTag,
UObject/FInstancedStruct EventPayload

1 Like

Yes, it’s different via CPP, but I was only referring to blueprint, which I assume the OP was also :slight_smile:

1 Like

Okay, new question.

I currently have a character that can grind on rails when they hit them. Right now, it checks for rails every tick. I’m thinking this can be done a lot cheaper with an event dispatcher, but even with your explanation I’m struggling a little bit with how to implement it.

1 Like

I would say, not a good example of something to do with a dispatcher, hence your trouble seeing it that way. Tick is right for this sort of character control.

Okay even better! Thanks

1 Like