most beginner tutorials use casts as they are easier to understand and are usually used in very small levels where there are only a handful of objects to interact with and the items being casted to are already in the levels so casting won't consume additional memory in such cases and won't have dozens of nested casts. As soon as you're making a game that's bigger than a few objects or if it has objects that are not present in every level, casts should be avoided to keep memory consumption low, especially if you have nested casts.
Thank you so much for this. This is the type of stuff a lot of people don't make straightforward tutorials for, and yours are quick, to the point, and easy to follow. Plus, you actually explain the stuff (again, in a way that's easy to follow) and help us understand it so we get the importance of it and aren't just mindlessly copying what's on screen the whole time. Fantastic videos. As someone who's making an immersive sim, which means you'll have a TON of different objects to interact with in different ways, this helps so much.
Thanks! i am glad you found it to be helpful :) I put a lot of effort into making my video's a tool for learning rather than just copy-pasting like many tutorials are so it's nice to have that be apricated!
This is actually really incredible. I knew about interfaces but when using them I was always just a little confused about them since tutorials don't go in depth about how they work. Now I can hopefully get some more of my ideas working better with better performance.
yeah it's tricky to wrap your head around, especially since casting is so much quicker and more straight forward, so most tutorials use that instead. While I think a lot of people go over the top to try and avoid casting, it's good to know your options!
You have finally driven home a much needed part of this for me!!! The Input of your BP_PlayerCharacter in the Interface is such a vital part I was missing. I was trying to send variables through input and output but instead you send the reference to the entire Player blueprint and THEN drag off to get the variables inside. THANK YOU!
thank you for your explanation about the blueprint interface and casting, It is the first time I understand how the interfaces work. I always had problems with casting, specifically Objects reference for casting.
it's still worth while understanding how casting works and when you should use it. but for something like the example in this video, interfaces work a lot better :)
You do an excellent job of explaining why/how things work to actually help beginners/intermediates actually learn. I'm sure we all know a lot of tutorials out there are 'do this, connect this, Call this' and we do it and whatever system we are working on works, but we dont learn anything along the way
When you create the Input as an Object Reference in the Blueprint Interface, it creates Hard Reference and it's the same like the Casting, it's still loading the Character BP the same like the Casting.
I absolutely love these videos and I can't get enough. Thank you so much. All these more complex (for beginners) topics I don't see talked ever (unless they're in a 40-video-long playlist) made so simple to make independent game development that much easier. Hats off to you man :)
Love this. Also, if you "have" to cast in some instances, it's good practice to "safe cast" on Begin Play and convert to a variable. I only do this in things like the Game Mode, much less in the Level Blueprint, and almost never in any other blueprints. I also run it with a Do Once node to make sure it only casts one time and set a variable to state that casting has been finished as there are some instances where it may need to cast again but only if the variable is false. But like I said, only in rare instances for certain scenarios within blueprints that aren't always spawning and in places (like Event Begin Play) where it runs only once based on Do Once and variable parameters.
doing a safe cast like that doesn't actually gain you too much. of course it's always better to not call any function twice if it only needs to be called once so you shouldn't stop doing it by any means but i also think you might be overestimating how much the actual execution of the casting node matters because the expensive bit of a casting node is the fact that it exists to begin with, making a hard reference to the class your casting to but just having a variable of that type on your blueprint creates a hard reference all the same. It's important for people to learn not to rely on casting as their default method of communicating between objects and classes but there is also definitely a use for it and a lot of myths and misconceptions about how to work around it.
@@thegamedevcave Good advice. Yeah, I struggled a lot with knowing when and where to use it although I saw your other video explaining this more in depth after writing this comment. I've always been more wary of casting and just have to put into practice of when it's good to do it.
1:10 - Im still learning UE but I had to fact check: this is simply not the case as far as I've figured out. Casting nodes by themselves dont load anything into memory nor store hard references to the objects/blueprints you're trying to cast to, they are just logic code. The line trace returns one object it hits, and then "casts" or "compares" that object to whatever you might need and does or doesn't do something with it after. The only things loaded into memory are the level you are in and objects inside it. Casting is okay in this case, though interfaces definitely should be used for larger scales.
you can check this in the reference viewer. adding in a casting node will create a hard reference. if it didn't you wouldn't be able to access any of the functions or variables on said class without explicitly loading the class. A casting node works like any other hard ref, and keeps the class (not object, the class) it refers to in memory for easy quick access. In a lot of cases, that is totally fine and you for sure shouldn't try to eliminate every cast ever in your project. When to use and when to avoid casting can be a rather nuanced topic that many people have very strong opinions about. But altogether, a cast creates a hard ref and a hard ref means that said class will be loaded into memory. if they didn't your program wouldn't be able to figure out what even that type of class is, as it NEEDS that class in memory to know what's up with it. having a class in memory generally isn't an issue as classes are super small but with blueprints (blueprint classes) they may also then themselves contain references to assets ( textures, models, and so on) which is where the memory footprint starts to blow up
Thanks for explaining deeper. Now, bare with me, with this extra comment my understanding now is that you're not saying the Cast node by itself is causing a memory leak, but an excessive usage of the cast node to classes that have references to memory intensive assets such as meshes, texture, etc. is the thing that can cause the memory issue? But wouldnt those classes that aren't even present in the level be unloaded by the engine itself? Surely UE isn't that bad at handling memory management?
no, because as a developer it is your job to know when assets aren't always relevant and tell unreal that by using soft references and only loading them into memory when they become relevant. What and when something needs to be a soft or hard ref will be heavily depending on a case by case basis so that's something a programmer needs to take care of (who knows, maybe in the future machines will be able to use some fancy AI to understand that context better but for now, that really is something you need a human to do who has the full context of what the project is). As a short aside, what is happening here isn't memory leakage, it's just heavy memory use. A memory leak is when objects are left in memory and never cleaned up, making for dead memory that's being used for no reason and that much unreal does take care of you for with it's garbage collection.
Most of the time, tutorials showing off something entirely unrelated don't want to bother setting up an interface because it takes more time, adds more possible confusion for a viewer and just adds a lot of stuff that is faster to solve with a cast. Where the issue comes in then is that people watching only 'how to make X feature" tutorials think that casting is the only option to communicate between objects of different classes, or even if they are aware of other methods see castings as the "default" way to do it because they just copy what they see in tutorials without thinking about what everything does. In a lot of tutorials i will also throw in casts for those reasons but I also put in a lot of effort to make videos like this to make sure people have a recourse to learn more about how things work beyond just copy pasting nodes that I place. At some point, if people don't want to learn beyond a surface level though, that's on them. btw, i also wouldn't call casting "bad" just misused and overused. the real danger in casting is, if you do it everywhere you create a cascading effect of dependencies, that is where it becomes and issue but there is plenty of scenario's where you just cast to a class which then itself doesn't do any more casts and that's fine really but those are things you have to be aware about, which thanks to a lot of tutorials indeed, a lot of people are not.
@@thegamedevcave I've also been following lots of tutorials lately, including interfaces from many different channels. Some even implement the interface in the player blueprint, some people don't. I didn't see you adding it to your player blueprint so I guess it's not needed there when just sending a call to the interact function of the interface?
@@powerpc6037 yeah you dont need to implement interfaces on the caller in blueprint, any blueprint should be able to call interface functions. Only the blueprint that has to provide code to run needs to have to implemented :)
@@timeflier350 i literally point out in this video that if you make an interface and make it return a reference you’re making a cast with extra steps which is just as bad. So if this is your take on the video, you’re just telling on yourself that you didn’t watch it buddy 😅
I got error messages, when I put my character as an input on Interface and get some values from it on my other actor class. How can I fix that? Blueprint Runtime Error: "Accessed None trying to read property K2Node_Event_character_reference_1". Node: Add Keys Graph: EventGraph Function: Execute Ubergraph BP Door Key Blueprint: BP_DoorKey
This tutorial is ssssooooo usefulllllll, I’ve always wondered how they handle hundreds or thousands of interactive items in a game but i keep using cast to cause its ez to find on tutorial
I dont understand how the withdrawal Chest got duplicated, renamed "Storage Chest" and without any work at all, operated effectively as a deposit Chest. Was there a jump-cut at that point?
Hello, thank you for your vidéo. Time 05:20, I don't have the "Coin" variable. Not found with UE 5.2, 5.3 even without context sensitive...nothing! In my BPI, I'm in First Person Character Object reference. Do you have an idea?
Apologies if this isn't clear I'm trying to wrap my head around this. If I had an in game bag (inventory) attached to my character and I had consistent consumable items the bag needs to hold- potions and temporary status buffs, I would use BPI for all of them. But if I had items that were permanent such as weapons or the first time I found and picked up my inventory bag, I would not use the same BPI I would use casting instead? Another question would be- let's say I had the potions as well as items that trigger in game cinematics that are not disposed of after use, would those use the same BPI as each other? I guess I'm trying to understand in which situation casting is ever appropriate if all interactions are the same, why not always use the BPI? Finally- with the line trace thing. Is that a replacement for the collision overlap? I haven't seen that in any tutorial but always see collision overlap. Thank you for your time to anyone who responds.
you use a BPI when you want to just send a message to the other object "do this thing" like activate an item, regardless of what the other object is. if the other object has the BPI implemented, it will then run it's own code to do what " interact item" means in it's specific case. that way your play can just send that generic message and the item object can figure out what that actually means. Casting allows you to call a very specific function on a very specific class of object. In most cases using an interface indeed is better, especially if you're setting up a modular system like an inventory. so if you're trying to get a character's HP for instance, you could set up an interface for all that, but if the performance impact of it isn't too big and it's 1 very specific type of object getting the hp from another very specific kind of object, it might just be easier to use casting. When setting up systems of code (things that will have to be modular or be able to scale up as your game grows) you'll pretty much always want to go for interfaces. Casting can come in handy for very specific situations where you're scripting our linear behavior (like say : in level 6 of your game, a very specific situation happens where one type of enemy needs to be able to execute some function of get some value from another type of enemy in your game, and that doesn't happen regularly, but instead just is a 1-off interaction in this level, in that case, creating a whole interface for just that, while not exactly bad, is also not going to improve anything so casting is fine there.) in short : when in doubt, interfaces never hurt
@@thegamedevcave thank you so much, after this I dove into your channel and found more videos about all of this, but the comment helped tremendously as well. Also your character avi for your channel reminds me of organization XIII from kingdom hearts. makes me feel right at home haha.
I keep getting a "Accessed None trying to read property K2Node_Event_[Interface Input Name]" everytime I try to get a bool variable from my player blueprint even though I set it and when I use print string I get the character value but the moment I put my bool variable i get from my interface into a branch I get this error PLEASE HELP
hard to say without seeing your node setup but that sounds like your character may not have the interface implemented? usually an error like that implies an actor variable not being assigned a value though.
Sometimes, casting is more useful than calling a BPI. This is because you cannot know in advance whether a particular actor has implemented the required interface.
if you're casting to a class you know what class it is you're casting to, and as such you will also know if that class implements an interface. but with interfaces you aren't limited to 1 class (+children). So while casting has it's uses, very often interfaces will be better to use. if you're worried about running something on a class that doesn't have the BPI implented, trying to message in that case simply won't do anything, so that's not really a problem. if for whatever reason you need to know if the actor you just tried to run your BPI function on does have it implemented or not, you can just add a bool on return , if that's false you tried to run it on something that didn't have an implementation for it. Now if you need a very specific value or execute a very specific function that only that 1 class has, of course there's very little use in making a whole interface for just that, in those cases just doing a cast is more straight forward. As well as in cases where you know a class is going to interact a lot with another class. (your player character having a cast to it's weapon for instance), there it also makes sense. You certainly dont have to replace every cast in your project with an interface, but largely, a lot of people could do with casting a bit less and using some interfaces to keep their memory footprint under control.
I don't understand why this works. Does any interface's functions just always get added to all actor types as messages? Because in code, you'll still have to check if an interface is implemented or not, so blueprints just showing all messages confuses me.
blueprint just does that for you, when you try to messege, it checks if the interface is on that actor's class, if it it, it'll run the implementation, otherwise it'll just move on
I'm very new to game dev/programming/UE, and still wet behind the ears. Is there a "functional distance" on the line trace ? Or would you be able to interact fra across the map?
with a basic interaction ssytem like this I use a line tracer. for a lien trace you give it a start and end point, so it's limited in length. if you want to make that length uper longer, or super short, you can :)
How well does this work with child blueprints using inherited functions? I'm excited to start implementing this, but right now I use a lot of Child Blueprints off of one root interactable BP
I believe if you implement the interface in a parent class all the child blueprints may also have access to it, not 100% sure though but using interfaces makes the need for a parent “interactively object” unneeded anyway
@@thegamedevcave thank you for the reply! I'm just so used to using inheritance in coding to make sure I don't have to re-type anything, I was curious to see how the two concepts interacted in Blueprints. I'm excited to start playing around with interfaces! This is the first video I saw that actually explained them in a way that clicked for me. Thank you!
I still don’t understand how your interface nor your other objects are keeping track of the variable coins. Is coins like a global variable or something? How else is everybody having access to the same variable coins?
the actor itself keeps track of the coins on a variable, the interface is just a function that makes the coin count variable on the player character change to a new value. it pretty much works the same way as if you were to cast to player character, get coins , add 1 to it and then set coins. Expect if properly implemented, it prevents any need for creating a hard reference between the classes which makes for better memory management on the performance side and more modularity in your options to code from a workflow side. So there is no global variable just the variable that exist on the player, ideally when the player touches a coin, the coin will just send a "message" to the player, telling it to run its "increase coin function" but since it's a message and not a direct function call, you can do this on any object, and if they DO have the interface, they'll run their implementation of it, but if the dont have the interface your code will ignore it and just move on. This makes it so the coin doesn't have to be aware of what a player character is, or what values and functions exist on it, all it needs to know is "hey, something touched me, i should tell it it has just picked up a coin" and then the player character's code can deal with what that actually means, AKA, updating it's coin variable
no, interfaces are kind of like event dispatchers, they just call out and if the object you're messaging it to has an implementation, it will run that code. the caller doesn't have to be aware of any classes it communicates to. of course, any parameters you may put into an interface will still create hard references.
@@thegamedevcave i hope that is the case. but looking at reference viewer it has created a hard ref. it doesn't if there is no input for player character in the interface but creates one if there is one. (like you did to get coin)
i have to assume you have another hard reference between whatever classes you're working with because the interface's whole purpose is to avoid that. both classes have references to only the interface but not each other.
@@thegamedevcave i'm stomped. the BP has literally nothing but the Event from interface. with nothing attached to It either. Obvielsy event has the ref just like you created one around 4.20
In the tutorial, "cast" is undoubtedly the most convenient form of object interaction, but in our actual projects, the abuse of "cast" will cause a great performance loss, because "cast" loads all related objects into memory. If there are many identical Actors in the world, its performance may be very slow. When making a project, use interfaces if you can. 99% of interactions can be solved with interfaces.🤔
if there are many identical actors that wont multiply your memory problems, the issue comes in when 1 blueprint (the class, not each instance) has a hard reference to another blueprint, which means all the hard referenced assets in that other blueprint get loaded. if you rely on a lot of casts, that will quickly result in loading in a bunch of assets that you're not actually using. However, the moment you have them loaded into memory, there is little difference between having 1 instances of that actor that causes problems or 100. Since it's loading assets and classes only once anyway. (unoptimized meshes and materials slowing you down with more instances will result in slowdown but that's due to rendering, not memory and unrelated to casting). so in short, if you have a cast to something that loads other assets into memory, it's not like it gets loaded in for every instance, that would make it even more terrible than it already is xd .
It drives me crazy not seeing you compile or save anything as you do these lol I have a question, is it more performant would you say to use a line trace on the characters feet to allow for an automatic interaction via interface, like stepping on a button, as opposed to using a box collision with a cast?
yeah, used to working in c++ where saving is less of a priority because when unreal decides to crash it doesn't delete all your progress XD as for compiling, there's no real reason to do that, when you run the game in editor it auto compiles all your blueprints first anyway so pressing compile and then running the game is a waste of effort XD (now if you need to add variables to a blueprint that you need to get with a cast or whatever in another blueprint, compiling does matter of course) as for your question, if you're making a button to stand on you probably want to go with the route of putting a box collision on the button (overlap) and check if the actor that overlaps is == to getPlayerCharacter. the player itself has no need to have any code regarding a button like that so you dont need to do that with line tracers and an interaction system like the one in this video.
@@thegamedevcave Ah ofcourse good point, so just creating an object reference to my pawn and checking if it's overlapping. No need for casting or line traces there then. My main priority at this time in my progress is figuring out ways of doing everything in the most simple and modular way I can come up with. Thank you :)
@@mosesgvr1456 yeah the overlap event for your button will come with a object reference to whatever actor triggers it (so that will be your player if the player steps on it, an enemy if it's an eney that steps on it, etc) you can compare it to the reference you get from GetPlayerCharacter without having to cast or anything so you dont need to make any variables that hold the reference to the player, the overlap event and GetPlayerCharacter nodes will provide those for you
@@thegamedevcave This is great, so what I did was from the 'other actor' pin in 'begin overlap' I created an == and pulled out from that 'getplayerpawn'. Then from the bool pin I put that into a branch and it works perfectly. What's odd is that nearly every tutorial or instruction I come across always always uses cast from overlaps. Maybe it's necessary because I don't know all that much yet, but I knew there might be a way without casting to achieve the same result.
@@mosesgvr1456 casting is only needed if you want to access information or events on your player that don’t exist on a generic actor. If you just want to compare them you don’t need to cast. I have a video that talks a bit more about casting in my unreal basics playlist that might be worth checking out, it’s a tricky concept to wrap your head around haha
I dont think you need the hard reference do you? Just give a send message to the character, and from the character have the event message peform the function with its variables?
random aside, but my personal solution for a system where the player is able to interact with a great deal of objects was to create a parent object and name it something like "BP_Interactable," and put some empty "On Interacted Events" and just cast whatever we hit into an Interactable and call On Interacted. ofc every interactable object you make must be a child of BP_Interactable. I'm too high to remember how to do it, but just do a blueprint function override on the On Interacted function and that way you can have your child objects be things totally different things like doors that swing open, boxes that break, priceless art which can be defaced, ect. It was a good enough solution and I wanted to share lol
that's a decent workaround but generally, using an interface does the same thing and avoids casting altogether and is more flexible. But effectively this workaround works more or less the same way! (just annoying whenever you're deep into a project and you suddenly need to have a actor that's a child to a different class but should ALSO be interactable, unless literally every actor class you make is interactable but then you run into issues with, what if i want to make a pawn that can be interactable or a character? do you make your interactable actor class from the character class? because then you have the issue that everything in your game is now a character without it needing to be, etc.)
@@thegamedevcave yup! it works fine for something like a single player puzzle game with no NPCs or AI, but isn't flexible enough for a more complex project.
@@thegamedevcave Your videos are nice to watch, but damn, nobody would ever do it like that. That's simply not how you would use interfaces even in small scale productions. Inheritance, dispatchers, interfaces all go hand in hand. There are always different approaches, but the one you describe here is impractical and ends up being a total mess once you step over a certain threshold of scale in production. The way youtubers teach topics like this is horrendous.
@@aff3nm4nn of course there is no single "catch all" method. in some cases interfaces make more sense, in some cases inheritance makes more sense. and sometimes you dont want to use either and you're better off using delegates. The issue with youtube tutorials is that they dont have production context, so just showing an example without any surrounding context is limited in how much you can truly show each usecase. All I can do is to show the options, explain what they do and what the upsides are and leave viewers to make their own decisions on what fits for them. Anyone watching tutorials and just blindly copying things over 1 to 1 isn't actually learning anything anyway, you always have to apply things to your own projects with all the context of that code you already have in that. as for your comment "nobody would ever do it like that", i assume this is referring to the example in the video showing the basic interaction system? Because I think that this is a pretty good way to do things. You could use a parent "interactableObject" class instead if you wanted to but that could very much lead to limiting yourself down the line. Again, this is very context dependent, if you know that all the objects you will every interact with can neatly fit into your actor hierarchy, it might be easier and more straight forward to do that. But there isn't any "right" or "wrong way about this without a lot of surrounding context. If you'd like to give some more details on your opinion I'm all ears though.
We have created problems for ourselves, we are solving the problem ourselves. It's just funny to watch this video. None of the (all child BP) via CAST will be loaded into memory until it is used.
That's not quite correct i'm afraid. having any hard ref to a class in your blueprint will load them in together. it doesn't dynamically load in at the moment of use, it's being kept in memory so you can use those variables without lagspikes, which is what would happen if you needed to load things in at the moment of use. This is exactly the different between soft refs and hard refs. Using casts can be totally fine if you understand how they work and what their downsides are so you know when they don't matter.
this is so much better then begin component overlap into cast that every other tutorial does
most beginner tutorials use casts as they are easier to understand and are usually used in very small levels where there are only a handful of objects to interact with and the items being casted to are already in the levels so casting won't consume additional memory in such cases and won't have dozens of nested casts.
As soon as you're making a game that's bigger than a few objects or if it has objects that are not present in every level, casts should be avoided to keep memory consumption low, especially if you have nested casts.
Thank you so much for this. This is the type of stuff a lot of people don't make straightforward tutorials for, and yours are quick, to the point, and easy to follow. Plus, you actually explain the stuff (again, in a way that's easy to follow) and help us understand it so we get the importance of it and aren't just mindlessly copying what's on screen the whole time. Fantastic videos. As someone who's making an immersive sim, which means you'll have a TON of different objects to interact with in different ways, this helps so much.
Thanks! i am glad you found it to be helpful :) I put a lot of effort into making my video's a tool for learning rather than just copy-pasting like many tutorials are so it's nice to have that be apricated!
This is actually really incredible. I knew about interfaces but when using them I was always just a little confused about them since tutorials don't go in depth about how they work. Now I can hopefully get some more of my ideas working better with better performance.
yeah it's tricky to wrap your head around, especially since casting is so much quicker and more straight forward, so most tutorials use that instead. While I think a lot of people go over the top to try and avoid casting, it's good to know your options!
This is a great explanation! Lot's of tutorials use BPI without explaining what it is exactly, this helps everything make sense! Subbed
Glad it was helpful!
You have finally driven home a much needed part of this for me!!! The Input of your BP_PlayerCharacter in the Interface is such a vital part I was missing. I was trying to send variables through input and output but instead you send the reference to the entire Player blueprint and THEN drag off to get the variables inside. THANK YOU!
Check out my video on copy vs references too, because i feel that that may be the actual issue gou were running into
thank you for your explanation about the blueprint interface and casting, It is the first time I understand how the interfaces work. I always had problems with casting, specifically Objects reference for casting.
it's still worth while understanding how casting works and when you should use it. but for something like the example in this video, interfaces work a lot better :)
You do an excellent job of explaining why/how things work to actually help beginners/intermediates actually learn. I'm sure we all know a lot of tutorials out there are 'do this, connect this, Call this' and we do it and whatever system we are working on works, but we dont learn anything along the way
i'm glad that it's appreciated! :)
When you create the Input as an Object Reference in the Blueprint Interface, it creates Hard Reference and it's the same like the Casting, it's still loading the Character BP the same like the Casting.
Yup
I absolutely love these videos and I can't get enough. Thank you so much. All these more complex (for beginners) topics I don't see talked ever (unless they're in a 40-video-long playlist) made so simple to make independent game development that much easier. Hats off to you man :)
it's also 4 am and i've been binging these videos. just found your channel an hour ago
Glad you like them!
This was a huge help! Thank you for taking the time to make it!
Love this. Also, if you "have" to cast in some instances, it's good practice to "safe cast" on Begin Play and convert to a variable. I only do this in things like the Game Mode, much less in the Level Blueprint, and almost never in any other blueprints. I also run it with a Do Once node to make sure it only casts one time and set a variable to state that casting has been finished as there are some instances where it may need to cast again but only if the variable is false. But like I said, only in rare instances for certain scenarios within blueprints that aren't always spawning and in places (like Event Begin Play) where it runs only once based on Do Once and variable parameters.
doing a safe cast like that doesn't actually gain you too much. of course it's always better to not call any function twice if it only needs to be called once so you shouldn't stop doing it by any means but i also think you might be overestimating how much the actual execution of the casting node matters because the expensive bit of a casting node is the fact that it exists to begin with, making a hard reference to the class your casting to but just having a variable of that type on your blueprint creates a hard reference all the same.
It's important for people to learn not to rely on casting as their default method of communicating between objects and classes but there is also definitely a use for it and a lot of myths and misconceptions about how to work around it.
@@thegamedevcave Good advice. Yeah, I struggled a lot with knowing when and where to use it although I saw your other video explaining this more in depth after writing this comment. I've always been more wary of casting and just have to put into practice of when it's good to do it.
this video is so underrated, It's straightforward and easy to understand and memories, thank you so much!!
Glad it was helpful!
1:10 - Im still learning UE but I had to fact check: this is simply not the case as far as I've figured out. Casting nodes by themselves dont load anything into memory nor store hard references to the objects/blueprints you're trying to cast to, they are just logic code. The line trace returns one object it hits, and then "casts" or "compares" that object to whatever you might need and does or doesn't do something with it after. The only things loaded into memory are the level you are in and objects inside it. Casting is okay in this case, though interfaces definitely should be used for larger scales.
you can check this in the reference viewer. adding in a casting node will create a hard reference. if it didn't you wouldn't be able to access any of the functions or variables on said class without explicitly loading the class. A casting node works like any other hard ref, and keeps the class (not object, the class) it refers to in memory for easy quick access.
In a lot of cases, that is totally fine and you for sure shouldn't try to eliminate every cast ever in your project. When to use and when to avoid casting can be a rather nuanced topic that many people have very strong opinions about. But altogether, a cast creates a hard ref and a hard ref means that said class will be loaded into memory. if they didn't your program wouldn't be able to figure out what even that type of class is, as it NEEDS that class in memory to know what's up with it.
having a class in memory generally isn't an issue as classes are super small but with blueprints (blueprint classes) they may also then themselves contain references to assets ( textures, models, and so on) which is where the memory footprint starts to blow up
Thanks for explaining deeper. Now, bare with me, with this extra comment my understanding now is that you're not saying the Cast node by itself is causing a memory leak, but an excessive usage of the cast node to classes that have references to memory intensive assets such as meshes, texture, etc. is the thing that can cause the memory issue? But wouldnt those classes that aren't even present in the level be unloaded by the engine itself? Surely UE isn't that bad at handling memory management?
no, because as a developer it is your job to know when assets aren't always relevant and tell unreal that by using soft references and only loading them into memory when they become relevant. What and when something needs to be a soft or hard ref will be heavily depending on a case by case basis so that's something a programmer needs to take care of (who knows, maybe in the future machines will be able to use some fancy AI to understand that context better but for now, that really is something you need a human to do who has the full context of what the project is).
As a short aside, what is happening here isn't memory leakage, it's just heavy memory use. A memory leak is when objects are left in memory and never cleaned up, making for dead memory that's being used for no reason and that much unreal does take care of you for with it's garbage collection.
Appreciate the lengthy responses clearing everything up
This was soooooo helpful, thanks for making this tutorial!
I can't stand most tutorials out there. Everybody using casting, are they not aware it's terrible due to huge memory allocation?
Most of the time, tutorials showing off something entirely unrelated don't want to bother setting up an interface because it takes more time, adds more possible confusion for a viewer and just adds a lot of stuff that is faster to solve with a cast.
Where the issue comes in then is that people watching only 'how to make X feature" tutorials think that casting is the only option to communicate between objects of different classes, or even if they are aware of other methods see castings as the "default" way to do it because they just copy what they see in tutorials without thinking about what everything does.
In a lot of tutorials i will also throw in casts for those reasons but I also put in a lot of effort to make videos like this to make sure people have a recourse to learn more about how things work beyond just copy pasting nodes that I place. At some point, if people don't want to learn beyond a surface level though, that's on them.
btw, i also wouldn't call casting "bad" just misused and overused. the real danger in casting is, if you do it everywhere you create a cascading effect of dependencies, that is where it becomes and issue but there is plenty of scenario's where you just cast to a class which then itself doesn't do any more casts and that's fine really but those are things you have to be aware about, which thanks to a lot of tutorials indeed, a lot of people are not.
@@thegamedevcave I've also been following lots of tutorials lately, including interfaces from many different channels. Some even implement the interface in the player blueprint, some people don't. I didn't see you adding it to your player blueprint so I guess it's not needed there when just sending a call to the interact function of the interface?
@@powerpc6037 yeah you dont need to implement interfaces on the caller in blueprint, any blueprint should be able to call interface functions. Only the blueprint that has to provide code to run needs to have to implemented :)
@@timeflier350 i literally point out in this video that if you make an interface and make it return a reference you’re making a cast with extra steps which is just as bad.
So if this is your take on the video, you’re just telling on yourself that you didn’t watch it buddy 😅
Very helpful tutorial. Appreciate you taking the time to make it.
Glad it was helpful!
4:11 doesnt this create an hard object reference as well which would cost performance? would you put in a Actor object reference instead?
Yes but since the player is always loaded anyway, because it is the player it doesn’t actually create any issues
I'm usually just a lurker, but this is a great video. Keep it up!
Glad you enjoyed it!
@@thegamedevcave I already knew the contents of this video, but I hope my engagement helps your channel!
I got error messages, when I put my character as an input on Interface and get some values from it on my other actor class. How can I fix that?
Blueprint Runtime Error: "Accessed None trying to read property K2Node_Event_character_reference_1". Node: Add Keys Graph: EventGraph Function: Execute Ubergraph BP Door Key Blueprint: BP_DoorKey
This tutorial is ssssooooo usefulllllll, I’ve always wondered how they handle hundreds or thousands of interactive items in a game but i keep using cast to cause its ez to find on tutorial
I dont understand how the withdrawal Chest got duplicated, renamed "Storage Chest" and without any work at all, operated effectively as a deposit Chest. Was there a jump-cut at that point?
Hello, thank you for your vidéo. Time 05:20, I don't have the "Coin" variable. Not found with UE 5.2, 5.3 even without context sensitive...nothing! In my BPI, I'm in First Person Character Object reference. Do you have an idea?
you gotta add that to the player class first. I'd recommend taking a look at my unreal basics course playlist
@@thegamedevcave Ha, There are a lot of videos! Could you tell me which one please?
Unreal Engine 101 Basics Course ?
@@RV-bc9yi ua-cam.com/play/PLoReGgpfex3x295NSo3hZD6Ylq6hPqdz8.html
@@thegamedevcave Thank you so much for this video the BPI is clearer for me now !
Apologies if this isn't clear I'm trying to wrap my head around this.
If I had an in game bag (inventory) attached to my character and I had consistent consumable items the bag needs to hold- potions and temporary status buffs, I would use BPI for all of them. But if I had items that were permanent such as weapons or the first time I found and picked up my inventory bag, I would not use the same BPI I would use casting instead?
Another question would be- let's say I had the potions as well as items that trigger in game cinematics that are not disposed of after use, would those use the same BPI as each other?
I guess I'm trying to understand in which situation casting is ever appropriate if all interactions are the same, why not always use the BPI?
Finally- with the line trace thing. Is that a replacement for the collision overlap? I haven't seen that in any tutorial but always see collision overlap.
Thank you for your time to anyone who responds.
you use a BPI when you want to just send a message to the other object "do this thing" like activate an item, regardless of what the other object is. if the other object has the BPI implemented, it will then run it's own code to do what " interact item" means in it's specific case. that way your play can just send that generic message and the item object can figure out what that actually means.
Casting allows you to call a very specific function on a very specific class of object. In most cases using an interface indeed is better, especially if you're setting up a modular system like an inventory. so if you're trying to get a character's HP for instance, you could set up an interface for all that, but if the performance impact of it isn't too big and it's 1 very specific type of object getting the hp from another very specific kind of object, it might just be easier to use casting.
When setting up systems of code (things that will have to be modular or be able to scale up as your game grows) you'll pretty much always want to go for interfaces. Casting can come in handy for very specific situations where you're scripting our linear behavior (like say : in level 6 of your game, a very specific situation happens where one type of enemy needs to be able to execute some function of get some value from another type of enemy in your game, and that doesn't happen regularly, but instead just is a 1-off interaction in this level, in that case, creating a whole interface for just that, while not exactly bad, is also not going to improve anything so casting is fine there.)
in short : when in doubt, interfaces never hurt
@@thegamedevcave thank you so much, after this I dove into your channel and found more videos about all of this, but the comment helped tremendously as well. Also your character avi for your channel reminds me of organization XIII from kingdom hearts. makes me feel right at home haha.
@@JordanGarland it is! Haha
I keep getting a "Accessed None trying to read property K2Node_Event_[Interface Input Name]" everytime I try to get a bool variable from my player blueprint even though I set it and when I use print string I get the character value but the moment I put my bool variable i get from my interface into a branch I get this error PLEASE HELP
hard to say without seeing your node setup but that sounds like your character may not have the interface implemented? usually an error like that implies an actor variable not being assigned a value though.
Sometimes, casting is more useful than calling a BPI. This is because you cannot know in advance whether a particular actor has implemented the required interface.
if you're casting to a class you know what class it is you're casting to, and as such you will also know if that class implements an interface. but with interfaces you aren't limited to 1 class (+children). So while casting has it's uses, very often interfaces will be better to use.
if you're worried about running something on a class that doesn't have the BPI implented, trying to message in that case simply won't do anything, so that's not really a problem. if for whatever reason you need to know if the actor you just tried to run your BPI function on does have it implemented or not, you can just add a bool on return , if that's false you tried to run it on something that didn't have an implementation for it.
Now if you need a very specific value or execute a very specific function that only that 1 class has, of course there's very little use in making a whole interface for just that, in those cases just doing a cast is more straight forward. As well as in cases where you know a class is going to interact a lot with another class. (your player character having a cast to it's weapon for instance), there it also makes sense. You certainly dont have to replace every cast in your project with an interface, but largely, a lot of people could do with casting a bit less and using some interfaces to keep their memory footprint under control.
I don't understand why this works. Does any interface's functions just always get added to all actor types as messages? Because in code, you'll still have to check if an interface is implemented or not, so blueprints just showing all messages confuses me.
blueprint just does that for you, when you try to messege, it checks if the interface is on that actor's class, if it it, it'll run the implementation, otherwise it'll just move on
@@thegamedevcave Dang. That's pretty cool. I'm refactoring my pickups as we speak. Dankjewel man
I'm very new to game dev/programming/UE, and still wet behind the ears.
Is there a "functional distance" on the line trace ? Or would you be able to interact fra across the map?
with a basic interaction ssytem like this I use a line tracer. for a lien trace you give it a start and end point, so it's limited in length. if you want to make that length uper longer, or super short, you can :)
@@thegamedevcave thanks man !
How well does this work with child blueprints using inherited functions? I'm excited to start implementing this, but right now I use a lot of Child Blueprints off of one root interactable BP
I believe if you implement the interface in a parent class all the child blueprints may also have access to it, not 100% sure though but using interfaces makes the need for a parent “interactively object” unneeded anyway
@@thegamedevcave thank you for the reply! I'm just so used to using inheritance in coding to make sure I don't have to re-type anything, I was curious to see how the two concepts interacted in Blueprints. I'm excited to start playing around with interfaces! This is the first video I saw that actually explained them in a way that clicked for me. Thank you!
I still don’t understand how your interface nor your other objects are keeping track of the variable coins. Is coins like a global variable or something? How else is everybody having access to the same variable coins?
the actor itself keeps track of the coins on a variable, the interface is just a function that makes the coin count variable on the player character change to a new value. it pretty much works the same way as if you were to cast to player character, get coins , add 1 to it and then set coins.
Expect if properly implemented, it prevents any need for creating a hard reference between the classes which makes for better memory management on the performance side and more modularity in your options to code from a workflow side.
So there is no global variable just the variable that exist on the player, ideally when the player touches a coin, the coin will just send a "message" to the player, telling it to run its "increase coin function" but since it's a message and not a direct function call, you can do this on any object, and if they DO have the interface, they'll run their implementation of it, but if the dont have the interface your code will ignore it and just move on. This makes it so the coin doesn't have to be aware of what a player character is, or what values and functions exist on it, all it needs to know is "hey, something touched me, i should tell it it has just picked up a coin" and then the player character's code can deal with what that actually means, AKA, updating it's coin variable
This still does create a hard referance to player tho right?
no, interfaces are kind of like event dispatchers, they just call out and if the object you're messaging it to has an implementation, it will run that code. the caller doesn't have to be aware of any classes it communicates to.
of course, any parameters you may put into an interface will still create hard references.
@@thegamedevcave i hope that is the case. but looking at reference viewer it has created a hard ref. it doesn't if there is no input for player character in the interface but creates one if there is one. (like you did to get coin)
i have to assume you have another hard reference between whatever classes you're working with because the interface's whole purpose is to avoid that. both classes have references to only the interface but not each other.
@@thegamedevcave i'm stomped. the BP has literally nothing but the Event from interface. with nothing attached to It either. Obvielsy event has the ref just like you created one around 4.20
do you have community discord by any chance?
In the tutorial, "cast" is undoubtedly the most convenient form of object interaction, but in our actual projects, the abuse of "cast" will cause a great performance loss, because "cast" loads all related objects into memory. If there are many identical Actors in the world, its performance may be very slow. When making a project, use interfaces if you can. 99% of interactions can be solved with interfaces.🤔
if there are many identical actors that wont multiply your memory problems, the issue comes in when 1 blueprint (the class, not each instance) has a hard reference to another blueprint, which means all the hard referenced assets in that other blueprint get loaded. if you rely on a lot of casts, that will quickly result in loading in a bunch of assets that you're not actually using.
However, the moment you have them loaded into memory, there is little difference between having 1 instances of that actor that causes problems or 100. Since it's loading assets and classes only once anyway. (unoptimized meshes and materials slowing you down with more instances will result in slowdown but that's due to rendering, not memory and unrelated to casting).
so in short, if you have a cast to something that loads other assets into memory, it's not like it gets loaded in for every instance, that would make it even more terrible than it already is xd .
It drives me crazy not seeing you compile or save anything as you do these lol
I have a question, is it more performant would you say to use a line trace on the characters feet to allow for an automatic interaction via interface, like stepping on a button, as opposed to using a box collision with a cast?
yeah, used to working in c++ where saving is less of a priority because when unreal decides to crash it doesn't delete all your progress XD
as for compiling, there's no real reason to do that, when you run the game in editor it auto compiles all your blueprints first anyway so pressing compile and then running the game is a waste of effort XD (now if you need to add variables to a blueprint that you need to get with a cast or whatever in another blueprint, compiling does matter of course)
as for your question, if you're making a button to stand on you probably want to go with the route of putting a box collision on the button (overlap) and check if the actor that overlaps is == to getPlayerCharacter. the player itself has no need to have any code regarding a button like that so you dont need to do that with line tracers and an interaction system like the one in this video.
@@thegamedevcave Ah ofcourse good point, so just creating an object reference to my pawn and checking if it's overlapping. No need for casting or line traces there then. My main priority at this time in my progress is figuring out ways of doing everything in the most simple and modular way I can come up with. Thank you :)
@@mosesgvr1456 yeah the overlap event for your button will come with a object reference to whatever actor triggers it (so that will be your player if the player steps on it, an enemy if it's an eney that steps on it, etc)
you can compare it to the reference you get from GetPlayerCharacter without having to cast or anything so you dont need to make any variables that hold the reference to the player, the overlap event and GetPlayerCharacter nodes will provide those for you
@@thegamedevcave This is great, so what I did was from the 'other actor' pin in 'begin overlap' I created an == and pulled out from that 'getplayerpawn'. Then from the bool pin I put that into a branch and it works perfectly. What's odd is that nearly every tutorial or instruction I come across always always uses cast from overlaps. Maybe it's necessary because I don't know all that much yet, but I knew there might be a way without casting to achieve the same result.
@@mosesgvr1456 casting is only needed if you want to access information or events on your player that don’t exist on a generic actor. If you just want to compare them you don’t need to cast. I have a video that talks a bit more about casting in my unreal basics playlist that might be worth checking out, it’s a tricky concept to wrap your head around haha
thank you, amazing explanation
I dont think you need the hard reference do you? Just give a send message to the character, and from the character have the event message peform the function with its variables?
Correct!
random aside, but my personal solution for a system where the player is able to interact with a great deal of objects was to create a parent object and name it something like "BP_Interactable," and put some empty "On Interacted Events" and just cast whatever we hit into an Interactable and call On Interacted.
ofc every interactable object you make must be a child of BP_Interactable. I'm too high to remember how to do it, but just do a blueprint function override on the On Interacted function and that way you can have your child objects be things totally different things like doors that swing open, boxes that break, priceless art which can be defaced, ect. It was a good enough solution and I wanted to share lol
that's a decent workaround but generally, using an interface does the same thing and avoids casting altogether and is more flexible.
But effectively this workaround works more or less the same way! (just annoying whenever you're deep into a project and you suddenly need to have a actor that's a child to a different class but should ALSO be interactable, unless literally every actor class you make is interactable but then you run into issues with, what if i want to make a pawn that can be interactable or a character? do you make your interactable actor class from the character class? because then you have the issue that everything in your game is now a character without it needing to be, etc.)
@@thegamedevcave yup! it works fine for something like a single player puzzle game with no NPCs or AI, but isn't flexible enough for a more complex project.
@@thegamedevcave Your videos are nice to watch, but damn, nobody would ever do it like that. That's simply not how you would use interfaces even in small scale productions. Inheritance, dispatchers, interfaces all go hand in hand. There are always different approaches, but the one you describe here is impractical and ends up being a total mess once you step over a certain threshold of scale in production. The way youtubers teach topics like this is horrendous.
@@aff3nm4nn of course there is no single "catch all" method. in some cases interfaces make more sense, in some cases inheritance makes more sense. and sometimes you dont want to use either and you're better off using delegates.
The issue with youtube tutorials is that they dont have production context, so just showing an example without any surrounding context is limited in how much you can truly show each usecase. All I can do is to show the options, explain what they do and what the upsides are and leave viewers to make their own decisions on what fits for them. Anyone watching tutorials and just blindly copying things over 1 to 1 isn't actually learning anything anyway, you always have to apply things to your own projects with all the context of that code you already have in that.
as for your comment "nobody would ever do it like that", i assume this is referring to the example in the video showing the basic interaction system? Because I think that this is a pretty good way to do things. You could use a parent "interactableObject" class instead if you wanted to but that could very much lead to limiting yourself down the line. Again, this is very context dependent, if you know that all the objects you will every interact with can neatly fit into your actor hierarchy, it might be easier and more straight forward to do that. But there isn't any "right" or "wrong way about this without a lot of surrounding context.
If you'd like to give some more details on your opinion I'm all ears though.
WOW keep up the great work still new to unreal love to learn
We have created problems for ourselves, we are solving the problem ourselves. It's just funny to watch this video. None of the (all child BP) via CAST will be loaded into memory until it is used.
That's not quite correct i'm afraid. having any hard ref to a class in your blueprint will load them in together. it doesn't dynamically load in at the moment of use, it's being kept in memory so you can use those variables without lagspikes, which is what would happen if you needed to load things in at the moment of use.
This is exactly the different between soft refs and hard refs. Using casts can be totally fine if you understand how they work and what their downsides are so you know when they don't matter.
Good stuff
Glad you enjoyed
one of the greatest videos to avoid casting ever
probably also good to check out my other video on when casting is totally ok to do to get the full picture :)
@@thegamedevcave all right
💯💯💯
This is amazing, but what about attack montages and stuff like that?
Made me sub.
welcome! :)