The naming of Cast to node

Development Programming & Scripting Blueprint
1

Hi,

as someone who has no programming experience whatsoever, I had a very hard time understanding how Cast To node in Blueprint works, not because I couldn’t get the logic, but because the logic it executes seems completely unrelated to the name of the node for someone who has no experience with programming. And since Epic claims Blueprint is supposed to allow non-coders create game logic, I believe it should have also naming friendly to non programmers.

When I asked my friend, who does coding in UE4 about it, he basically told me that casting in programming is diverse, multi-purpose tool, but its variant inside the Blueprint resembles to “Is of type” operation, and that is something that corresponds with my observation, as well with what the UE4 documentation describes:

“When using a Cast To node in Blueprints, put simply, you are attempting to check if the object you are casting from is the specific object you casted to. In other words, say you have created a special Character Blueprint (called MyCharacter for example) that has variables in it or other custom functionality contained within it and assigned it as the Default Pawn Class (or the Character Blueprint all Player Characters use by default).”

If you have no experience with programming, and see a node called “Cast To”, you will immediately associate such node with operation that takes an information from somewhere, and casts it somewhere else. For example, almost everyone owns a smartphone these days, and if you see a “Cast” button on your phone, you will most likely assume it will cast your screen on the other device. Yet, what the node actually does, is making sure that you are interacting with specific object of a certain type.

What confuses me further is that Cast To is basically a branch node, which takes Actor instead of boolean as a condition to route the execution output pin, yet in branch node, execution output pins are True/False, but in case of Cast To, execution pins are [empty] and Cast Failed. This, combined with the clumsy name makes understanding of Blueprint logic really difficult for non programmers. So I hope this is something that could be improved.

Thanks

6

Ok, not sure I completely follow your train of thoughts but here is a simpler explanation (and the purists will excuse me if this is not 100% technically accurate).

Casting is simply an attempt to convert the type or class of a variable into a different type or class. If the two types or classes are somehow compatible, the casting operation will succeed. If the two types are not compatible, the casting operation will fail.

Casting is to be though of as casting in a mold, where the liquid metal (the first type or class) takes a more defined shape (the second type or class). In fact casting is often used to convert a more generic type or class into a more specific type or class.

If the casting operation is successful, the resulting cast variable can be used as it would be of the new type or class (in fact it is now of the new type or class). This is useful if you need to perform a specific task which only the new type or class can do. Or if you need to access a property which only the new type or class has.

If the casting operation fails, it means the two types or classes are not compatible and you don’t have any resulting cast variable to work with. This is like pouring the metal and breaking your mold.

In UE4 blueprint casting is often used to convert a reference to a more generic class (say a Pawn reference) into a more specialized one (say a MyPawn reference) so that you can access the variables and the specialized behavior of MyPawn. This works properly if MyPawn is derived from Pawn (meaning MyPawn is actually a more specialized version of Pawn).

The reason cast is necessary is that many Blueprint nodes do not know about your specialized classes (e.g. MyPawn) but only about the more generic classes (e.g. Pawn) and therefore carry around references only in a generic way. Once you get a generic reference, you make it specific by using a Cast To node.

I hope this makes it clearer. I know it is not easy if you are coming from the non-programming side.

Cheers,
.

7

Its like Humpty Dumpty. The engine comes in a big massive bumper bag full of nothing but a thousand or more broken busted pieces to start with… Our job is to pout out all the contents of the bag on the floor and sort through all the pieces, and start the arduous task of slowing gluing back all the pieces together to make a game so we have to be good at building jig jaw puzzles out of the pieces just like leggo bricks… The trick is knowing where each piece goes and where each piece fits in. Its not so easy when the engine has got over a thousand broken pieces in it which we call Nodes is actually BROKEN busted up bits of code modules that need to be glued all together with these Wires to keep them from falling all apart. Putting back all the pieces in the right way to create a game out of it isn’t so easy as it may look either… You have to know how all the pieces work
and where they all fit in and know all their relationships and classses one to another, and I don’t have all that programming knowledge so i struggle in trying to put my game into this engine as a result… I think You need professional jig saw puzzle experts to make a decent game with this engine.
And if you pieced it all together and its all working, just leave it alone, because any further tinkering around with it, and them off goes Humpty falling
off the wall and he breaks into a thousand pieces again, so Humpty appears to be rather fragile even with all his thousand or so of wires to try
to hold him all together.

8

In my limited, but successful experience, I use Cast To mostly to SET a variable inside of my Player Character FROM another blueprint or UMG/HUD. I will create a Variable inside of my Player Blueprint example: WhichCubeFell and make it an Integer, default at 0.

