Hello,
Lots of YouTubers said to avoid to CAST object for performances.
Do you have some alternative? to avoid cast?
some tips to share?
Thanks in advance.
Nothing wrong with cast.
Donât fall into the youtube misinformation black hole.
You could say cast isnât a great idea if youâre casting to hundreds of things trying to figure out what just overlapped, but if youâre casting to that much stuff, you have another problem anyway.
6 Likes
I can understand that put a cast inside a loop, itâs not really good.
What i did for that itâs create a variable with a cast at the Event Begin play. And use that variable instead of the cast.
But if itâs a wrong information to avoid cast, i will use them⌠becuase i build all object by avoiding cast, but structure of them is not really good. to much code inside one classe insteaf of separate them by component and utility to avoid castingâŚ
but itâs not a big deal to make cast sometime⌠i will use them 
2 Likes
Cast is a bit like Tick. The nodes are not related, but you can bring the engine to itâs knees if you havenât put any thought into what youâre doing, thatâs all.
The main thing with cast, is it loads the asset. So, if you going through lots of casts trying to figure something out, youâre loading a lot of assets for no good reason.
But, if thereâs only your player overlapping objects, well, your player is loaded ANYWAY, so casting doesnât make any difference.
There are some times where interfaces are a more elegant method than casting, so itâs good to find out about them.
But apart from that, donât worry 
2 Likes
I donât really know what youâre doing there, but it sounds like a good place to use an interface.
You donât want to be casting and then setting variable inside other blueprints ( or calling functions ) for example. Just because thatâs not good programming. BP A shouldnât know about the inside of BP B.
So an interface is a great option there, you can give BP B instructions, or ask it for info, without knowing anything about the code inside BP B.
Once you get it nailed, you can use just a couple of calls to do most things.
But, if thereâs only your player overlapping objects, well, your player is loaded ANYWAY, so casting doesnât make any difference.
Most of the time I cast to retrieve actor on the map.
For example: I walk on block
My character, cast all block each time, to retrieve the color of the block.
If i understand what you say⌠because they are already all inside the map, itâs not a big deal to cast them to retrieve the current block on which my character step on.
Is it correct?
Yes, thatâs right. The system already has âblockâ loaded, cause theyâre in the map, so no big deal.
Again, though, good place for an interface. You can have a call, âget colorâ. And the block tells you what color it is.
Now you donât have to even know itâs a block. To you, itâs just an actor, and you can ask it something.
That way, your player doesnât know about blocks. Itâs called separation, or decoupling.
2 Likes
So an interface is a great option there, you can give BP B instructions, or ask it for info, without knowing anything about the code inside BP B.
But interface allow me to communicate only if i know the BP which who I need to communicate.
In that case, before to be able to send a message to my blueprint block. (the one the actor step on) I need first to cast the block inside the actor collision box. When i know that my actor communicate with this block, i can send a message through interface.
I have try longtime, to send interface without knowing who will receive it, and it doesnât work⌠
So in a static project, when you know all your existing actor inside the map. itâs ok
I have a dynamic project, where i build the map dynamicly, so i donât know where are the block on the map. only way for me to know where is a block is to cast the block each time my collision (overlapping) notice that a new block is inside.
So is it bad to cast all the time the block? or is it ok? Interface could work? did i miss the understanding of the interface?
Now you donât have to even know itâs a block. To you, itâs just an actor, and you can ask it something.
That way, your player doesnât know about blocks. Itâs called separation, or decoupling.
Ok i will make some search regarding that topic. I was not aware about that.
If i can send the GetColor to the actor⌠without casting, it will be good
The point is with an interface, you send the message without know the type of the other actor. Thatâs the big difference.
1 Like
If the actor implement the interface it will respond to the call.
I will try that too.
Like I say, you really donât need to worry about it now. For now, casting is really really fine
But later ( few months ), you might notice some of the logic of the blocks is in the player. And some of the logic of the player is in the blocks. Then, the way to separate them is using interfaces .
But later ( few months ), you might notice some of the logic of the blocks is in the player. And some of the logic of the player is in the blocks. Then, the way to separate them is using interfaces .
Thatâs already what i do now.
1 Like
With an example
Here i get my collision box. Retrieve the actor that I cast to a block. and i ask to the block to change the color.
Iâm in the player BP.
The color logic is inside the Block BP.
But like you see, i cast the block before calling the Change Block Color
So the player is telling he block to change?
Notice, you already know itâs a block before you make the interface call. Then itâs too late
Make it so that your player will call the interface without checking what kind of thing itâs talking to, thatâs real interfaces.
Because if it IS a block, boom, it changes colour. If itâs not a block, no problem, nothing happens.
1 Like
Pow!
See, you can tell the sky sphere to change color. It wonât because it doesnât know how, but it doesnât matterâŚ
This is how you do interaction. You can have a call like âuseâ, but it means something different to every actor. Door â open, ball â throw, sky â nothingâŚ
And like that⌠if 2 differents actors, use the same Interface and re-define the same methode⌠then it will automatically chose the methode link to the good actor.
It change a little bit my view on the general flow. I will rework my game.
Thanks for your help. I see better how to use that interface now.
1 Like
One more question regarding to all of that.
If all my actor have a common interface: getName() where i return the name of the object.
When i use the methode, i can âsimulateâ a cast with the getName()
So with a methode like :
I could say if getName()=targetName then.
Itâs correct?
Is it usefull?
Itâs an example because here i know the type of actor