Hi, I would like to know what is the difference between Event Dispatcher and Blueprint Interface and an application example in each of them. I would also like to ask if with the Blueprint interface I always have to use my pawn. Thanks
The use case is totally different.
BPI is a type independent way of talking from one actor to another. One at a time. Example, I talk to the door, and say ‘use’, or ‘open’.
A Dispatcher is a way of talking to many actors at once. The ‘listeners’ all register with the dispatcher, and with one call, they can all be activated. An example would be many lights all registering with a central controller, then I can turn them all on or off at once.
With BPI you don’t need to know the type of anything you’re talking to. With dispatchers, the binding actors do need to know the type or the actor they’re binding to.
9 Likes
But at BPI, does the pawn always have to be involved?
Not at all 
Sure you can send a message from a pawn BP, or to a pawn BP, but they are just actors.
You can send a BPI message from any actor that has a blueprint ( or C++ ), to any other actor.
2 Likes
I’ve always thought it was a real pity you can’t use EVs ( why not EDs? ) without know the type of the actor you’re binding to.
I mean, BPIs just throw the call down a black hole if the receiving actor doesn’t implement it, why can’t EVs do that? Like, I’m going to bind to an event called ‘myevent’ in actor A, and maybe actor A doesn’t even have that event…
I think the problem with getting a system like that working is that you cannot make a BlueprintImplementableEvent or BlueprintNativeEvent or BlueprintCallable return a FDelegate object that would be the hook for the bind inside of an interface.
Tried it but whenever I wanted to expose the FDelegate I would hit a roadblock.
It would be nice & make work a lot more abstract.
1 Like
I noticed stuff like this
or
Hmm if that plugin is global then it has to be based off of a static library.
1 Like