[Music] Welcome back to this, the second part about blueprint communication. We will be going into some further concepts and ways of establishing a direct communication between blueprints. In this episode, we will start off from where we ended last time and move in towards interfaces. Imagine that you have hundreds of objects, and you want to interact with them, and they are all very different, so they can't for some reason be inheriting and getting this functionality. But we have to actually call upon them individually. If that is the case, then this is a very poor method of communicating with them because we would have to cast or try to cast each and every single object that we want to create a connection with and then call an interaction with. Which means that if we had multiple different places where we could possibly also try and interact or some other way communicate with these items, then each time we add an item or remove an item, we would have to go to those different places, and we would have like these hundreds of casts in a long succession.

and it would just be a mess of code. So, what is the alternative to this? Well, for this specific scenario, interfaces would be a good solution. So, what is an interface? Well, an interface is a promise that if you implement an interface, you will accept certain parameters and then you will behave in a certain way. The promise is not about the behavior; the promise is that you will take the input and then you will behave in a certain way. So, if we take the example with the lamp and the garage door, you can say that you're interacting with both of them, and the result is very different. Either a light turns on or a door is opened. You are doing the same thing; you're interacting with them, but the result is very different based on the item that you're interacting with. So, let's demonstrate this to make it a little bit more clear in how it works in Unreal. So, we're gonna create a blueprint interface. So, we'll right-click, we'll go to blueprints, and you see that blueprint interface.

appear here. We'll call this BPI for Blueprint Interface Interact, and we'll open that up. Now, this looks very different from a normal blueprint because, first of all, the grid here is all grayed out, and you can see up here in the top right it says read-only. That is because this is just the promise of interface of how two different classes can interact with each other. It doesn't actually say anything about what the result of that interaction will be, but we can start off with we get a function created immediately, and we'll call this interact. So, this is a function that you promise that you have if you implement this interface. So, if we compile and save and we don't, you can have inputs, and you can have outputs to this just like any other function, basically. But for now, we'll go back to our BP Box, and we'll go to class settings, and you see that it opens up this interface grouping here, which says we have no interfaces. We'll add BPI Interact to this one, compile, save. We'll go to our BP Sphere, and we'll

do the same thing: class settings, interfaces, add bpi, interact, compile, save. So now both the sphere and the box have said that they're implementing these interfaces. Okay, what does that mean? Well, you can see here on the left among our functions and events. Now we have an interface grouping that has appeared that says interact with, which tells us that this is a function or event that you're getting from an interface that you should have available. So if we right-click on this and we choose the implement event, it will create a node that looks slightly different. This symbol up here represents that it's coming from an interface. So what we want to do now is, well, if we get interacted with, what do we want to do? Well, we want to use our interact function, which we have already created here, or rather event in this case. So we'll just drag off a connection here and type interact. Now when this event happens, it will say, Ah, I should use my interact functionality, which is this, which will tell us that the circle blueprint has been interacted with.

cool, so we'll compile and save. We'll go to the box. We'll do the same thing. We'll implement the event. We'll say interact function should be called compile save. Okay, so now we have both of the blueprint events implemented in both of the classes. How do we use this? Well, if we go back to our first-person character, and this is our logic for interacting with the world with the line trace channel, what we can do just to keep this separated. This is not good practice to have multiples of the same code, but I just want to keep them both available so you can see how they work and you can see the difference between them also. So now when we're pressing E, we're doing this exact same thing as before when it comes to the lane trade line trace, and then we have an object to interact with. So what we do is we drag out this actor, and we type interact with, and you see we get an interact with message. Now this class, the first-person character, does not implement

