Event Dispatchers | Unreal Engine 5 Tutorial 

With the exception of Interfaces, most things within Unreal always tend to fall back on Hard References. This just increases the memory load per actor and things become much worse when those referenced actors are also referencing other actors as well. This is why coming from other game engines that do this system a lot better, I was put off by Dispatchers when I first started using Unreal. I feel that still having to cast, just defeats the whole purpose of even having a messaging system in the first place. And although he may have been able to get away with it for the first example, since he happened to be spawning an object into the world, in most situations, dispatchers still mostly rely on hard references to relay messages to the thing you are trying to communicate with. I could just as easily cast to an actor from another one and call the custom events within that actor from the one im using to cast with. And if those other actors inherit from the same class, I could just as easily execute the same call on all of those actors as well. Then what would even be the point in using the dispatcher in the first place? Dispatchers also take just as much time, if not more, to set up as Interfaces do. This is because not only do you have to also create a custom event, you have to set up the call, the cast to get a ref to the actor, and also the bind. There are a significant amount of steps. Interfaces are so much better because you save on memory since they are only weak pointers to the things that are already loaded in memory from the time the game is launched. You can also clear the arrays from retrieved actors, which helps a lot with potential bottle necking. With an Interface, I could have 3 objects respond to a single event call without having to cast to them or risk creating a daisy chain of dependency.

@@ChatterBoks85 I think there is a difference between Soft References and Hard References regarding the loading into Memory. As I remember with soft reerences there is no loading of dependencies until they are being used. I watched a youtube Video about it explaining it I think .

Truth be told, I never even thought to do that. That's actually extremely interesting, thanks for that!

@@TylerSerinoI'm very much of the mindset "how does this actually work?" From removing array indices to this.. I start by prototyping to test "but what if.." And yeah, that's how I found this out. Honestly.. It's less pure curiosity, more paranoia that it'll do something I didn't expect.

Could you elaborate on this a little? I am making a day/night cycle controlled by a timer in my GameMode_BP. I would like the timer hitting zero to call "turn night/day" in my Town_BP. However I am getting stuck at needing a ref in my Town_BP for the 'bind event'. I could Cast from TownBp to GameModeBP, but that destroys the point of dispatching in this case.

@HighTv420 you’ll still have to cast to your game mode, it doesn’t defeat the purpose because your game mode won’t rely on your town bp in any way. But yea anything that you want to use to bind to an event in your game mode is going to have to cast to the game mode

Hi, I vaguely follow what you're saying but could you please give an example use case for this?

My pleasure! Glad it was helpful

you prolly figured it out but for anyone else, the way to dodge a cast would be to create a BPI_Interactable with an Interact Function with a set keybind and then in the weapon BP, add the event for Interact and use a branch node to check if your player pawn is overlapping with the weapon's pickup range collision and then fire the event of picking up the weapon. This decouples and binds the interactability to the weapon BP rather than making the weapon cast to the Player BP per overlap. There should be better ways to do this as well but I hope this helps :)

Whether or not its a physical object, in order to get an object reference, the class must be instantiated - meaning in the world. If memory serves me correctly, the AI controller is referenced by the character you are controlling, no? You should be able to get it with a reference to your ai. Furthermore, I believe there is a node called "Get Ai Controller".

Last I recall, you need to access a given object directly to get it's gameplay tags no? If you're talking about regular actor tags, I believe you could use the does actor have tag node directly from the output, but iirc gameplay tags aren't on the base actor class

So In general, I use event dispatchers when I’m not entirely sure what might need to bind to them, as a way to give access to certain functionality in actors or components, without creating any other dependencies. An example I give in the video is components: take the projectile motion component for example - you want to just be able to slap that on something and have it work without having to add any additional interfaces or otherwise. At the same time, there may be events or functions running in that component that you want the owning actor to know about on a case by base basis. With interfaces, you can slap them on a given object in order to give them a set of functions and events that you can reference from elsewhere without needing a direct reference. The best example there is an interaction system - you may have a ton of different interactable objects, and your player may be tracing for them with a line trace which just returns a generic actor. You can use that generic actor to call those interface functions without needing to cast.

Well you still need a reference to whatever event dispatcher you’re trying to bind to but in general I sometimes find it more efficient to cast when I’m trying to get a reference to something that I know will always be loaded, or at least will always be loaded at the same time as the object casting. Ie casting to the player from the players widget or vice versa is generally safe as far as I can tell.

@@TylerSerino Gotcha, thanks :) Another small question. We got interfaces, dispatchers and casting, is there other types of communication?

@@cosmotect Those are really the big 3 for blueprints. The only other one I can think of are just simple direct references, ie you have a variable that you manually set to your object via the details pannel in the world.

@@TylerSerino I see. Thanks a lot!

@@cosmotect Material parameter collections and the like.