Wow, finally someone explained WHY and WHERE interfaces are useful. Most tutorials they say HOW to use interfaces and Castings. Keep up this good work and do more detailed tutorials with cat as an example.
@@ReidsChannel Any chance you could do interfaces vs components? I can use them the same way for my status effect system, but not sure if there's some big advantage to either.
Man, I think I'm in love with you. Don't tell my girlfriend. Learning **why** something is good is so much better than just seeing how to do something. As a UE beginner, this channel is amazing.
"Learning *why* something is good is so much better than just seeing how to do something." This x1000. This is why I like this channel, Ryan Laley, Matt Apsland, et al. They go into how and why things work so you can understand how to best utilize it, and troubleshoot/debug when needed.
fucking dead right! I am always left wondering why from other youtubers! lol I also agree that Ryan and Matt are awesome too. Maybe you guys can do a dev collab! :)
Important note: You don't always *need* to check if the actor implements the interface before calling the implemented function. If the actor does not have that interface, there is no error and nothing happens, the game continues normally. However, in this video's example we made the projectile disappear IF something got painted, so it's a perfect example for when we *should* check that the actor implements the interface.
@@loremipsum3147 Yes, but you have to be careful because now the paintable object will destroy ANY actor that calls this interface and you might not want that. Also if you use the DestroyActor node, what happens if it wasn't an actor that called the interface? What if it was the PlayerController that called the interface? Honestly I think that the projectile destroying itself is the best choice here, because this decision to destroy itself should be made by the projectile and not the painted object. Another option would be to add an output variable to the interface function and use that to decide if the projectile should destroy itself (default "no").
@@t3hpwninat0r thank you for the explanation and yes, I agree with you destroying in the interface is generally a bad idea. Btw, about returning an output variable, if the actor did not implement the interface and we call the function, what will be the return value? (I guess it is the default no?)
As always, excellent tutorial, i permit myself to add some additional note : -> Interface have a lower cost than cast, work with interface when you can. -> Casting on the upper hierarchy will cost less. If you need a fonction un Parent, prefere cast to parent than cast to child -> If a function cast often something (like everyframe), considere caching the cast (Create a new variable, and store the cache return inside, instead of casting it every frame)
That last point, especially. In many cases, you can get away with casting using the "make it a variable" method without hardly any performance penalty.
Can you please elaborate on your point about interfaces having a lower cost than casting? What exactly is the lower cost? Do you have any info on this from an engine standpoint, or better yet, from a C++ language standpoint? I'd be very interested to know.
@@GeorgePence I think there is a myth around "performance" improvements with Interface vs Cast where as from what I have read its basically the same outside of the main reason people tell you to use Interfaces in Blueprint specifically is because when you Cast in BP it creates a HARD link to every Class you Cast to (and ever Class it Casts to) which means they are all loaded into memory. So in his example where he says people do Multiple Casts to multiple Classes every one of those classes will be loaded into memory, now if they are Parent classes it might not be too bad but if you cast to Cat & Lounge & Final Boss & etc it means all those Classes (and any Classes they Cast to) and related items such as Meshes and Particles etc are loaded into memory as soon as you Call / Cast to FirstPersonProjectile
@@shannenmr Thanks for the reply. Yes, I agree also, people throw these phrases around and it's sort of like an urban legend. Very rarely does anyone ever have any legitimate info to back it up with, so I appreciate you providing some proper details.
I'm like a year late to the party but your explanation on casting is just clearer and simple than anything there is online... You have a gift for teaching...
You see, before this video, I... was that guy that would cast and cast... and cast to as many different actors as I needed. Now I was taught that not only is there a much better way of doing things but also what I was doing before was incredibly inperformant so I thank you very much for this incredible knowledge lmfao
Thank you so much for this! I'm in the middle of an Unreal online course at the moment and it bothered the hell out of me that the tutor just plainly said "I always use interfaces, never casting" without ever going into why. Same as with your videos explaining replication, this helped me a ton! So thanks :)
Wow, DOES IMPLEMENT INTERFACE !!! I was looking at a tutorial and even if it had the interface it was still casting and I didn't understand why isn't there something more. I'm a programmer and blueprints are so easy, yet so complicated for me. In programming I would create an event system and fire that even, waiting for someone registered to do something ( works well in unity ). Thank you soooo much for this
@@ReidsChannel also am looking through your playlists . unfortunately u just have a gaint playlist of tutorials . i would highly recomment u break it up atleast into series and have separete c++ playlist . thank you good day to you sir .
Also when you cast, the blueprint has to load the casted blueprint because the code needs to know it to work (dependency), so if your blueprint casts or has (even not used) a function of another actor in the event graph the blueprint is loaded which makes it heavier. Example: I have a blueprint that is 10Mbs and i add a cast to a blueprint which is 20Mbs the blueprint depends on the second one to work so the 10Mbs become 30Mbs, so when you do many casts or just reference to another actor always watch the size tree or the references view, you can find those in the top bar while on a blueprint, I think on the view menu. The interfaces are used also for that memory optimization since you can just call functions without needing any dependency. Im not an expert so correct me if Im wrong about something, but thats what I found out, also I suggest studying soft references for variables if you need more memory control and less loading time!!
@@thelawgameplaywithcommenta2654 You should always use interfaces to get the reference of a class, example: I get the playercharacter in my code so its a Character class even if it referes to a class that inherits from it, for example the FirstPersonCharacter that is given with the template, but I want to run something in that child class not in the parent given, infact as you know if I have in my FPSCharacter a function and I get a Character class I can't obviously call that function from that, but I can call an interface call, so usually you create an interface to get the reference of the player, in that interface you create a getPlayerRef function with an output that is the actual playercharacter class like the FPSCharacter, you implement that interface in that character class and override the function to return self as the output, so when you call that function as message from the character class that you obtained like with a getPlayerCharacter or whatelse you can get with that getPlayerRef the actual reference as the class you need. Sorry if it's hard to explain, Im not english so I tried to make the best explanation possible.
@@thelawgameplaywithcommenta2654 Anyway to deal damage I suggest to run the damage function given with unreal and then handle that damage with the event anydamage or the other ones, instead of making your ones, otherwise if need more complexity you can do as you need
Excellent explanation, but I have another question, that is, why did you set Construction Script like add “Create Dynamic Material Instance” to the cat's blueprint but not do the same things it in the furniture?
Sooo clear! Thank you! Sometimes my confusion with interfaces is that the interface itself stays empty; here I understood you simply call it and blueprint it wherever you wanna implement it. Now I kinda wonder why cast at all? 😂
At 9:34. You say the Cat is derived from Pawn and therefore, different than the furniture that are derived from actor. But since, Pawn themselves are derived from Actors, how does that make a difference in terms of inheritance?
Cat -> Pawn -> Actor Furintue -> Actor Sure they both derive from actor so they are both actors but I think what Im trying to say in the video is that they are both not pawns
Nice explaination ! I have one question : what's the point of testing if an actor implement an interface prior to call a function through this interface since doing so on a actor that does not implement the interface doesn't return any error... ??
You did such a good job here that I was wondering if you could somehow do a ownership theft system like the elder scrolls? I can't seem to understand what to do to even start such a system.
Very useful info. Thank you! I've heard that Casting is more performance costly than the Interface and therefore in mid or large projects Interfaces are more preferable. Is that so in your opinion?
What about changing mouse cursor at run time when mouse over a mob. In this case we will use a function and not an event. This is more complex because you need to pass ref of the widget cursor to the interface and then when mouse over a character use this same ref to change the cursor image.
great vid. i only started learning unreal last week and great to have a better understanding on casting vs interfaces. also it seems UE 5.1 does not show the "add" dropdown within the class details to add interfaces. so i've had to do my learning in v 5.0.3. i heard this was a bug with 5.1 and will be fixed soon. is that true?
Great stuff , nice expletives I also gonna watch one mor time to implement ! How can I , instead get the color from a cubic static mach in the map , making an inventory color by widget inventory to click and apply or drag and drop? Thx 🙏😊
Thanks for the useful lesson. This same technique can also be easily applied in C++. Examining Class.cpp leads to this function, which is actually used under the hood by the DoesImplementInterface Kismet function: bool UClass::ImplementsInterface( const class UClass* SomeInterface )
Good stuff. It is funny though how you seemed to struggle just a touch with this basic stuff. At least more than you do with some pretty complex topics. I get it though. When you have an almost intuitive understanding of something, it can be hard to figure out how to explain it to someone else. It's just something you've used so much that you just know. It's like explaining why you hold a pencil a certain way. Struggle or no though, that was very clear. Thanks.
thanks man good video as always :) could u please explain how from software made their pvp system behind the scenes ? i cant get any information via google or youtube and im not sure what parts of my game need to be replicated or not :s it would be very kind! dont need an extra video but i guess many other ppl would be watching it too :)
So... I just need to get one important detail to be clear... Typically I shouldn't use casting if I'll do the same action (Or very similar) to multiple or a lot of objects. But, if it's a one time thing, or only very few objects, I can then use casting instead. Is this correct? If so.... I'm starting to think that perhaps I could still use one way casting... So after the interaction interface is fired in the paint ball, it will work as intended and send the message. But then inside whatever actor the ball has hit, I can then cast to the ball and maybe ask it an arbitrary question like "Can I paint tables?" (Which is a variable inside the ball), and based on that, if the actor hit was in fact a table, then it (Inside of the table blueprint) will not change color if the variable is false.
Its hard to put a blanket statement around when to use them vs when not to use them but generally what you said it correct. However I wouldnt make a bool inside the ball for each kind of object it can paint, that can get out of hand quite quickly. It might be ok to do if you have many different types of balls that all can paint different things though.
@@ReidsChannel Wow, thanks for the reply! Although I agree that having a boolean inside of the ball for many objects (Furniture), objectively is a bad idea, I think I was more interested in the optimization part of the coding. (Remember you said casting to all objects would be generally bad), so instead these objects (Furniture) are the ones who cast to the ball, and ask it that arbitrary bool value. You could say this example uses limited (or one way) direct referencing. This ball and furniture is a bad example for this method I just mentioned, but I strongly believe it could work in other scenarios, like perhaps player interaction (with slightly more complex implementation).
@@wolfboos I don't keeping it the way it is in the tutorial is best. Having the furniture cast the ball kind of defeats the purpose of using an interface. If you went that route, everything that you wanted to be colored would have to cast to a ball in it somewhere.
I guess I don't understand. I know the memory hogging nature of casting vs interfaces, but you never really explained when casting is a BETTER idea than to use an interface. Seems it's always better/safer to just use interfaces and not have to think about hard references. Am I missing something?
If you want to join my discord and ask some more questions about this, more specific questions, I can try to answer. Its hard to generally say when casting is better or worse. But if you give me an example I can tell you why one way is better vs the other
Wow, finally someone explained WHY and WHERE interfaces are useful. Most tutorials they say HOW to use interfaces and Castings. Keep up this good work and do more detailed tutorials with cat as an example.
lol so many comments about the cat
@@ReidsChannel Maybe they should be renamed "Catstings" :P
@@ReidsChannel Any chance you could do interfaces vs components? I can use them the same way for my status effect system, but not sure if there's some big advantage to either.
@@ReidsChannelThe cat was a nice touch to entire thing :D
Man, I think I'm in love with you. Don't tell my girlfriend.
Learning **why** something is good is so much better than just seeing how to do something.
As a UE beginner, this channel is amazing.
Knowing why things work definitely helps me retain the info.
"Learning *why* something is good is so much better than just seeing how to do something." This x1000. This is why I like this channel, Ryan Laley, Matt Apsland, et al. They go into how and why things work so you can understand how to best utilize it, and troubleshoot/debug when needed.
fucking dead right! I am always left wondering why from other youtubers! lol I also agree that Ryan and Matt are awesome too. Maybe you guys can do a dev collab! :)
This right here is why 99% of TH-cam “tutorials” are absolute garbage
The cat must be an addition to all future tutorials. It is something we didn’t know we needed.
Important note: You don't always *need* to check if the actor implements the interface before calling the implemented function. If the actor does not have that interface, there is no error and nothing happens, the game continues normally. However, in this video's example we made the projectile disappear IF something got painted, so it's a perfect example for when we *should* check that the actor implements the interface.
Nice detail, thank you!
aha! I was asking myself why he used the checking. Nice catch
btw, to avoid checking we could pass the projectile's reference as input and make the interface function destroy it I guess?
@@loremipsum3147 Yes, but you have to be careful because now the paintable object will destroy ANY actor that calls this interface and you might not want that. Also if you use the DestroyActor node, what happens if it wasn't an actor that called the interface? What if it was the PlayerController that called the interface? Honestly I think that the projectile destroying itself is the best choice here, because this decision to destroy itself should be made by the projectile and not the painted object. Another option would be to add an output variable to the interface function and use that to decide if the projectile should destroy itself (default "no").
@@t3hpwninat0r thank you for the explanation and yes, I agree with you destroying in the interface is generally a bad idea. Btw, about returning an output variable, if the actor did not implement the interface and we call the function, what will be the return value? (I guess it is the default no?)
As always, excellent tutorial, i permit myself to add some additional note :
-> Interface have a lower cost than cast, work with interface when you can.
-> Casting on the upper hierarchy will cost less. If you need a fonction un Parent, prefere cast to parent than cast to child
-> If a function cast often something (like everyframe), considere caching the cast (Create a new variable, and store the cache return inside, instead of casting it every frame)
That last point, especially. In many cases, you can get away with casting using the "make it a variable" method without hardly any performance penalty.
Can you please elaborate on your point about interfaces having a lower cost than casting? What exactly is the lower cost? Do you have any info on this from an engine standpoint, or better yet, from a C++ language standpoint? I'd be very interested to know.
@@GeorgePence I think there is a myth around "performance" improvements with Interface vs Cast where as from what I have read its basically the same outside of the main reason people tell you to use Interfaces in Blueprint specifically is because when you Cast in BP it creates a HARD link to every Class you Cast to (and ever Class it Casts to) which means they are all loaded into memory.
So in his example where he says people do Multiple Casts to multiple Classes every one of those classes will be loaded into memory, now if they are Parent classes it might not be too bad but if you cast to Cat & Lounge & Final Boss & etc it means all those Classes (and any Classes they Cast to) and related items such as Meshes and Particles etc are loaded into memory as soon as you Call / Cast to FirstPersonProjectile
@@shannenmr Thanks for the reply. Yes, I agree also, people throw these phrases around and it's sort of like an urban legend. Very rarely does anyone ever have any legitimate info to back it up with, so I appreciate you providing some proper details.
I'm like a year late to the party but your explanation on casting is just clearer and simple than anything there is online... You have a gift for teaching...
You probably have the best UE4 tutorial channel on youtube. Among the few who don't really leave any questions unanswered. Great job, subscribed :)
probably the best example for casting & interfaces...anywhere. Heck even beginning programmers in college should be sent to this video.
Cheers,
b
You see, before this video, I... was that guy that would cast and cast... and cast to as many different actors as I needed. Now I was taught that not only is there a much better way of doing things but also what I was doing before was incredibly inperformant so I thank you very much for this incredible knowledge lmfao
Thank you so much for this! I'm in the middle of an Unreal online course at the moment and it bothered the hell out of me that the tutor just plainly said "I always use interfaces, never casting" without ever going into why.
Same as with your videos explaining replication, this helped me a ton! So thanks :)
Sounds like you need to find a new online course ;)
This is the only tuutorial that i understand what the casting and interfaces are. Thank you
One of the best explanation of the topic. Clear and easy to understand. Thank you!
You are a gem. Incredibly concise and useful explanations for a newbie like me
this is honestly one of the best channels i've found. great work.
The best tutorials are 90% why and 10% how. Thank you so much, i understand so much better now.
This has been a nebulous concept for me for a long time. Thanks.
incredible video, thank you
We should change this channel's name to Prof Reids Explains! Man, This is the best thing I have every watched!
i love this type of videos ! hope u keep doing on it !
Im loving your channel man. Actually informative information not just quick how to's.
And this is what a tutorial should look like. Slow, clean, right on point, detailed and for all. You just got a sub. from me!
Most underrated video on TH-cam.
Wow, DOES IMPLEMENT INTERFACE !!! I was looking at a tutorial and even if it had the interface it was still casting and I didn't understand why isn't there something more. I'm a programmer and blueprints are so easy, yet so complicated for me. In programming I would create an event system and fire that even, waiting for someone registered to do something ( works well in unity ).
Thank you soooo much for this
👏🏾👏🏾👏🏾 this helps so much with being able to understand a lot in blueprint programming…Thank you
just perfect ! amazing big brain stuff ! . you ever going to make c++ tutorials ??
ty :) I have made a couple but no one watches lol
@@ReidsChannel please link them
@@ReidsChannel also am looking through your playlists . unfortunately u just have a gaint playlist of tutorials . i would highly recomment u break it up atleast into series and have separete c++ playlist . thank you good day to you sir .
This really is a great explanation of those two blueprint communication methods! Really enjoying your content!
Thank you so much, I was scratching my head for some hours for getting rid of castings.
Thanks again.
I love the hammer and screwdriver analogy, great video makes me wonder if you work as a teacher!
Thanks! No I don't but I do some tutoring sometimes haha
Awesome work, thanks for explaining the why as well as the how
Perfect clarity. Thank you!
Amazing video man. Really helped me understand interfaces.
From completely confused..... to now understanding when and why..... thank you!
Thank you so much! I knew interfaces existed but never really understood why or how to use them. Now it's clear.
This is an excellent demonstration with the furniture vs. the cat 👌
Also when you cast, the blueprint has to load the casted blueprint because the code needs to know it to work (dependency), so if your blueprint casts or has (even not used) a function of another actor in the event graph the blueprint is loaded which makes it heavier.
Example:
I have a blueprint that is 10Mbs and i add a cast to a blueprint which is 20Mbs the blueprint depends on the second one to work so the 10Mbs become 30Mbs, so when you do many casts or just reference to another actor always watch the size tree or the references view, you can find those in the top bar while on a blueprint, I think on the view menu.
The interfaces are used also for that memory optimization since you can just call functions without needing any dependency.
Im not an expert so correct me if Im wrong about something, but thats what I found out, also I suggest studying soft references for variables if you need more memory control and less loading time!!
Doesn't this mean that you can always cast to the player in single player games to cause damage? Or is the dependency 2 way?
@@thelawgameplaywithcommenta2654 You should always use interfaces to get the reference of a class, example: I get the playercharacter in my code so its a Character class even if it referes to a class that inherits from it, for example the FirstPersonCharacter that is given with the template, but I want to run something in that child class not in the parent given, infact as you know if I have in my FPSCharacter a function and I get a Character class I can't obviously call that function from that, but I can call an interface call, so usually you create an interface to get the reference of the player, in that interface you create a getPlayerRef function with an output that is the actual playercharacter class like the FPSCharacter, you implement that interface in that character class and override the function to return self as the output, so when you call that function as message from the character class that you obtained like with a getPlayerCharacter or whatelse you can get with that getPlayerRef the actual reference as the class you need. Sorry if it's hard to explain, Im not english so I tried to make the best explanation possible.
@@thelawgameplaywithcommenta2654 Anyway to deal damage I suggest to run the damage function given with unreal and then handle that damage with the event anydamage or the other ones, instead of making your ones, otherwise if need more complexity you can do as you need
Thank you so much. This is really helpful. Also, best quote.... "the problem is this friggin cat."
gotta choin the choir and say that this is such a fantastic explanation. Thank you!
Excellent explanation, but I have another question, that is, why did you set Construction Script like add “Create Dynamic Material Instance” to the cat's blueprint but not do the same things it in the furniture?
Very clear explanation! Definitely helped me solidify the use cases
This is the type of good tutorials
Another amazing tutorial .... Quick question - that cat - where you took it from - I need something like that for my current project :)
Sooo clear! Thank you! Sometimes my confusion with interfaces is that the interface itself stays empty; here I understood you simply call it and blueprint it wherever you wanna implement it. Now I kinda wonder why cast at all? 😂
This is an excellent explanation. Thank you.
Very good explanation.
Detailed and simple.
At 9:34. You say the Cat is derived from Pawn and therefore, different than the furniture that are derived from actor. But since, Pawn themselves are derived from Actors, how does that make a difference in terms of inheritance?
Cat -> Pawn -> Actor
Furintue -> Actor
Sure they both derive from actor so they are both actors but I think what Im trying to say in the video is that they are both not pawns
Great example and easy to understand. You are the best!
this video helped me to understand even better what interfaces are useful for. thank you a lot.
Great stuff here. Very well explained...the why is so important...great work.
Nice explaination ! I have one question : what's the point of testing if an actor implement an interface prior to call a function through this interface since doing so on a actor that does not implement the interface doesn't return any error... ??
You did such a good job here that I was wondering if you could somehow do a ownership theft system like the elder scrolls? I can't seem to understand what to do to even start such a system.
Very useful info. Thank you! I've heard that Casting is more performance costly than the Interface and therefore in mid or large projects Interfaces are more preferable. Is that so in your opinion?
What about changing mouse cursor at run time when mouse over a mob. In this case we will use a function and not an event. This is more complex because you need to pass ref of the widget cursor to the interface and then when mouse over a character use this same ref to change the cursor image.
What is the best way to avoid actually having to duplicate the code in the 2 implementations of the interface? Function libraries?
just what i was looking for 🥳
thank you very much
great vid. i only started learning unreal last week and great to have a better understanding on casting vs interfaces. also it seems UE 5.1 does not show the "add" dropdown within the class details to add interfaces. so i've had to do my learning in v 5.0.3. i heard this was a bug with 5.1 and will be fixed soon. is that true?
Awesome! Thank you!
Loving this shorter format
Great stuff , nice expletives I also gonna watch one mor time to implement ! How can I , instead get the color from a cubic static mach in the map , making an inventory color by widget inventory to click and apply or drag and drop? Thx 🙏😊
very nice listening to your voice is comforting lol
I use interfaces for most of my in game interactions. It makes it so easy
omg tyty! This was so useful :D Also it explains the way its done in Good Practice! :D
You're amazing at explaining things
Thanks for the useful lesson. This same technique can also be easily applied in C++. Examining Class.cpp leads to this function, which is actually used under the hood by the DoesImplementInterface Kismet function:
bool UClass::ImplementsInterface( const class UClass* SomeInterface )
Apprecaite your work ❤
Thanks for the tip!
I was wondering how you pass on variables via interfaces while retaining the event. So you can't have outputs, but inputs are ok.
Outputs wouldn't make sense since it's being broadcasted to potentially thousands of objects
Nice video. It would be great if you show how to change color of projectile and weapon
Excellent tutorial! Loved it. Now I know the why.
So functions are for the same class of item and interfaces are like functions but can be used across item classes?
Yes, that's one way to look at it
Good stuff. It is funny though how you seemed to struggle just a touch with this basic stuff. At least more than you do with some pretty complex topics. I get it though. When you have an almost intuitive understanding of something, it can be hard to figure out how to explain it to someone else. It's just something you've used so much that you just know. It's like explaining why you hold a pencil a certain way. Struggle or no though, that was very clear. Thanks.
Yeah, its just explaining it clearly that is a struggle haha but glad u like it
So good! Thank you!
What if you want to only colour the sofa and not the table? Now things get complicated...
very well done, i learned a lot thanks
hey thanks alot. this is truly helpful and i see my self using interfaces now.
also you should include your AI cat in future videos lol.
Oh this is gonna be good I can already tell. Dropping a comment for the algo gonna watch the rest with a notebook later on
Excellent tutorial..! Thank you! 🫡
thanks man good video as always :)
could u please explain how from software made their pvp system behind the scenes ?
i cant get any information via google or youtube and im not sure what parts of my game need to be replicated or not :s
it would be very kind! dont need an extra video but i guess many other ppl would be watching it too :)
Very very insightful...
I wish I knew this ages ago xD
I had a tower of casting code in one of my projects... dear god I don't want to remember 😳
Thank you for this perfect video.
will this work with Mesh with multiple Material elements?
UE5 looks sooooooooo much better ... thank you for getting to the point quicker than most ... also, you gave me an idea for a mini-game :P
Best tutorials Ever ❤
Finally something that makes sense.
Nice tutorial, thank you!
very useful! thank you for the tutorial😄
So... I just need to get one important detail to be clear...
Typically I shouldn't use casting if I'll do the same action (Or very similar) to multiple or a lot of objects.
But, if it's a one time thing, or only very few objects, I can then use casting instead.
Is this correct?
If so.... I'm starting to think that perhaps I could still use one way casting...
So after the interaction interface is fired in the paint ball, it will work as intended and send the message.
But then inside whatever actor the ball has hit, I can then cast to the ball and maybe ask it an arbitrary question like "Can I paint tables?" (Which is a variable inside the ball),
and based on that, if the actor hit was in fact a table, then it (Inside of the table blueprint) will not change color if the variable is false.
Its hard to put a blanket statement around when to use them vs when not to use them but generally what you said it correct. However I wouldnt make a bool inside the ball for each kind of object it can paint, that can get out of hand quite quickly. It might be ok to do if you have many different types of balls that all can paint different things though.
@@ReidsChannel Wow, thanks for the reply!
Although I agree that having a boolean inside of the ball for many objects (Furniture), objectively is a bad idea, I think I was more interested in the optimization part of the coding. (Remember you said casting to all objects would be generally bad), so instead these objects (Furniture) are the ones who cast to the ball, and ask it that arbitrary bool value.
You could say this example uses limited (or one way) direct referencing.
This ball and furniture is a bad example for this method I just mentioned, but I strongly believe it could work in other scenarios, like perhaps player interaction (with slightly more complex implementation).
@@wolfboos I don't keeping it the way it is in the tutorial is best. Having the furniture cast the ball kind of defeats the purpose of using an interface. If you went that route, everything that you wanted to be colored would have to cast to a ball in it somewhere.
thank you so much
Great Video, and I assume this is UE5 it looks great.
I understand now the difference, thank you. But you did not explain why not always use Interface even if casting is possible?
Wait did you say “cat-sting”?
I see what you did there
I guess I don't understand. I know the memory hogging nature of casting vs interfaces, but you never really explained when casting is a BETTER idea than to use an interface. Seems it's always better/safer to just use interfaces and not have to think about hard references. Am I missing something?
If you want to join my discord and ask some more questions about this, more specific questions, I can try to answer. Its hard to generally say when casting is better or worse. But if you give me an example I can tell you why one way is better vs the other
Really cool, thank you =]
Interface promote loose coupling. Great tool
Interfaces 10:52
This was amazing!!
Best tut on this
supersnacky example. that WOW! effect, when projectile paint something first time. is that easy! supernice. thx
great lesson, thanks
Damn, this is a great tutorial.
Awesome!
Wow!