the interface. The sending blueprint doesn't need to have the interface; only the receiving blueprint needs to have the interface. So, what we're doing here is we're saying we got a hit on this line trace. We're going to send an interface message to this object. If this object has that interface implemented, then it will run whatever code it has there. If this object does not have an interface implemented of this type, then nothing will happen. There will be no negative consequences. It will just continue processing as normally. So, let's try this out. Go back to the map, click play, pressing E, nothing happens, nothing happens, nothing happens because we're at the distance. We'll walk up to the box, press E. Box has been interacted with, sphere or circle has been interacted with. Okay, so this particular scenario, we could get rid of this and possibly hundreds of other costs to this specific interface called instead much more handy in this specific scenario. This seems like a fire-and-forget kind of a call, and it sort of is, but you're not limited to having only an

input to an interface. Either you could actually have it return something for you, so you could be sending data to a class, and if it's implementing it, it will receive the information, do something, and possibly send some information back to you, saying like maybe this was successful or something of that nature. Or it could be something way more advanced than that as well, but for instances when this, when you need to check if you need to do something that is agnostically indifferent when it comes to, they don't have an inheritance that exists that allows you to have functionality shared between objects, but you have very different objects, but you need to do something very similar when it comes to communicating towards them, even if the result within them is very different than interfaces, is a very good way of dealing with that situation. Now let us dig into yet another way of how we are able to get references to interact with in some form or manner. Let's think back to our tutorial where we did the door that was opening. It had a collision volume around it, which allowed

any character or player entering the volume to interact with that door by having it opened. Well, that works for each individual object that you would have in the world that would have functionality like that. So, you would have to have a volume around each object. You can do this in a similar but different way, which is this is our character that we're playing with. It can itself have a volume attached to it. So, if we type in box call, we get our box collision. We'll call it proximity volume. Let's see here. It is. I'm just closing down some of the hierarchy to see which level this in. This is under the capsule component. Now, that is good. So, what we can do is we can move this box forward a bit so it represents a head of the character. We'll scale it up a bit, make it a bit wider, maybe even make it further out like so. This gives us approximately the same size as our character but ahead of us, meaning that anything in this volume here is something that we could potentially

interact with, so we'll compile and save, and we'll do something fun with this. So, we'll go back out into the map, and we'll get our door that we made before in the previous tutorial, and we'll right-click on this, and we'll make a duplicate out of it just for this particular example. We don't want to mess up the old logic; we just want to play around with some new logic. So, we'll call this um bp interact door, and we'll open it up. And you remember how we have this proximity volume on this door here, which allows a player to enter it, and then we open up the door here. What we instead want to do now is we want to cut out these two events that are generated from leaving and entering the volume. So, we'll delete those. We will delete the proximity volume. We will then right-click and create a custom event, and we'll call it open door. So, this custom event called open door, it's gonna start doing the door opening there. So, we'll remove this cast.

because we don't need it. So, if anyone was to call this event called open door on this blueprint, then it would start opening the door, and it would run the animation that we did in the last episode. We'll remove this other cast as well, and we'll create another custom event called closed door, and we'll put that in the reverse over here. So, the same functionality as before, but it is triggered differently now. So, how can we make use of this in a nice way? Well, we can say we can make a variable. We can call this, let's call this open, okay? So, by default, this boolean variable called, let's actually rename it to is open, so it's more clear, called is open, is defaulted to false by the checkbox and not being checked in. We can use this as our sort of directionality when it comes to what are we supposed to do with the store. So, let's make a custom event, call this our interacts to be sort of like consistent. So, we expect this to be called at some point, and we want to say that if the door is

opened or closed, we want to behave differently and call these events, so we'll branch on this our if statement. Connect the node, so we'll say if the door is open, then we want to close it, so we'll call close door equally. If the opposite is true, we want to open our door, okay? So now we have that set. Let us go back to our first-person character again, go back to the event graph, and we'll move this interact input that we haven't disconnected because we're just going to show a different interaction now. So what we want to do is if someone or something is in this sphere or sphere, this box volume that we created, the one that we put ahead of the player here, and we press E, we want to interact with it. We don't want to make a line trace towards it; we want to find everything in the box instead, okay? How do we do that? Well, we have our proximity volume. We'll drag it out so we have our reference. We get overlapped, get overlapping actors.

