[Noob Question] What is 'Cast to'

So i can’t get my mind on exactly what is a ‘Cast to’ in blueprints… I mean what is it for? What does it do exactly…

Also i have an example here where someone placed a Cast to node, but even if i remove the node it works fine… Can you tell me about that too?
Images -

Please use really simple words
I’m really thankful to you

It is related to the concept of inheritance in Object Oriented Programming. Blueprints also support inheritance. Ie You can create a new blueprint based on an existing Blueprint class and add additional functionality to it. We also have Blueprint interfaces. Now the CastTo node is used to convert a Blueprint instance into a particular Blueprint class in its inheritance hierarchy.

For instance, imagine that you create a new Blueprint class called ‘MyActor’ based on the Actor blueprint. Later you create a new Blueprint class based on your ‘MyActor’ and name it ‘CustomActor’. So the inheritance hierarchy would look like:

Actor -> MyActor -> CusatomActor

Now suppose you make an instance CustomActor and place it in your level. You also put some other actor in the level called ‘BombActor’. Now you want to explode your BombActor whenver an instance of CustomActor touches it. BUT you do not want anything to happen if any other Actor touches the Bomb. So to implement that you would edit the Bomb’s blueprint and add an event ‘BeginTouch’.

As you probably know, the BeginTouch will give the instance of the Actor who touched the Bomb. But how do you know if the Actor that touched the Bomb is an instance of ‘CustomActor’. This is where CastTo node comes in handy. All you have to do is to attempt to convert the BeginTouches’s output Actor into CustomActor using the CastTo node. If the action succeeds, then the Actor that touched your Bomb was an instance of CustomActor and you can explode the bomb. If the cast failed, then it was not an instance of CustomActor and you can leave the Bomb as is.

Another reason to use castTo is if you have defined some new function in your CustomActor and want to call it in a situation like above. Since that function is not available in the Actor blueprint, if you attempt to call that function on an instance of Actor, it wont work. Again you will need to use CastTo node to convert the Actor into an instance of CustomActor.

This may help or confuse but anyway here goes…

  1. As was said above by mindfane OOP / Inheritance in general requires use of Casting etc…
  2. But casts are also used in Programming Languages that implement Strict-Type-Checking.

Chocolate Factory Example:
Think of a Cast as a kind of real-world Conversion from something into something else…
You receive industrial sized choc bars at the plant, but have to melt them first to pour.
After heating the melted chocolate can be poured into a Cast of chocolate Doggies etc.
Its still choccy, but now you’ve ‘Cast the chocolate’ from solid bars into edible Doggies.
So the melting / converting is like a type of Casting. Casts have a long history in coding.

Returning to Game Dev:
Casting involves converting between different data-types, imagine Float to an Integer.
A Float of 5.8 can become an Integer of 5 or 6 depending on what way its converted.
Casting is the act that prepares Float to be passed to a Function that expects an Int.

Back to dogs: Imagine you have a game object called Parent-Doggy and a second game object Puppy.
The parent might have an ability Carry-Puppy that Puppy doesn’t have as it can’t ever carry a Parent.
Cast-To lets you check if you’ve a Puppy or a Parent object so you know if CarryPuppy is allowed etc.

blueprint communication with other “things” (actors, blueprints and so on).

you need to “cast” them to be able to receive details from the specific casted thing OR *tell *it what to do.

no idea what those other guys are talking about. :stuck_out_tongue:

Casting is a tool to specify the actual type you are working with.
Take the “BeginOverlap” Event within Actors for example. Although you only have “Other Actor” as a Parameter, you can distinguish what you overlapped with - with Casting.

In the example you’ve got the SpawnActor thing already outputs a BP_FloorTile reference, you can see that by the GetAttachTransform node says “Target is BP Floor Tile”. This should give a warning when compiling with the cast node saying something like you don’t need to cast.

But in general when casting you go from something general to something more specific, so if you create an actor MySpecialActor with a variable in it, only that type of actor will have that variable, so you will need to cast to it in order to access its variables and functions.

Wow… I use cast to… and Im even more confused then before reading all these posts… Maybe im using them wrong - most likely? This was my concept - My First Person Character has a variable named “Damage” If the damage = 100 then I die. It defaults at 0. I have several ‘bombs’ in the level all valued at different levels of damage. Some are 10, some are 25, etc. As my character interacts with EACH of these individual Bombs, I can Cast to my Character and ADD the value of the Damage from that particular Bomb to the Variable “Damage” in my character. In other words Cast to FPS, Set “Damage” to damage + bombDamage. I am setting a variable in another blueprint from the bomb blueprint. Is this not correct?

It is correct. You used the CastTo to convert an Actor into an instance of FPS Character. That is why you could access the damage variable. If you did not cast, then you wouldn’t be able to access the variable Damage.

Man, these explains are batshit insane. Mine is probably too.

Look at it this way:
The blueprint system does not inherently know what a thing that you are interacting with is.
For example, imagine you want to access a variable on your player character from another blueprint. Let’s say that variable is “health” and you want to edit the health directly via “set health”.
Your player character is an actor, as it inherits from the actor class. So you make a variable of type “actor” and that variable contains a reference to your character.
You use the “get” node on that reference, pull from the node and search for the “set health” node. It’s not there.
You have two options to fix that:

  1. You make your variable of type “player character” instead. This makes it impossible to have the variable later reference to anything that isn’t either “player character” or something that inherits from it.
  2. You drag from the “get” node, use “cast to player character” and then drag from there to get your “set health”. What this does is that the program will, once the game is running and this instruction gets called, check if the variable really contains a reference to “player character”. If it doesn’t, the cast fails and nothing happens. If it does, the instruction is executed.
    If the casting system didn’t exist and you tried to “set health” on something that later turns out to not be a player character, you’d crash the engine.

Basically, the “cast to” node is supposed to tell the system explicitly what type of object you want to interact with and to make sure that only valid operations are executed. It’s a safety feature.

You are right in a sense. But the real reason for ‘Cast’ is tightly related to ‘Inheritance’ in OOP. Any language that supports OOP (C++, Java, C#, PHP…) has some way for casting an object to an instance of another class in its inheritance hierarchy. Casting is not a feature exclusive to Blueprints.

Anyone who is interested in knowing more might find these links useful:

Casting in UE4
Inheritance and up/down casting in C++ (bit technical)

Up-casting is transparent in Blueprints. But for down-casting you will need the CastTo node.

Cheers for sharing… It encourages everyone to think of Casting in simpler terms:
Such as navigating a tree structure, or walking up & down a ladder of a hierarchy…

I only flew over it, but it doesn’t cover that you can’t downcast if the actual type is higher in the hierarchy.
Many newbies simply cast An Actor to something although it is just an actor and not a specialized actor or simply cast a reference to a sibling branch, which is not allowed.

Animal animal = new Animal();
Animal dog = new Dog();
Animal cat = new Cat();

//DOES NOT work:

((Cat)animal).meow(); //Casting down not allowed.
((Cat)dog).meow(); //Not allowed, since a Dog can't be a cat
((Dog)cat).bark(); //the same the other way.