One of the big limitations of the single delegates we learned about in the previous lecture is that a single delegate can only call back a single callback function. The most recent callback function that was bound to that delegate. There are certainly lots of situations where we'd like a delegate to be able to broadcast to as many callback functions as we need for whatever we're trying to accomplish. In this lecture, you'll learn how we can use multicast delegates and events to accomplish that. This is our project from the delegates lecture from last time and single delegates work great if we have only one talker and only one listener. But if I add another listener actor to my map and put it in an appropriate place and when I run the game, you can see that only one of those listeners is getting called when the delegate is executing. That's because one of them binds itself to that delegate on BeginPlay and then the other one binds itself to that delegate on BeginPlay. That last binding is the only one that has an effect. If we have multiple listeners that need their callback function called when the delegate is executed, using a single delegate won't work for us. The answer is to use a multicast delegate instead of a single delegate. As you can see, we have documentation here that tells us how to do that and you can read that documentation. I'll show you in the example how we can actually use a multicast delegate so that multiple callback functions get called when the delegate is executed. Let's go take a look at the code that actually does that. First, I'll show you that the changes that I've made to the code actually solve our problem and then I'll show you those actual changes. If I run my game every three seconds, you'll see that both listeners are having their callback functions called when the delegate is executed. First, I've changed the way I've declared my delegate. Instead of using Declare Delegate oneParam as my macro, which just defines a single delegate type, I'm declaring a Multicast Delegate OneParam. I've left the type name of that delegate the same and it still only has an f string parameter, but it's a different kind of delegate. It's a multicast delegate, not a single delegate. The rest of my talker actor header file is the same. My implementation file changes slightly. When it's actually time to execute my delegate, I don't use execute if bound, I use broadcast. The broadcast function will call back all of the callback functions that have been added to this delegate. Not just one, like we saw when we bound a callback function to a single delegate, this will broadcast to every callback function that has been added to this delegate. In my listener actor, I've added an additional field here for a delegate handle. We'll see why I need that when it's time for me to remove this particular object from the broadcast list of callback functions. The rest of this header file is the same as it was before, but the implementation file changes a little bit. In BeginPlay, I still find the talker actor, but this time instead of calling BindUObject, I call AddUObject because I'm just adding myself to the list of objects that have a callback function that should be called back when the delegate is broadcast. I also sieve the results of calling that function into that delegate handle field I showed you moments ago. The reason I need that is because when I want to remove myself, when this particular listener actor is being removed from the level or the map, I can't call unbind anymore with no parameters. Remember the unbind function had no parameters. For a multicast delegate, I need to call the remove function instead. The remove function has a single parameter and that parameter is the delegate handle that I saved when I added this UObject to that delegate. That's why I need to sieve that delegate in handle, so when it's time for me to remove myself from that multicast delegate, I can provide that handle that was provided to me when I added myself to that multicast delegate. Back in the talker actor header file, this works fine for having multicast delegate. We might want to actually limit which classes can actually broadcast a particular delegate type that we're defining, FMessageDelegate in this particular case. With multicast delegate, any class can broadcast an FMessageDelegate, but we might want to be more limited, if we know that there's only one class in our game that should be able to broadcast a particular delegate, then we can limit the broadcast capability so that only that class can broadcast that delegate. The way we do it is instead of using multicast delegate, we use Event in our macro and we need to change our list of items provided to the macro. The very first thing we put is the name of the class that is allowed to broadcast the delegate. If I say a talker actor here, that's the name of the class that can broadcast our delegate and only a talker actor object can broadcast that delegate. I'll compile again. Then back in the editor, when I run the game again, it's going to behave exactly the way it behaved before. But I wanted to show you that if in fact we want to limit who can broadcast a particular delegate, we can use one of the event macros that are available to us to do that. If we don't care or if we have multiple objects that we want to be able to broadcast a particular delegate, which we'll see before we're done with this particular lesson, then we definitely want to use a multicast delegate. If we do care and we only want objects of a particular class to be able to broadcast the delegate, then we use the Event macro instead. To recap, in this lecture you learned how to use multicast delegates and events in unreal and you also learned that using multicast delegates and events lets us broadcast to multiple callback functions.