this will, when we press the e key, get us a result of overlapping actors of a certain type. Now, this isn't very good for us because, in the example we talked about with our box and our sphere, those two classes we imagined didn't have a very clear inheritance to them, which made it so that we could inherit functionality instead. So, what we want to do here is something of a little bit of a wide net instead. We wanted to say we want to pick a class here which is encompassed by both of these objects, and we know that all objects in the world are of the type actor. So, let's see, is it by default actor? No, there we go. Okay, so we say anything that is of the type actor in this volume we want to pick up. Okay, what do we want to do with it? Well, we want to go through every object and say interact with it. Okay, how do we do that? Well, we have this array, we drag off on connection and type loop, we get a for each loop, we connect it up with our event.

So this will go through our event, our array of results, which could be zero, it could be hundreds. Regardless of what it is, this isn't something we need to check like before. We need to check if a result was valid with the getting of a certain index, because if this loop contains zero results, it won't loop in the body, and it won't actually calculate on it. It will just go completed, which means that it's a bit safer in that regard. But what we want to do here is we want to interact with each of these elements in here, okay? So let's go and say interact with message, and then we can type a print string here just to say interaction completed, meaning that we have gone through all of the results. And we'll see if we have an empty result. We will just get this printed. If we have more than zero results, it will interact with all of them, and then it will print. So let's go try this out. We go back into the map, click play, we walk up to the box.

It should be within our volume that we have in front of us now. So, if we press the E key, you can see the box has been interacted with, and the interaction completes. Go up to the sphere, we do the same thing, sphere blueprint interacted with, and completed. Okay, so now why does this work? Well, the only thing we did was we chose to use a volume around the character or in front of the character to determine which objects were interesting for us. From those objects, we decided to send the interact message with. So, all of them that have the interface interact with will be actually interacted with. So, the thing we replaced is the actual line traces. So, this is a matter of what kind of preference do you want to have, how do you want to gather the references of the objects that you want to interact with, but the actual interaction part is the same. There are pros and cons with this. This, for example, with the line trace would be more precise. It would be something like the middle of the screen, and you can aim for something and say

you want to interact with that specific thing while this thing would actually interact with everything in a certain area. Meaning, if we go back to the map and we go and move our sphere to be just next to where the box is, and we play and we walk up to them, so we have like sort of both of them where the volume is most likely gonna be, and press e, we'll see both of them appear here. So let us use the door that we modified slightly. We'll put it into the world, but we do know that, excuse me, that we can't actually use this door right as it is right now because nobody's actually calling this interact event. And our functionality currently is that we need to interact with objects that actually have the interface available. So we need to start with adding the interface to this class by clicking class, class, class of things, adding it under interfaces, interacts, and then we compile and save. And then we'll open up the interface over here. We'll implement event. Then we say if someone interacts with us.

We want to run our interact function, which now that I look at it, also has an error in it. Because a door that is opened and we start closing should also be changed to not being opened afterwards. So what we'll do is we'll drag out this is open and we click set and we'll set this to what we can do is we can take is open, get a reference to that, drag off a connector, and type in not boolean. What this means is whatever it is set us currently here, it will take the opposite. And then we can put the inset here. And since this is supposed to happen for both of these executions, we can actually connect them like so. So that means if the door is open, we go here, we start closing the door, and then we set it to the opposite of open, which is closed. So then if we get interacted with again, we go in here and says it's open, it's false. It goes in here, it opens the door, it sets is open to the opposite of false, which is true. So it is opened.

compile save hope that made sense. Let's try it out. So, we walk up to the door. We should be within range now, and we press the interact key. It opens. Now you can see that it said interaction completed despite not saying anything else, and that's because this door is actually only reacting by opening the door. It doesn't print like the other ones. You can also see that you get an interaction completed, and then the door closes long afterwards. And if we go and look at the door opening, it is most likely yes, the length of this timeline is we have an animation running from two seconds four to two seconds from zero to two, but the actual length of the timeline is five. If we change this to b2 so it better matches our animation and go back, this should be more responsive now. It's opening, and we can close it midway, and open, close, and open, close however we want to do it. The very last part we're going to talk about today when it comes to blueprint communication is something called event dispatchers. Event dispatchers could most easily be

