When I tried blueprint communication, I was not clear about the use of Direct communication and Casting in some cases.
I know the definition of Casting and the usage of it for Getting Player and checking the object of Overlapping. But when we try to cast an Actor as a target, it seems to be the same as Direct communication. We all need to use the dropper to select the instance that we put in the viewport. In this case, I don’t understand why Casting is necessary, because we have already selected the instance we want in the viewport. Why not just use the Direct communication method?
There’s a lot of confusion about casting, mostly thanks to youtube.
Here’s how it goes:
-
A direct reference is just that. You have a variable of type ‘blueprint A’ in ‘blueprint B’ and use it to talk to the other blueprint.
-
Casting is ACTUALLY used to find out if the actor you have just encountered IS of the type you suspect it is. Nothing to do with communication. Notice the overlap node
It says ‘other ACTOR’, it doesn’t say, ‘other player’. The overlapping actor could be literally anything ( the sky, the ground, a missile etc ), so we cast to find out ‘hey, is this my player?’
And the cast will say, yes or no, and kindly give us a reference is the answer is yes
While I’m on the subject, this is what’s great about interfaces. Interfaces get called on an ACTOR, not any particular kind of actor. So you can say
( Interact is blueprint interface I made ) and the ACTOR can do anything it wants to with the interact call. No assumptions about what kind of actor it is. No assumptions about what’s it’s going to do when you say ‘interact’. It could flash yellow, or fly up in the air, or open ( if it’s a door )
Thank you for your explanation. Now I understand that Casting is used to test whether the things we encountered are what we want. So if we are clear and sure about the actor that we want to call and do not need us to detect the things we encounter, then we should just use Direction communication, right?
It seems that some YouTube tutorials only add a Cast on the basis of direct communication (for example, pressing the E key can turn on a light selected in the viewport by using dropper), which has always puzzled me
You’ll see a lot of rubbish on youtube
The word ‘cast’ is used interchangeably with ‘connect’. If anything, it should be used interchangeably with something like ‘check’.
There’s no ‘fixed’ scenario. Direct comms is simple and good, but it has the downside ( eventually ) that you end up with what’s called ‘asset chains’. Where everything in the content browser is referencing everything else. That causes bloat, slowdown, and can cause inexplicable crashes. But you have to do a lot of it, for that. ( Same goes for casting, btw ).
The great thing about casting is you get to check, and you get the reference for free. Why not do that?
Also, what if you have 50 AI that are going to overlap your box. You don’t know which one it’s going to be, so you can’t use the eye dropper.
Wait, does that mean, that the Cast is basically nothing more than using an “Equal”-Node with the overlapped actor followed by a branch, that checks, if it is indeed of that type i am looking for ? o.O
Like this?
Could someone from Epic please copy ClockworkOceans post into the official manual?
i didnt read all post so it may have already been said, but i just wanted to add that casting loads the class and gives reference to the instance of the class as well.
A bit semantic, but I’d say its more than just a simple check. It is like you go into a restaurant and they bring out a platter that is covered. You ask, “is that the fish?” They uncover the platter and there is a big fish, and you are able to eat it.
Whereas an == check would be like asking, “is that the fish?” and they just say, “yep” but don’t give you access to it.
So a good time to use casting is when you want to not just confirm something is the class you are interested in, but also get access to it’s data (whatever stuff is in that class that is set to be public).
Another thing that is slightly off topic, but I never see people put anything on the cast failed output. Even in a lot of asset store code plugins I bought, I can’t tell you how much more difficult it is to debug somebody elses code when they don’t use that to print a string on failure.
So put a print string on failure so that if you are getting bad reference problems you’ll be able to easily find the problem spot. It takes an extra five seconds but can save you a lot of stress in the future.
Has tag ? use interface ? == interface !
Exactly on point!
YES!
Checking for tags will greatly reduce instances of chained casting.
e.g. on Hit → Was it this? (fail) → Was it this? (fail)
Interfaces should be a no brainer.
Creating references for classes you’re constantly referring to will reduce load and bloat.
For example in the older v4 templates (animBP’s) the default setup was constantly casting to the character. Every frame there’d be multiple casts like this.
Try get Pawn Owner → Cast to Thirdperson → get some component/variable.
All the new templates for 5.0 do this once on Event Blueprint Initialize Animation
, promote the result to a variable. Then on Event Blueprint Update Animation
they use “Is valid” to validate the reference.
This is the way I’ve been doing it for as far back as I can remember.
- Constantly used references → Promote to var and re-use throughout the class.
- Occasional references → Cast. Debug print string on failures!
- Direct Interactions → BP Interface. Debug print string on null hits (traces)!