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