be exemplified by a newsletter. If you subscribe to a newsletter for something, I don't know, a movie company or something like that. What you do is they are the senders. They are sending out the newsletters. You are the receiver of the newsletter. They are sending this newsletter regardless of who, how many, or how few are actually interested in it, basically. So, what you do is you say you want to be added to a mailing list. So, when this mail gets sent out, it sends to everybody who has assigned themselves as interested in knowing about this newsletter event. Dispatchers work the same way. You have something that executes some functionality, and it creates, it dispatches an event, and everybody who has said that they're interested in knowing when this event happens can then have their own event available, which will trigger each time the sender's event is called. So, they have a reactionary event, sort of similar to how interfaces have the same interaction, can work in very different ways depending on the different objects, these other objects that are interested in knowing this.

event being dispatched can themselves react in completely different ways to this information as well. Now, to be able to sign up to a newsletter like this, you need to be aware of this fictitious company that is sending the newsletter, right? So, the sender has nothing to do with setting anything up; it just sends the newsletter. It's up to everyone else who's interested in it to sign up to it. So, the receivers are the ones who need to get the reference to the sender to get this to work, and there's a multitude of ways to do this as well. You can either, at the start of a creation of an object potentially, you might have a reference to it, and then you can say, Oh my, I also want to be listening to this event dispatcher that this object has, or it can be created dynamically in runtime. [Music] Let us create an example that creates this in runtime so you can see what it looks like. So, to do this, let's do some changes and build upon what we have already done.

um, let's do this. We'll open up the interface interacting, and we will add an input to this, which will be of the type player interactor. We can name it, and we'll make this of the type first-person character object reference. So, what this means is we'll say that this interface, now that is sent to all of these objects that are interactable, will also get this parameter sent to them. Now, this is a parameter that we send into the interface. So, the sphere, for example, here, now you can see, has a player interactor available here, but it doesn't need to use this information if it doesn't want to. So, for the sphere in the box, we might still want to just like type the information that we had before, circuit blueprint interactive with them and such, and everything will be fine. The important parts to keep in mind here are where we're sending this information. So, if we were to do this, we press E here, we get everything in our volume, we go through everything, and then we send our interact message through the

interface here. Some of them might not want to use player interactor, but some of them might. So, it's important that we make sure to send the information so that those objects that want to use this information actually have this information. So, this is a type of reference to the object of this blueprint that we're in now, the first-person character. So, what we can do is we can drag off from the player interactor. We can just type in self, so this will send a reference to this interface that we are the ones who interacted with. You. That will compile and save. We should do this in all these cases now since we have altered the interface. Those were all the ones we had just to make sure that we don't have a situation where we try using this and then all of a sudden we don't have the information being sent in and things break down. Okay, so now we're sending the information. So, now we want to use this information somehow. Well, let's go to the door. No, let's start off with creating our.

event dispatcher. Our player first-person character is the one that will be acting as the company in our scenario, that's sending the mail newsletters. So, we'll go here to event dispatcher, we'll click, and we call this jump performance, and then we compile and save. So now we have the event dispatcher available here. So, we want to sign up for this event now somewhere. So, we go back to our door, go to our event graph, and we'll say when someone interacts with us through this interface here, then we want to say that this person is of interest to us now. We're gonna start listening to its newsletter. So, we'll take its player interactor here and type jump performed, and we'll get a bunch of different options available to us here. So, the one that's interesting for the receiver here now, which is the door, is that it wants to have bind events to. So, what it says that it will first do the interact part, and we'll do the binding from this player reference that we have here. We'll create a custom event.

