I’m always thinking of keeping things as minimal as possible. The Cast To sounds heavy, if attached to an event such as on tick / timer / service that it might slow things down. So my question is, what does the Cast To have to do ?
In an AI character I have tried an idea, which is basically to create a Cast To with the Construction Script to a variable rather than fire it off every time I need to cast to something. But as clearly I have no idea what it actually does this might not even be a relevant idea.
To understand what Casting does in UE4 you must first understand what ‘Class Inheritance’ is in programming.
Example: you can cast your character blueprint to Character class and it will be valid… You can cast your Character to Pawn, cast Pawn to Actor and almost anything to UObject; but you can’t cast an Actor to Pawn or Pawn to Character, it will fail unless target is actually a Child Class of your casting type.
Once you understand why is that, you’ll understand what ‘Cast To’ is doing.
That is related to pointers (or references) and object oriented programming.
You ask unreal what is pointer to something (when you connect something to blue target pin), in case of picture to Widget User Object, so it gives you address in memory. But that address in memory, can be address of anything, sound actor, texture, material. Well there is basic class checking, and in some cases unreal suggest you that casting is not needed.
As it can be really anything blueprints have no idea what to do with it. So you need tell rest of graph what type of data it is.
And that is casting. It changes that data from something unknown to data that has variables and function you declared inside that class. Its like telling blueprint system what type of data layout it should use.
Ps. I think cast to is not that heavy operation, such stuff is used all over C++ code, in blueprints should not be that much slower.
PPs. Casting in Construction script may be bad idea for totally different reasons: not everything is ready and loaded into memory when construction script is called. You may get weird errors (or just access none error). So its safer to get pointers and cast to in “Begin play event”, but then if something is destroyed and you call it, well unreal is quite good at handling those pointers.
As there can be more or less abstract concepts in real life, there can be aswell more or less abstract classes in BPs. As example, “Table” is a more abstract concept than “crappy table” wich is more abstract than “Crappy 30year-old 2x2m blue table with a two damaged legs”. The more concepts get close to reality, the less they are considered abstract.
Casting means chacking whether an instance of “highly-abstract” class (such as the userwidget) can be classified as a “lowerly-abstract” one (such as the more specifical info widget).
Q1:
The “Cast To” node tries to take an object of some type and convert it into an object of another type. As others have said above, this is related to object inheritance. Let’s say you have a base class blueprint called “Fruit”. From this base class, you derive other blueprints, such as “Apple” and “Orange”. Let’s say that for apples, you have a property or method which is unique to only apples, such as “make apple juice”. You have another function for oranges, lets say, “Extract Citric Acid”. Lets say that you’ve instanced a bunch of apples and oranges and have stored them into an array of fruits. Each instanced apple and orange is stored within the array as a fruit and only treated as a fruit. If you wanted to make apple juice with all of the apples in this list of fruits, you’d have to create a loop which iterates through each fruit, figure out which fruits are apples, and then call the “Make Applejuice” function on them. The “Make Applejuice” function is exclusive to the apple blueprints only, so in order to call it, you can only call it on apples (not fruits). Within a for loop, you’d use the “Cast To” node to attempt to cast each fruit to an apple. The “Cast To” node has a “fail” execution pin and a “success” execution pin. If the particular fruit was an apple, the “success” execution pin will be followed. If it was not actually an apple, the “cast failed” pin will be run. On successful casts, the node will have an output object which is an apple, which you can then call “Make Applejuice” on. Notice that both apples and oranges inherit from the fruit class, and the fruit class probably inherits from the actor class. You never have to cast upwards, you automatically get all of the properties and methods of all classes your apples and oranges inherit from. But you do have to cast if you’re trying to work with objects down the inheritance tree.
Q2:
What about performance? Casting does come with a very slight performance hit. in 99% of the cases, you won’t really notice it so you don’t need to worry too often. Just try to avoid doing it to a ton of objects every frame. If you do cast a ton of objects every frame, look into re-architecting your solution.
In your case what it does is to check that the UserWidget in the input node actually is an InfoWidget or not.
If yes, the node will make the graph continue with its success exec output and the node will output an infowidget.
If not, it’ll just continue with its cast failed exec output and will not output any infowidget. If you try using it when the cast fails, you’ll get an “accessed none” error, meaning that you tried using something that didn’t exist.
When I was a pretty noob, i’d have probably said this:
"Ok, but I knew I had an infowidget and not a generic userwidget there! "
-True, but the programming is made to be executed by the computer, the computer, not you, has to know about it.
I hope I was clear enough. What didn’t you understand of what I posted before?
