Thanks Zak, thats basically what I ended up with…except that it was more like:
Actors/BPs register with a manager class (which could be the Game Mode/State) on spawn (usually directly in BeginPlay)
The Matinee Controller inside the Level BP grabs the current Game Mode/State and calls a function that iterates this list, then calls a method on the registered Actors/BPs
Members of that list simply implemented an interface which allowed them to be triggered to do whatever
It’s kinda nice to get some confirmation that this is the-way-to-go (for now, until a better way is developed), but on the other hand it also shows there is room for improvement
Looking forward to the sublevel-implements-interface thingy, that sounds weirdly awesome.
So, without being in UE at the moment, I’ll take a stab at getting you started. I would personally set up separate trigger volumes on either side of the door. The outside trigger volume (on begin overlap) plugs into a timeline that drives an animation of the door opening inward, while the inside one plugs into a timeline that drives an animation of the door opening outward. You could use matinees, but if you need to do this multiple times in a single level, it gets really old really fast. Using timelines, you can set up a curve from 0 -> 1 -> wait -> 0 that will drive a Lerp node’s alpha pin, where the other two pins hold the information about the door in its normal and open states (probably rotation vectors, if you’re talking about it swinging).
First off, thank you – I’m pretty sure your videos singlehandedly got me through my first UE4 class, and have been a constant reference point for me from first learning to developing full games.
Secondly, I’m wondering if there’s anyway UI widgets might work their way into this discussion tonight? It may be outside the scope of this stream, but communicating between class BPs & widgets/the level BP and widgets is something I’m curious to learn more about.
Thanks for the stream, it was interesting and instructive.
Here a question I asked a bit too late:
I’m wondering if there is any in future update to have the possibility, when using BP interface, to not necessary have to set the target on message call nodes. So all actors having the interface implemented would receive the call and do whatever they need from that.
Someone on the live chat said it would be pretty similar to event dispatcher. Yes except in this case, not only the sender would not have to take care of the receivers, but the receivers would not have to know the call sender either, they just need to know the “language” his using.
I think it could bring more flexibility to BP communication.
I’m posting an unanswered question from the stream here:
Is there a way to check whether an actor is visible on screen, inside the viewport? This was answered partly during the stream by a fellow user. I was referred to delta rotators and this tutorial: https://www.youtube.com/watch?v=8RPk3zldqAA
Is this the best way to do this? I guess I could simply do a line trace for every actor in the vicinity and see if it directly hits the actor. But I fear that I may only target a specific point on the actor and that it would be difficult or impossible to recognize if some part of an actors peeks out.
I also have a more advanced question: Is is possible to check this from the viewpoint of any actor? This would be interesting for programming AI for example… I realize that you can have many workarounds when you program AI and simply “simulate” such functionalities, but it would be much easier if this functionality could be implemented “physically”.
Yes sorry I should have prefixed that with Youtube, it was fine on Twitch.
Will go back a re-watch this when possible, as whilst I understand BP communication pretty well now, I still get a bit lost, especially with Event Dispatchers. Also casting kinda confuses me because as long as you have a reference to something that exists, surely you can just get the information straight from referencing, or am I wrong?
Anyway I will check it out in properly at some point, and maybe get my Asteroids games completed at some point to (put it down for a while as getting dejected with my artistic skills)
I believe single line trace by channel is what you want to use, with the start being your camera and the end being well your object in question. Then just set a bool whenever you need to check, if you are doing it during each frame.
This depends. For the most part references come in as Actors. Consider the ActorBeginOverlap event. Its output is of type Actor. This will give you access to the object’s transform data and a few other useful things, but nothing specific to that class.
Now, you can create your own reference of a given type and if you do that, then you don’t need to cast. In fact, if you do, Unreal will warn you that the cast will always test true. But if you’re using many of the events and functions available in the engine, you’re getting very references, which we have to do for flexibility.
Consider it like this:
In most cases, a reference is kinda like someone randomly knocking at your door. It might be a friend, but you’ll need to verify before you take action. So you might look through the peephole or ask who it is before you do anything. If you know the person, you might open the door. References in BP are more often than not going to be the same way. They’ll come in as something very like an Actor (or a knock at the door) and you’ll need to verify it is what you think it is (the pizza guy) before responding.
Just watched the twitch and it was very helpful. Quick question regarding communication between a Character BP and its Animation BP. I’m using root motion graphics and this requires quite a few of the properties/variables that are coming from the character blueprint which need to be used in the animation blueprint (jump and other action buttons pressed, character motion controller info, look pitch & yaw, etc). I have been using the update animation event of the animation bp and casting to get the character bp then all those variables and set them as local ones that are then used throughout the animation bp; however, this is updating every tick - Its also pretty busy looking. Is this best practice or is there a better way of getting all those variables. It may be that they MUST be every tick being that it controls the animations, but if I am missing something please let me know.
Really a great twitch and I appreciate how Zak does not assume we are all at the same level with our unreal kung-fu. His training is always extremely clear and his examples solidify the concepts very well. Great job!
So in essence what you are saying is that if you are referencing a BP directly you might not be getting the information you think you are getting? Whereas if you cast then you know your casting to a certain type, therefore its safer, even though both obliviously work?
That leads me onto another question (apologies if already answered in stream), again if you are referencing another objects variables, is it therefore safer to do a get/set (from a get/set function in the BP) than just accessing the variables directly? Get/Set is generally how you are supposed to it, or is BP’s just making us lazy?
No, that’s not what I’m saying. I’ts not a question of safety, it’s a question of accessibility. When you cast to a given class, you’re just verifying that the incoming reference is of a given type. If that cast is successful, then you will only have access to those properties that exist within the class you cast to, or anything it has inherited from its parent classes.
Let’s consider a ThirdPersonCharacter. It’s parent class is Character, so its class hierarchy would look something like this:
Object
—Actor
------Pawn
---------Character
------------ThirdPersonCharacter
So let’s say you get a reference to this object. References are just like variables in that they all will have a type. Think of the term “type” in this case just as you would the “specific class” to which the object belonged, or the lowest member of the hierarchy. In fact, it’s a good idea to think of a class hierarchy in terms of how specific it is. More things are near the top, more specific things are near the bottom. Whenever you hear “” you should always think, “further up the hierarchy.”
Most references you’ll get in your Blueprints are going to be of a very type. The most common gameplay reference type is Actor (as a reminder, just about anything that actually lives in your game worlds is probably based on the Actor class). If you got a reference to this object it will more often than not be an Actor reference*. You could cast the reference to anything along the above hierarchy chain and the cast would succeed. However, you would not necessarily be able to access the data you need. As an example, let’s say you wanted to access the FieldOfView of the CameraComponent on the ThirdPersonCharacter. If you cast to a Pawn, that would succeed! Great! But a Pawn does not have a CameraComponent, so you can’t get to the FieldOfView data.
That is why we cast. We need to verify that in incoming reference is of the type you really want to communicate with, so that you can get access to the data you need.
*The exception is in the event you get a reference that is already the type you need. For example, you might have set up a way to get a reference of type ThirdPersonCharacter, then there would be no need to cast in order to access its CameraComponent and the field of view. In fact, if you do try to cast, Unreal will warn you saying that the cast will always test true and is therefore superfluous.
To your other point, how are you accessing variables without using a Getter or Setter?
Thanks for the clarification, makes more sense now.
Apologies, not explained myself very well as far as the get/set question. I guess what I meant to ask was is it inherently safer to have a function inside your class that gets or sets a local variable rather than just accessing it directly from another class.
For example, in my Asteroids game I have an Asteroid class for the Asteroids object. I also have a Game Manager object that looks after score etc. When an Asteroid gets hit I call a function inside the Game Manager from the Asteroid to add a certain no to the score, passing on the score I want to add. However technically I could just set the score in Game Manager directly from the Asteroid If I really wanted to. Both of those solutions would work, however is it inherently safer to do the first option? (I would say it is).
Can you please add time stamps to important topics, especially the non-Powerpoint topics, but including those on the YT video? It will make it easier to direct people to it like that. I appreciate it!
You can safely ignore me now … Finally got around to the part of the stream where you answered the above.
I’m still confused as to the difference between Event Dispatchers and Interfaces, not the technical differences, just the when to use really as they seem (I stress seem) to do the same thing.
They certainly do similar tasks, in that they have the same goal of enabling communication from one asset to another. The real difference is in the direction of the communication. Think of it like this:
Blueprint Interfaces - Imagine handing a list of one-word commands to one of your friends. Simple stuff; words like “food,” “coffee,” “exercise” or whatever. You don’t really care how your friend does those things. You just want to be able to tap your friend on the shoulder at any given point and say one of those commands, and then have something happen in response. The key is that you’re actually having to go find your friend and tap him on the shoulder before anything can happen.
That’s like an interface. The list of commands is like the Blueprint Interface asset. Notice that it’s just a list. It doesn’t have step by step instructions (nothing like: pick up phone, call Domino’s, etc.). It’s just basic commands. Having to tap your friend on the shoulder is like getting the reference. And your friend can only do something on the list because you gave it to them and so they know about all the commands.
But say you go tap a perfect stranger, someone who doesn’t have the list. You walk up, tap them and say “pizza.” They might ignore you and walk away. That’s okay. You didn’t give them the list. Interfaces work the same way.
Better still, you could give the list to 2 different people! They might do different things in response. So you go tap Friend 1 and say coffee, and you get a caramel macchiato. Do the same thing to Friend 2 and they spend the rest of the day making a pot of cold brewed espresso. Two really different things! But that’s okay. Interfaces allow for that. They’re just simple commands and what happens on the far end can be different.
The KEY is you have to go Tap your friends on the shoulder and then issue a command. That’s just like how with Interfaces you must get that initial reference.
Event Dispatchers - Dispatchers go the other way. Imagine you’re at a party with all of your friends. You’re all dancing to some amazing tune the DJ is playing. Every time he hits a drop, everyone brings it down hard and starts really dancing intensely. That’s kind of like an event dispatcher. You, the audience, are listening to the DJ. He’s just doing his thing. Each time he hits that amazing riff, you respond with your most amazing moves.
That’s a dispatcher. The sender (our esteemed DJ) is just up there jamming away. He knows what he’s doing and he’s selected a track that has a really awesome drop (that was him setting up his Dispatcher).
You are coming to the party and listening, and you’re reacting whenever he hits the drop. That’s just like Binding. You’re binding the event of bringing your A-game dance moves out when the bass hits.
But note that the DJ didn’t come tap you on the shoulder. You’re choosing to pay attention by attending the party. You, the listener, got the reference to him. He has no idea who you are.
You could stop listening and go home (Unbind). You could go unplug the DJ’s equipment (Unbind All) so no one else can listen anymore.
The KEY is that you, the receiver, needed a reference to the Sender, the DJ. The DJ doesn’t have to do anything special to you like tap you on the shoulder. He doesn’t even know you exist. You had to get a reference to HIM and attend his show. So the communication is going in the other direction, from Receiver to Sender, instead of from Sender to Receiver.
When to use each one of these really depends on what you’re doing and where you want to have to set up functionality. It’s about what you care about. It’s about who can get a reference to whom. Is it easier or does it make more sense for the Sender to get a reference to the Receivers? Use an Interface. Is it easier or does it make more sense for the Receivers to get a reference to the Sender? Use a Dispatcher.
You’re going to find this is often a philosophical question, meaning folks will handle it in different ways. Don’t stress that. There’s not always a “right” or “wrong” way in these things. There’s just the one that works best in your situation.