this will be a jump has been performed. So, this is our event that we want to have trigger when a jump has been performed. So, we'll hook that up here. So, that means that when we get interacted with, we bind to its newsletter and we say that this is the event that will trigger whenever that newsletter is being sent. So, what we say here is we're gonna say the player that opened me has jumped. Exclamation mark. Compile. Save. So, theoretically, now if the player jumps after having interacted with this door, this event should trigger and it should tell the whole world that the player that opened it has jumped now. So, now we have the actual receiving part done. Now we need to do the transmission or descending part. So, we'll go back to first-person character and we need to hook into the fact that we're jumping, which we can find over here. We'll drag this whole node away so we have it where it's interesting for us. Okay, so when the input action jump happens, it has a press and it has a

release when it's pressed. It starts the jump function, and it's released when it. Then it's the stop jumping appears. What happens so what we want to do is every time it is pressed. The jump is pressed, then we want to call our event dispatcher saying the newsletter is being sent out. And everybody who's listening, you're now getting it. So what we will do is we will drag a note out here and say jump performed, which is the one we see in the bottom left here. And we want to do a call. There we go. So this is the point where we say send newsletter of jump performed. And everybody is interested will get their ping saying ah the newsletter is out. And then they can act however they want. Compile and save. Let's try this out now. We go to the map, click play. So if I were to press e now, nothing happens because I'm out the range of the door. If I press jump, I jump. We get no message. We go up to the door. We press e to interact with it.

interaction is complete. Now the binding should have occurred that it's now interested in this character's event of jumping. So, if we move away, we press jump again. The player has opened me as jumped. So, every time I press space, which is the jump key, the door is telling the world the player that opened me has jumped. This is how events dispatchers work. Now, we don't want to have objects sitting around listening all the time to different things. So, what we want to do is at some point, we most of the time come to the conclusion we're now no longer interested in listening to a specific object. So, if we hear on the interact door gets the interact with call saying we opened or closed the door, and then we bind the event to jump, and then we when we get a jump, we print the string. This might be something that we're just interested in once, for example. So, what we can do then is once we have gotten our very first ping of the player having jumped, we also unassigned to this newsletter.

making sure that we don't take into consideration it in the future on the player reference again. Jump performed and unbind event from jump performed. This became a little bit messy. Let's learn some new things. If you double-click on a connection string, you'll get this happening. The yellow outline, which means that it's currently marked, allows you to drag the node around. This is called a reroute node. Double-click again. I'll make another one. This way, you can clean up your connection nodes a little bit. There, it looks a bit tidier. So, we get interacted with. We do the opening or closing. We bind the event. When the event happens, we react to it. We print. Once we have printed, we say we're no longer interested in listening to this newsletter anymore, and it should never be triggering this again. So, compile, save, go back to the map, play. We jump. Nothing happens. We go up to the door. We interact with it. We go away. We jump. It notices the jump. We jump again. Nothing happens. We go up here again. We interact.

it should have bound it again. We jump. It should have unbound. Now we jump. Nothing's happening. So that's how you keep things clean, so that you don't have everything listening to everything at all times. You just kill off the connections as you deem it necessary and when they're no longer needed anymore for your purposes. So let's take a moment to reflect over what we have done so far. So in the first part, we found actors by class and then we tried to communicate with them on functions and events that they had on that class. After that, we moved on to interfaces, showing how they can be useful in different situations when we have similar functions that need to be called upon different objects that don't have a clear, coherent inheritance structure for them. After that, we went into line tracing and managed to grab objects by sending out our line traces in the world and then acting upon them. After that, next, we moved on to making a collision box for our player, which allowed us to find everything within that box and interact with.

objects in that way, and lastly, we finished off with event dispatchers, making these newsletters which other actors couldn't listen into and then react to accordingly. Well done if you made it so far, hopefully found this video helpful. If you liked the video, leave a like. If you did not like it, leave a dislike. Leave any suggestions or comments down below. Subscribe if you want to see more videos like this in the future. In the next video, we will be looking into user interfaces. That is all for now. Keep on learning. Take care.

Beginners tutorial #6 - Blueprint communication part 2 - Unreal engine 4

Beginners tutorial #6 - Blueprint communication part 2 - Unreal engine 4

스크립트