Lots of Cubes in the level, each has a variable with a set Integer (1, 2, 3, etc) … when one of the Cube Blueprint Class Actors hits the ground because of a fall… that particular Cube Blueprint does a “Cast to” my Player Blueprint and Sets the WhichCubeFell variable to what ever Number the Cube variable was that fell. Then from then on until changed, my WhichCubeFell variable is now set to what ever Cube fell, vs default as 0.

9

You shouldn’t think about what things are named but instead think about what they actually do. Casting is an established programming term and it makes sense that it’s called Cast in BP as well. It’s called the same thing in C++ so why should it be different?

BP is supposed to allow everyone to create game logic, not just non-coders, so it’s better if things are called the same way as in programming languages so you don’t have names like “variables” in C++ and “thingyholder” in BP. It will also allow you to learn programming terminology through BP so you can actually speak to programmers in terms they understand.

10

Sorry, but “You shouldn’t think about what things are named but instead think about what they actually do.” is probably the least valuable answer I could receive. If you have absolutely no programming background and are just starting to learn blueprint, then the name of the node is the ONLY indicator you get of its function. Even if you know theoretical basics, for example using ray casting to test for hits of an object, you will logically search for the term “ray cast” just to figure out later it’s actually named “line trace”.

It’s absolutely fine that there is a legacy reason why it is named casting, I just wanted to know that reason, and people above you have managed to explain it very well. But really, saying that I should not think about the naming is completely missing the point, as name, for me, is the only thing to hold on to when I am trying to figure out what the node is for, or trying to search for a node that does what I need.

My main problem was that while I understood the logic that the node performs, every time I looked at its name, I started to question if I truly understand the function of the node, despite the node working exactly as I expected it to. Here’s an analogy:

Imagine you open a new piece of software, and need to multiply just two RGB colors with each other. Logically, you would start to search for a node called “Multiply” or “RGB multiply”. After an hour of searching, you would decide to go online and seek help.

You would read that what you need to do is done by a node called “Inverse Mixer”. You would then proceed to drop “Inverse Mixer” node into your graph, and it would do exactly what you need, multiply the colors of two RGB inputs, but every time you look at the node name, it says “Inverse Mixer”. So you keep asking yourself “****, is this really the node I should be using? Doesn’t it do something more than just RGB multiply, that could have adverse effects later on?”

Confused, you would return to seek help from the internet, and after a while, someone would come up with an explanation of why RGB Multiply ended up named so ridiculously in this particular piece of software. And that’s exactly what happened here, to me, with the “Cast To” node: https://youtu.be/f7qj6uhBtOQ?t=2m17s

11

It’s still a good thing to keep in your mind because in end BP nodes don’t (necessarily) do what they say, they have programmed functionality. For example Print String doesn’t print a paper or whatever, it outputs a text on the screen and the log. The name of the node being the only indicator of its function is wrong. They have execution wires, input and/or output variables. Those are good (sometimes better) indicators of nodes functionality.

When searching for a node it doesn’t really matter what the name is, it could be CastTo or SuperHiddenBPNode123 and you could still search for it and get information. But that’s not really my point, my point is if you decide what a node does from its name you have a possibility of misinterpreting its functionality. As an example there’s the node Do N. You would think that a node like that would do something N times. But that’s not what it does, and if you happened to come across that node thinking like you are now you could screw yourself over by getting a false misconception of what the node does.

With that in mind it’s good that it’s called Cast To because you had no idea what that meant, so you had to go look it up and learn what it actually meant.

Well that wouldn’t be a problem if you didn’t think about the name too much but instead thought about its function. :stuck_out_tongue:

Except this time it’s a programming term that you happened to not know. I don’t think changing the terms of programming terms used in BP (like casting, variables, functions, children/parents and so on) just to make it “easier” (remember that recognizing something may not help at all) for beginners is a good thing. It’s better that you accept your ignorance (literal meaning) and find out what things do, either by looking in documentation/answerhub or experimenting by yourself.

12

Just to shed some light on the term “cast”.

Think of the nodes in a blueprint as the actors on a stage.

A node may be reference to an actor.
All UE knows is that this reference is an actor on the stage.

But when you cast that actor to a Hero, you are saying that actor isn’t just any actor but is also the hero of the play. He can also do hero stuff.

Casting tells UE to that the reference can also be used as a different type.

The term cast in this case means to “treat in a certain role”.

When a cast fails, then the actor failed to be cast in the new role.

e.g. Try to cast the villain as a hero, and it will fail.