Whenever someone uses the word "never" in a video like this, often times they don't understand what they're talking about. This is a perfect example of how beginner Unreal devs hear "casting bad" and just make whole courses on how to avoid it. If you avoid casting you will end up creating complex solutions for absolutely no reason and make your code really hard to debug. Epic put casting into the engine for a reason. If it was never to be used it wouldn't be a feature in the first place. Casting is NOT bad, you just need to understand where and how to use it. If an object is loaded into memory already, casting is essentially free and preferred over interfaces. It will not cause any performance issues in this case and its faster. This includes things like the player character, the Game Instance and often your HUD as well. There's no reason to avoid casting to these classes because they exist in memory by the time the cast is performed. This is only an issue if you're casting to an object that isn't needed all the time like if you cast FROM your player to an object in the world that is only in one section of your level. That will load it into memory even when its not needed. I hope this helps someone before they pay for a course that will steer them in the wrong direction and take bad advice.
You are saying that I don't know what I'm talking about, without knowing how much experience I have and what I've achieved in game development ( that says it all ). Another thing, Epic put casting for a reason, yes, and that reason is: "To quickly test an idea and prototype, but to optimize the Blueprints you have to do the heavy lifting yourself, Epic won't do it for you". These words are from an Epic Games stuff, I've learned from one of their gamedev talks. My words: Casting is for lazy people and for people who want quick and easy fix and not taking care for their precious code and not bothering for the long term performance consequences. You my friend keep Casting in your games, but please don't post misinformation based on your own opinion and preferences, because there are new and aspiring game developers who needs to know how to properly program their game. Have a great day
@@chankulovski I mean i made a platformer and there are like 200 cast nodes inside my ui, obstacles and enemies, they all cast to the player character and the performance is fine even on old smartphones like redmi note 7 it's 12-15 ms, so if i want to save myself hours and make the code more readable i use cast. Ofc sometimes interfaces or soft references are the better choice but i know what i'm doing so - sometimes
His point is to teach optimization so he’s making a point that using casts can hurt that… I think it’s fine to give that description to teach an idea. He is making a point… he didn’t say your stuff is going to blow up.
@@IstyManame thats fine… I didn’t watch the video coming away thinking I would never ever ever use a cast… i saw it for what it was - a proper warning about the use for cast and the cost of that use - thats all… every tool has a place. If the goal was pure optimization then removing as many un-needed casts is the message.. if you guys want to take everything as a literal absolute then you will have this issue of thinking. 💭 to each their own.
@@virtualalphastudios6149 indeed, but you'd be very hard pressed to find a game that doesnt use it. The runtime cost of casting used properly is absolutely miniscule, and the engine casts countless times a frame regardless of what you do.
You do know Unreal interfaces perform a C++ style cast under the hood and it's all just basically fancy reflection? You are NOT avoiding casting with it. The big difference is that it doesn't hold on to the object in memory. And if you know about it, how come it's not touched on? that's useful information. As for Interfaces as a tool they have a place in programming and as a principle it's not meant to replace casting. They allow you to think about solutions in a sort of "Multiple Inheritance" kind of way. It just so happens a lot of time that looks like replacing Casting. I understand you coming from a place of wanting to counterbalance bad practice. Which is good. But you can't do that with misinformation and expect people to listen. Misinformation here being to NEVER use cast.
When chosing wherther to use casting or interfaces context absolutely matters there is nothing wrong with casting to the game instance for example as it will be loaded into memory regardless if you have a hard refrance to it (Cast) casting wouldent be good if for example your casting to a car that your player can spawn later in the game in that case its best to use a interface (A interface that dosent create a hard ref) in conjunction with a soft class ref which you can later load when the car needs to be spawned
Every time when I see someone is so convinced about Casting with the saying "There is nothing wrong with the Cast", I immediately stop replying because it's useless explaining anymore, so ... feel free to use Casting in your games, that's your choice.
@chankulovski Im not saying casting is the best solution I'm saying in very specfic senerios casting is a acceptable solution like the game instance example the game instance will be in memory regardless of whether you cast to it. But in your example in the video I myself wouldent use casting because what if there are multiple character BP that's need to interact with that then you have a problem with casting.
Would really like to see you actually demonstrate this performance loss with casting with Unreal Insights. If we're never supposed to use it, that should be pretty easy, no? Otherwise your arguments in this entire comment section are just "trust me bro".
In order to fully demonstrate the damage of the Casting nodes, you need to create a whole game, it doesn't need to be AAA or something, but something playable for around 20mins approx. Then you will see how the game will crash many times. The Casting in your code will overload your RAM memory, so if you have a small game of 10-20mins playable something, you will need a GPU 1080 or 2060 if you want your game to be smooth. I've been doing games with Casting and I had terrible experience for a whole year when I was starting, so I'm passing this knowledge to prevent beginners do the same mistake and frustration like I did, so they won't lose 1 year in vain like me. I've demonstrated in the video how the memory is bumping up with Castings, and in the Casting Node it's written as well, so I didn't invent this, I've learned it and experienced it the hard way...
@@chankulovski I mean this comment just tells us everything we need to know. You had problems with casting "when you started" so you were just using it wrong. And now you're spreading misinformation because of the experience you had when you first started. If casting is causing your project to run out of memory then you're the one using casting wrong and that's totally your fault. It's not something everyone should avoid at all times. You used it improperly, you still don't really understand it, and you're telling other people stuff that is going to derail their projects because of bad advice. Like others have said, casting is totally fine to use if you use it properly.
@@fray989 I don't think the author know much about class hierarchy. Casting is actually important and practically free if the thing you're casting to is already loaded.
@chankulovski You can tell who is inexperienced in the comments, don't waste your time typing to these kids lol, also unreal did a talk detailing this exact issue, maybe read up or watch some vids from the creators of unreal.
Yeah...In this case not casting to the player controller is not really necesary, especially since when ever you start the level it automatically possess the pawn that is assigned in the game mode. So it would be redundant to "reload" the controller using cast. I think that all is missing to the explaination could be that the engine always spawns a controller, doesnt matter which one is it and it is always created when playing the game, so the reference always exists. In that case casting is not necesary and would definitely be redundant, allowing for the solution you are using to be the best practice. But in other cases where the BP is not spawned by the engine on its own, casting is a great solution as long as you are not destroying the reference and / or have anything else dependant on that BP.
Friends, please understand... casting is NEVER GOOD SOLUTION. You should use Blueprint Interface instead. People are making thousands of excuses just to convince themselves that Casting is ok, IT'S NOT. Casting is used for quickly test an idea and prototype, to see things how they work and what they do, nothing else. Creating a whole game with Casting all around the Blueprints will ruin the game performance and there are high chances of crashing. But at the end of the day, everyone can use Blueprints as they like. My job is to teach people what is good, and what is not good with Blueprints to the best of my knowledge. Thanks for your feedback.
@@chankulovski tbh I am not really against the "not using cast", I agree with you that it is "better" to not be used, I think that this example might not have been the best to show it since the work around is "simple", and also I agree that a lot of tutorials show it that way, so this is really helpful for beginners. It would be best to showcase it against other implementations just like the one you mention which are the interfaces, and / or soft / hard references from one BP to another and compare and contrast, more of a "real world case". Either way, good video.
@@chankulovski this is retarded. Casting is fine. Bad casting isn't. Saying casting is "NEVER GOOD SOLUTION" and then in another comment saying it's just to get views is intellectually dishonest. Either you're lying or you're clueless as to what you're actually talking about.
Bold statement in the video titel. But the video don't really cover the topic or properly show what to replace it with. (No need to defend yourself in the comments, try to take in peoples feedback and grow for your next video. Best of luck!)
Hi there, thanks for your feedback. I am not defending myself, I''m just allergic to toxic comments. As well, the person wrote completely irrelevant comment about C++ and whatnot, and that was misleading to other people. I just want to help the community to learn how to properly use Blueprints and why some nodes are not good for their games. I've replied in such manner because I'm trying to protect the aspiring developers and beginners of reading these type of nonsense. Regarding bold statement, I'm explaining in the video why you should never use Casting, that means everytime when you are using Casting you are loading and referencing the Casting Class and therefore it's loading up unnecessary files and assets that Class contains. I'm here for the community, not to get rich or something :) In the video I'm not showing what to replace the Casting with, is because I have a complete Course on Udemy and I'm teaching the students all of this in depth. Kindly check it out, you might find it useful. Thanks for your comment and feedback, I appreciate it.
@@chankulovski Saying you do this for the community and not to get rich, but then directly advertising your course in the next sentence is wild. If it was "just for the community" you could've just explained all that in a youtube video.
@@crspybtw Advertising a course of A$10 will not make me rich at all. People want to learn as soon as they can and the Course is alreary published with lots of information to help many people. Of course I will post another Tutorial on UA-cam according to user's feedback. This was just 1 video and I didn't know the interest is going to be this high. Edit: This video is from the Course on Udemy.
@@chankulovski i apology on behalf of toxics reactions cause it realy look like ur not that bad and the course is not the problem even with the way u did it like the guy said previously, the reason why u get that much toxicity is cause ur not the first doing that and this look even worst, and its sad cause it seem like u understood enough but we can't aknowledge it with this amount of information u give, and i personaly think u know how it work but u dont have the correct word and u are indeed using those given in bad video, and despite me thinking i understand it enought i think u could learn me something cause i can still perfect my own understanding for sure
@@edgardsimon983 I am making more Tutorials with further explanations. I cannot put every information in one video because the video would last 2h minimum. I've put the most important information to wake up the developers/designers who believe that there's nothing wrong with the Casting. EVERYTHING IS WRONG WITH THE CASTING, so it's up to them to decide whether they will optimize their code and put up that extra work that's needed, or they will stay in their comfort zone and keep lying to themselves that Casting is great...
Out of curiosity, iv been using casting for any interactive elements. So i have ledges that can be grabbed which hold all of the logic when the user has grabbed them. Same with vents, switches for doors etc. How can you get the player and the interactive elements to speak to each other without casting?
You can use "Actor has Tag", or "Component has Tag", or Blueprint Interface. There are many other alternatives than Casting, depends how's your Blueprint setup. But definitely ditch the Casting, for the sake of your game's performance please.
@chankulovski So if the player pawn line traces to an actor which then will perform functionality based on the player characters variables, how can that be achieved without casting?
@@Jack-yk3nl Break the Out Hit, from Hit Actor create Interface with a name Interact, and connect the Hit Actor with the Target in the Interact Interface. Add the Interact Interface in the Actor you want to do interact with, and when you implement the Interface you can interact with this Actor. This is a bit more work ( that's why nobody wants to go through this setup, so instead they are using Casting cuz it's easy ), but once it's done properly, you can be sure that this setup will not kill your game.
casting node doesn't communicate with ur other bp, it convert the output pin for the actor to you to be able to read is specific property, there is no such a thing as communicating between thing, U GET AND CONVERT SOMETHING, it took me month to find finnaly a guy capable of saying me this simple specific thing.
@@mikoajtarkowski4083 I have the whole course on Udemy explaining everything in details, because these things needs to be properly explained and you can't do it in 2mins like the videos with Casting. Check the link in the description for the Course, you should find it very useful.
@@mikoajtarkowski4083 You can call an interface function on any object. You can pass it in via a function, an overlap, an apply damage, exposed variable (though a soft reference is a better option). If the object implements the interface then it is called, if not it just fails and continues on with further blueprints.
My question is, for this case, if the player is already loaded into memory, does it "copy" all the player content into each one of the actors that cast it? Or just call the already loaded content in memory? In your example, if you create 100 actors waiting to cast the player you can have 3GB of memory just for this casting process, that doesn't sound real to me. It makes more sense if you cast 100 actors against another 100 actors that force to put all the actors in memory and then that is a case when is not recommended and can cause terrible problems. If someone know how this work exactly. Thanks
If you have 100 actors with Cast, you will not have 100x the memory size ( I checked and I was wrong about that and I apologize for the mistake ). But the problem remains the same, if you have 100 Actors in your game and you have a Cast inside, everytime when you Cast you will load that memory into the system everytime and that will strain your computer and it will cause to crash. And at the end of the day, Casting is still bad and you should not use it, period :)
Casting issue is just creating hard reference to other assets, so even if the code is not called , just loading the first actor that has the casting node will load the class it cast to to memory with it even if you didn't call the function yet But if that actor is already loaded then the cast won't hurt your memory or anything@@chankulovski
@@arrowsdev It's always the best practice to simply not use it at all. Imagine you are shooting a Projectiles fo example. You are spawning the Projectiles and every time when you spawn them, that loads up the memory and it's straining the system.Thanks for your feedback.
What about casting in AI Taks/Services/Decorators? As far as I know casting there is most reliable way of working, because otherwise you will need to find a shit tone workarounds for each of these entities, and btw even official UE tutorials show that you should work with casting for AI
It's like Epic games staff once said: "Epic made the engine for us and there are nodes to help you quickly test an idea and prototype something real quick ( casting, tick, delay etc ), but doing the proper way is your job and you should do it, Epic won't do it for you". That's why people are trying to convince me ( and themselves :))) that Casting is good, IT'S NOT. I know that therr is a lot of workaround like you've said, but that's the proper way of programming with Blueprints. It's not most reliable using Cast, it's the easiest and fastest way, yes, but with bad consequences. I wasn't working much with AI Tasks but the problem remains the same, if you Cast you are increasing the chances your game to crash and behave weird.
@@chankulovski I can agree to some degree, but than again, Epics have sample projects (Lyra for example), where they demonstrate not "prototypish" solutions, but solutions that they use themself in production of their projects (Fortnite), and these best practices also use casting when its best to be used
@@UELearning-bc7uu Epic also is using Casting for Animation Blueprint in the Default Templates, that doesn't mean we should not make it better. At the end of the day, it's all a matter of preferences, if you want the quick way with a possibility your game to behave unexpectedly, or the long way with a proper polished Blueprints for smoother gameplay experience. First time I hear Fortnite is using Casting, but even if they do, they are Casting to a C++ classes. When you use Casting in C++ classes, I've heard that the performance might not be that much affected. But my Courses are for Blueprints and Casting from Blueprint to Blueprint. ( I'm making another Tutorial as we speak, to demonstrate my point even further ), stay tuned. Thanks for your feedback, I appreciate sharing your thoughts.
@@UELearning-bc7uu This dude is absolutely off his tree. Unreal Engine is a very large ecosystem to wrap your head around. Epic Games has made Lyra as a living project that follow their recommended standards. Who do you follow? The people who build this engine or some UA-camr spewing really bad advice.
@@fragileglass9622 I follow Epic staff and their Gamedev talks and GDC events. Hover over the Casting node and read what it says. I bet you've never read any documentation or whatsoever. Keep it up
Great video - thanks! - However lets say we are interacting with an actor that implements an interface - I have to cast it to a type of that interface to be able to call the methods defined on that interface! - how would I do this without casting? - seems the implementation of casts in blueprints is badly implemented!
Hey there, thanks for your comment! Try watching this Tutorial, hopefully it's what you are looking for: ua-cam.com/video/DmpRbWwJCzY/v-deo.html&ab_channel=Chankulovski If not, try to check my other Tutorials. Casting node is bad for your final game, and it's made for quick prototype and testing, there is almost always a way around it! :)
@@cmulder007 Always! :) Let me know if this was what you were looking for, if not, I will try to explain in a comment, or make a Tutorial for it. Thanks again
That is also a great video... however in that example you are able to avoid casting because you know the object that you are going to be calling the function on is the player character (you check this with ==) and then you call GetPlayerCharacter ...... however in a more generic system where you want to check against ANY object that implements the interface, like for instance I_CanBeClicked.... and if the object does implement it you want to then call the ClickMe function defined on that interface, you still need a reference to the object as that interface.... hope that makes sense... I know there is a node to check if an object implements an interface but that just returns a boolean, I cannot find a way of calling the function on an abstracted object reference without a cast... however I guess a cast to will only increase the size of the blueprint by the size of the interface though so maybe not so much of an issue?
@@cmulder007 The node is called "Does Implement Interface" with a Boolean Return, but you have a Target to assign in that node, so you can still do things with it. You can always Call an Interface and avoid the Casting :)
I've used casting many times and my packaged game crashes. IG this is the reason. But then how are you going to target specific variables from the thirdpersoncharacter bp? For example, I made my character to switch between tps and fps mode. So I casted the thirdpersoncharacter in widget ui and let the player switch between the cameras with the "F" key. How can I switch now without the casting please let me know////
You can target any variable from your Character to your Widget without Casting. I've made Health and Damage System without casting and without Event Tick. This subject is not that simple as doing with the Casting ( that's why there aren't any/much Tutorials for this ). The whole course for this I've recently posted on Udemy. If you have a chance have a look, if not, I need to plan for my future content whether to be completely on UA-cam or on Udemy, or both.
@@connorjade5460 Sorry to hear that, I haven't touched anything in the settings. I've deleted few comments from some users due to overly toxic, but I haven't disable anything. I will double check now. Thanks for letting me know and sorry for the inconvenience.
bro your video are amazing and i changed or my event ticks and delays man i like this, but there is something dangerous that i cant understand regarding casting, i understand that on maybe overlapp events can usee if = to player etc , but lets say idk whatever lets say that i want to spawn a BP or 10' times this blueprint so i want to change things on this blueprints for each of them , so how i can edit things inside these spawnewd bluieprintts if i dont cast ? i mean how i can load a parf of it into memory so i ca n edit it ? or take thius example spawning 5 AI enemy but you still need to cast to these AI to set variables or whatever i dont understand how to not load everything into memory and just a part what i want to edit from it
@@TheSuperGameHD Hey man, I'm happy you like the Tutorials. For the things to work as you were asking, you should use Blueprint Interface. I'm not sure if this will help, but you can try it and let me know if it helped: ua-cam.com/video/DmpRbWwJCzY/v-deo.htmlsi=QcS72Bcj6aK8QX9Z The things you were asking are a bit complex, so I have to make a whole Tutorial for it, probably I will do in the near future. Thanks again.
@@chankulovski Thats right bro , interfaces broooo, i will change now the rest of all casting sht , in sure my big project will run on windows xp with 4 gb ram or less xD
Now i understand that when i play gta v my 3080 grafics card the fans are always running and when playing the big game star Citizen the fans run only sometimes maybe in 1 hour of playing only 1 minute the fans are spinning thats amazing, and for the casting thing im hate it so much after watching your videos , but i was thinking if i want to test just something fast that will never be published i can just cast for testing so i think from hating it its more.like for testing , but when i think in the past vro casting was normal in my mind and now its just sht
@@RaulRadulescu You can use to quickly test something, but make sure that won't turn into a habit :) I'm using Optimized Blueprints even for testing, because if I like that what I'm testing, I will just leave it that way, I don't have to change the code 100 times :)
Wow this comment section is a laugh. I guess this is what you get for trying to help people to make good design choices. Your heart is in the right place I think, but people seem to have a hard time stomaching the truth. You guys can pick apart his example and come up with your own logic that validates your insecurities but that doesn't make what he is saying any less true. I agree with his methodology & try to avoid casting as much as possible. His example is perfect in demonstrating that there are other options like "get player character".
Thank you for your supportive comment, I really appreciate this ! Like I was telling them before, they just want to follow 6mins Tutorial full of Casting, Event Tick, connect 3 nodes and that's it, they are now Game Developers. But what really gives me hope is people like you who understand and acknowledge my hard work, and people who are really willing to go that extra mile to make their games optimized and enjoyable. Thanks again ! :)
@@chankulovski Honestly my bro... To your point I specifically watch for bad practices like using event tick & a lot of casting. Interfaces, use of components, & overall approach to design, would be some of my first boxes to check when it comes to a good tutorial. The reality of the state of learning on UA-cam is you really can't depend on one tutorial to explain how to do something. Sometimes even people with poor design framework will do something in such a way that it will surprise you. Keep up the work. I for 1 would love to see you release a tutorial series in UE 5.4 covering some of your optimized systems.
@@moosehead13 Thanks for your supportive comment ! I will continue releasing Tutorials for best practices, and making cool Gameplay Actions and UI programming as well. I will cover UE 5.4 but it will take some time for that. Reason 1: There are still a lot of people who cannot afford to use UE 5.4 and UE5.0.3 is very close to UE4, so a lot of things are relevant between these versions. Reason 2: UE5.4 is very new and unstable version, it will take time until they stabilize the version. Thanks again ! :)
Maybe your statement is just a bit too bold. When data is already loaded, casting to this data is not a bad thing. If it has to be loaded just for the cast, then it is a bad thing and you pointing this out correctly. So the title should be something like: be careful with casting.
Not bold at all, Devs and Designers should avoid using Casting if they want their game to be performant. It's a simple as that :) but for people who wants to accept the reality only.
@@erik8120 What file in memory? You have created Blueprint Actors in your Content Drawer like Projectiles, Loot Box etc. As long as you don't Drag and Drop them into the Level ( World ) they are NOT LOADED. So when you have a Projectile Actor in your Content drawer, this Actor is NOT LOADED. So when the Player spawns this Projectile, then it loads everything in it. If you have a Casting in the Projectile ( probably you do ), then you will make the Projectile more expensive than you should. Imagine when you spawn hundreds of Projectiles how bad this is for performance?
@@chankulovski yeah for sure, but that was not my point. You have to be careful with casting in general. But if you cast for example to your game instance class, which is spawned by default, then what is bad about this ? Just read my comments carefully. My point is that it’s not always bad or good, it depends on the situation and if the class is already loaded or not.
@@erik8120 It's your game after all, you can have 300 casting nodes if you want. I've explained in 200 comments and the Tutorial why Casting is bad. Just hover over you Casting node and READ what it says.
I'm glad it helped, feedback like this gives me even more motivation to create valuable content.Thank you for your nice words and support, it means a lot !
@@BingoBabyO Thank you very much for your support and inspiration, it means a lot ! The thing is, I know they won't nag me because I'm mentally very strong, but the problem is, there are so many aspiring developers and complete beginners who are just starting with Unreal, and they can be easily misguided, confused, and that will lead to quitting their gamedev dream job. When I started first, I was experiencing exactly the same thing and I wanted to quit, but thankfully I didn't. So I'm trying my best to pass my knowledge to the best of my abilities and to protect the beginners of being trolled and misguided. Thanks again for your support !
Even though they are not that heavy as the Casting node, you can still use different nodes to improve your Blueprints even better. If you want to interact or do something with an Actor, you should use "Actor Has Tag", or if you want to interact with a Component, you should use "Component Has Tag". These are lightweight because they are simply sending a message between Tag names.
Any Casting is bad, ESPECIALLY TO THE CHARACTER. That's why you should use Interface instead. I know it's a bit of a work, but it's worth it on the long run. Trust me, you don't want to spend 1-2 years of developing your game full of Casting inside ... I've regretted and it cost me BIG TIME, that's why I'm teaching everyone not to make the same expensive mistake I did ...
@@chankulovski But the question is if i create for example blueprint interface BPI_Interactable and somewhere cast to BPI_Interactable and then do interface call instead of interface message. You think this is bad too? And if so what is the reason?
@@geltun1 You simply don't need it, you are doing double the work if you Cast with that Interface. It's completely unnecessary. And also bad thing with that, is that you will load and reference everything within that Casting. It's just bad idea either way with Casting, you really really don't need it.
@chankulovski context is everything dude your argument is correct in some cases let's say you have 5 characters that the player can pick from if you cast to all 5 in that BP you will create a hard ref to all 5 characters which will cause them to be in memory and that is a case you would definitely not want to use casting but if you game only has one character there is nothing wrong with casting to it in that case as that 1 character will be loaded into memory regardless if you make a hard ref to it or not
@@Dante1243 Either way, Casting should be avoided at all cost. There are many other ways to do that, if the developer is willing to put that extra work and optimize their code. Casting is for lazy people.
Why u should use casting (ps : not realy, it was to offset the title) but u could : casting doesn't summon thing, it convert the object pinned to be read with the same object data propertie that the cast he is named at. Its a converter When u want to get a specific variable from a specific actor in a scene u need to convert this actor to read his property with the apropriate class wich mean u first get the actor wich cost performance then convert the get output to the correct class to read his information, property whatever u call it from that class and instance of it. The get and the cast are different thing, to better understand a cast node u can also try to understand his wildcard input and how this work and why interface replace them. Im not a total noob but im not a pro and i'd say if u can't use cast and u have to use a lot of interface u probably need to do what u are doing in c++ cause from what im doing im using realy few interface, everything is in my character bp except actual game system logic i have cast everywhere from bp that are loaded constantly anyway and it work fine so far
@@edgardsimon983 Why would I delete my own comments, I don't understand? When I see a comment from a user I'm replying, why would I delete my own comment? I've replied to your previous comment with: "Ok make sure you have 1000 Castings in your game", and that was it...
@@edgardsimon983 No no. Doesn't mean if we disagree on something that I will go crazy and delete comments :) There are so many comments that I can't find the new users who are commenting anymore :D
@@chankulovski bro pliz dont mock me to not give further answer u dont actualy explain anything and u dont tell why my understanding of casting is wrong. Im not talking about if yes or not its bad or if it will implie performance issue, tell me what a cast node do for u pliz
The title can easily cause misunderstandings for newcomers, right? When Character interacts with Actor in the level, there is really no need to use "cast to". In addition to "Other Actor = Character" in the video, you can also use "Get Tag" and so on instead, but in the Character blueprint and controller blueprint or animation For the interaction of blueprints, in this case, using "Cast to" will have better benefits. "Cast to" is not a bad thing, it needs to be used when appropriate.
True, you can use "Actor Has Tag", "Component Has Tag, "Does Implement Interface" nodes and so on instead of Casting. In the Controller Blueprint, Animation Blueprint YOU DON'T HAVE TO use Casting. I've done it, and it's much better performance without Casting. Everyone who says that Casting has benefits or it's used when appropriate, that person simply doesn't care for their game performance and don't want to put extra work, because it's quick and easy node that does everything, at the cost of the game performance. Casting IS A BAD PRACTICE, it's as simple as that.
Блин, вот совершенно случайно наткнулся, на видео. Не вводи людей в заблуждение, они этого не оценят, если не знаешь как работает каст, лучше не показывать подобное. Надеюсь ты понимаешь, что бывают такие механики в которых без каста ты не обойдешься. Без негатива.
I know what I'm teaching, that's why I'm teaching. Nothing is misleading. Everyone who says Casting is good or great, is either lazy or not knowing how much damage it causes to your game. But don't say misleading just because you love using Casting and don't want to hear about it.
Thank you great video fo me at least I'm a begginer and following a lot of tutorial that use cast and always wonder if there another way to do things and this is way more better for optimization purposes and for learning principles too. Do you have any information or where to find if the cast to character in the character BP that is default in third person blueprint has another way to do it ? Or in that case (movement control with the enhance input....) can be used. Thanks again keep going with the tutorial.
Hi there, thanks for your comment. I was following Tutorials the same like you, they are all with Casting ( because it's quick and easy to make a video for it ) and people are easily misguided ( just like you and me ). One of the best alternatives to avoid using Casting is Blueprint Interface. I have a whole Course on Udemy explaining all this stuff into great detail, check the link in description ( discount coupon is applied ).
I think you're blowing this idea way out of proportion and are pretty wrong about the blanket statement in the title. What next? are you planning "never use tick". I've seen some of these lately as well, by people who clearly don't understanding that tick is fundamental to every game, it's about choosing *what* ticks. Not avoiding it. Likewise, casting is sometimes unavoidable due to API restrictions. Its also great to enforce code on a part of the built-in game framework's hierarchy, like ACharacter / APawn. The real message should be to use it wisely and ALWAYS test cast failure but I guess that won't sell as good.
Do you know what sells? Content creators that are making Tutorials that the audience WANTS TO SEE ( Video of 6-12mins length, quick, easy, full of Casting, Event Ticks, and that's it, in 6mins you've learned how to setup a Health Bar, congratulations :)))) THIS sells my friend... if I wanted to sell, I would give the people what they wanna hear, not what they really need... But NOBODY wants to see the reality, that instead of using Casting and Event Ticks, you should use Blueprint Interface and Custom Events with Timers ( which takes around 30-60mins of work to setup a proper mechanics ). But hey, everybody wants to go the easy way: CAST TO CHARACTER, Event Tick, Delay - Congrats, you've become a game developer with 6mins Tutorial :))) On the side note, I have a video for "Never use Event Tick", and yes, you should NEVER use Tick. If you ever watched Epic Game Dev talks, you wouldn't write this comment. A legendary Epic Games staff Zak Parrish said: " I try to tell artists and people who are not skilled scripters to never use Tick. Just don't look at it, don't touch it, pretend it's not there, and even if you think you need it and if you're sure you need it - STILL DON'T USE IT !".
Many of the comments made me see that people simply don't want to get out of their comfort zone, they don't want to do the heavy lifting for best game performance...
@@chankulovski Casting is a fundamental property of code with almost no performance costs and no cost in native code. The only drawbacks is BP casting fills ram with potentially unneeded class data. Which is a non-issue when your cast is ACharacter since its already in memory in 99% of cases. You're right in warning people against building frankenstein-switch-like statements out of multiple casts one after the other tho, that's a given.
@@l_t_m_f Just Hover over the Casting Node and read what it says please, it's written in the node itself. Casting is not a fundamental property, it's meant to be for debugging and quick prototype purposes mostly. Please read what it says when you hover over the Casting node and let me know :) Thanks
@@chankulovski I know from another comment you said you don't do C++ so I think you'd have a heart attack if you take a look at casting at the C++ side. Casting is perfectly normal, only difference in BP is that you can add lots of meshes, materials, whereas in C++ it's merely code. Which is why inheritance should be used, casting to the parent base class with only code is perfectly fine and done in the industry, even Epic does it.
This is the "Never use ngon, only quad!!!" for the programming side. There's no absolute reason to not use casting the right way, and I'm sure that the author of this video know, but if you need to use clickbaity titles just to acquire more viewers I think you are not good enough to give lessons.
My only goal with these Tutorials, is to teach developers ( especially beginners, and advanced ), how to properly use Blueprints so their game will run smoothly with a minimum chances of crashing.
This is as terrible as the Tick video, and no epic devs do not state u should never use casting or tick, u just need to know when to use them and when it can be used without any issues, this guy has no idea what he is talking about like other noticed too. He didn't even release any big commercial game and he is selling an optimization course..., thats all u need to know, do listen to this, u wont learn anything here.
An Epic Games staff said: "" I try to tell artists and people who are not skilled scripters to never use Tick. Just don't look at it, don't touch it, pretend it's not there, and even if you think you need it and if you're sure you need it - STILL DON'T USE IT !" If you've ever watched a Gamedev Talk from Epic Games, you would've know. But you are simply jealous troll, that's it :)
Better take down this video buddy, this is pure misinformation, your Damage-Heal actor will use the same object in memory for the character that's already loaded in the world. Imagine how dumb it would be if for each actor that does a cast to the character, the whole thing was copied into memory? It wouldn't exist a rig capable of running the game for god sake.
I've corrected myself in the comments. If you have a Casting in one Actor and you duplicate that Actor, the Casting WILL NOT DOUBLE the size. But if you have 10 different Actors and these 10 Actors have Casting, everytime when you call these Actors will load everything from the Character.
@@chankulovski this is the second channel claiming insane bs about cast. You check the provided pointer's object type. if cast succeeds it was the appropriate object. Nothing is duplicated/loaded/whatever the thing is and was in memory. It's a fancy c++ cast but there lies the problem, none of you understand c++ and are creating this alternate universe where the craziest rules apply. It should make you think that you might not be the right person to offer a course on this matter...
@@chankulovski Try and explain this: But if you have 10 different Actors and these 10 Actors have Casting, everytime when you call these Actors will load everything from the Character. What do you mean by this? It doesn't make sense in c++ terms nor in blueprint terms. When you cast you really do expect the object to be there right?
@@chankulovski Another misconception would be that interfaces only load parts of the object but that isn't true. The object is fully in memory and you cast the pointer to the interface type. Nothing is or is not loaded... This is all c++ you know?
Whenever someone uses the word "never" in a video like this, often times they don't understand what they're talking about. This is a perfect example of how beginner Unreal devs hear "casting bad" and just make whole courses on how to avoid it. If you avoid casting you will end up creating complex solutions for absolutely no reason and make your code really hard to debug. Epic put casting into the engine for a reason. If it was never to be used it wouldn't be a feature in the first place. Casting is NOT bad, you just need to understand where and how to use it. If an object is loaded into memory already, casting is essentially free and preferred over interfaces. It will not cause any performance issues in this case and its faster. This includes things like the player character, the Game Instance and often your HUD as well. There's no reason to avoid casting to these classes because they exist in memory by the time the cast is performed. This is only an issue if you're casting to an object that isn't needed all the time like if you cast FROM your player to an object in the world that is only in one section of your level. That will load it into memory even when its not needed. I hope this helps someone before they pay for a course that will steer them in the wrong direction and take bad advice.
You are saying that I don't know what I'm talking about, without knowing how much experience I have and what I've achieved in game development ( that says it all ). Another thing, Epic put casting for a reason, yes, and that reason is: "To quickly test an idea and prototype, but to optimize the Blueprints you have to do the heavy lifting yourself, Epic won't do it for you". These words are from an Epic Games stuff, I've learned from one of their gamedev talks. My words: Casting is for lazy people and for people who want quick and easy fix and not taking care for their precious code and not bothering for the long term performance consequences. You my friend keep Casting in your games, but please don't post misinformation based on your own opinion and preferences, because there are new and aspiring game developers who needs to know how to properly program their game. Have a great day
@@chankulovski I mean i made a platformer and there are like 200 cast nodes inside my ui, obstacles and enemies, they all cast to the player character and the performance is fine even on old smartphones like redmi note 7 it's 12-15 ms, so if i want to save myself hours and make the code more readable i use cast. Ofc sometimes interfaces or soft references are the better choice but i know what i'm doing so - sometimes
His point is to teach optimization so he’s making a point that using casts can hurt that… I think it’s fine to give that description to teach an idea. He is making a point… he didn’t say your stuff is going to blow up.
@@BingoBabyO Well the title says "you should NEVER use cast" and the video didn't live up to it so i have my concerns
@@IstyManame thats fine… I didn’t watch the video coming away thinking I would never ever ever use a cast… i saw it for what it was - a proper warning about the use for cast and the cost of that use - thats all… every tool has a place. If the goal was pure optimization then removing as many un-needed casts is the message.. if you guys want to take everything as a literal absolute then you will have this issue of thinking. 💭 to each their own.
Casting is not bad. Poor use of casting is bad.
You don't NEED casting!!!!!
@@virtualalphastudios6149 indeed, but you'd be very hard pressed to find a game that doesnt use it. The runtime cost of casting used properly is absolutely miniscule, and the engine casts countless times a frame regardless of what you do.
You do know Unreal interfaces perform a C++ style cast under the hood and it's all just basically fancy reflection? You are NOT avoiding casting with it.
The big difference is that it doesn't hold on to the object in memory.
And if you know about it, how come it's not touched on? that's useful information.
As for Interfaces as a tool they have a place in programming and as a principle it's not meant to replace casting.
They allow you to think about solutions in a sort of "Multiple Inheritance" kind of way. It just so happens a lot of time that looks like replacing Casting.
I understand you coming from a place of wanting to counterbalance bad practice. Which is good. But you can't do that with misinformation and expect people to listen.
Misinformation here being to NEVER use cast.
When chosing wherther to use casting or interfaces context absolutely matters there is nothing wrong with casting to the game instance for example as it will be loaded into memory regardless if you have a hard refrance to it (Cast) casting wouldent be good if for example your casting to a car that your player can spawn later in the game in that case its best to use a interface (A interface that dosent create a hard ref) in conjunction with a soft class ref which you can later load when the car needs to be spawned
Every time when I see someone is so convinced about Casting with the saying "There is nothing wrong with the Cast", I immediately stop replying because it's useless explaining anymore, so ... feel free to use Casting in your games, that's your choice.
@chankulovski Im not saying casting is the best solution I'm saying in very specfic senerios casting is a acceptable solution like the game instance example the game instance will be in memory regardless of whether you cast to it. But in your example in the video I myself wouldent use casting because what if there are multiple character BP that's need to interact with that then you have a problem with casting.
Would really like to see you actually demonstrate this performance loss with casting with Unreal Insights. If we're never supposed to use it, that should be pretty easy, no? Otherwise your arguments in this entire comment section are just "trust me bro".
In order to fully demonstrate the damage of the Casting nodes, you need to create a whole game, it doesn't need to be AAA or something, but something playable for around 20mins approx. Then you will see how the game will crash many times. The Casting in your code will overload your RAM memory, so if you have a small game of 10-20mins playable something, you will need a GPU 1080 or 2060 if you want your game to be smooth. I've been doing games with Casting and I had terrible experience for a whole year when I was starting, so I'm passing this knowledge to prevent beginners do the same mistake and frustration like I did, so they won't lose 1 year in vain like me. I've demonstrated in the video how the memory is bumping up with Castings, and in the Casting Node it's written as well, so I didn't invent this, I've learned it and experienced it the hard way...
@@chankulovski I mean this comment just tells us everything we need to know. You had problems with casting "when you started" so you were just using it wrong. And now you're spreading misinformation because of the experience you had when you first started. If casting is causing your project to run out of memory then you're the one using casting wrong and that's totally your fault. It's not something everyone should avoid at all times. You used it improperly, you still don't really understand it, and you're telling other people stuff that is going to derail their projects because of bad advice. Like others have said, casting is totally fine to use if you use it properly.
@@fray989 You keep using it :) make sure you have everything Casted to :)
@@fray989 I don't think the author know much about class hierarchy. Casting is actually important and practically free if the thing you're casting to is already loaded.
@chankulovski You can tell who is inexperienced in the comments, don't waste your time typing to these kids lol, also unreal did a talk detailing this exact issue, maybe read up or watch some vids from the creators of unreal.
Yeah...In this case not casting to the player controller is not really necesary, especially since when ever you start the level it automatically possess the pawn that is assigned in the game mode. So it would be redundant to "reload" the controller using cast. I think that all is missing to the explaination could be that the engine always spawns a controller, doesnt matter which one is it and it is always created when playing the game, so the reference always exists. In that case casting is not necesary and would definitely be redundant, allowing for the solution you are using to be the best practice. But in other cases where the BP is not spawned by the engine on its own, casting is a great solution as long as you are not destroying the reference and / or have anything else dependant on that BP.
Friends, please understand... casting is NEVER GOOD SOLUTION. You should use Blueprint Interface instead. People are making thousands of excuses just to convince themselves that Casting is ok, IT'S NOT. Casting is used for quickly test an idea and prototype, to see things how they work and what they do, nothing else. Creating a whole game with Casting all around the Blueprints will ruin the game performance and there are high chances of crashing. But at the end of the day, everyone can use Blueprints as they like. My job is to teach people what is good, and what is not good with Blueprints to the best of my knowledge. Thanks for your feedback.
@@chankulovski tbh I am not really against the "not using cast", I agree with you that it is "better" to not be used, I think that this example might not have been the best to show it since the work around is "simple", and also I agree that a lot of tutorials show it that way, so this is really helpful for beginners. It would be best to showcase it against other implementations just like the one you mention which are the interfaces, and / or soft / hard references from one BP to another and compare and contrast, more of a "real world case". Either way, good video.
@@chankulovski this is retarded. Casting is fine. Bad casting isn't. Saying casting is "NEVER GOOD SOLUTION" and then in another comment saying it's just to get views is intellectually dishonest. Either you're lying or you're clueless as to what you're actually talking about.
Bold statement in the video titel. But the video don't really cover the topic or properly show what to replace it with.
(No need to defend yourself in the comments, try to take in peoples feedback and grow for your next video. Best of luck!)
Hi there, thanks for your feedback. I am not defending myself, I''m just allergic to toxic comments. As well, the person wrote completely irrelevant comment about C++ and whatnot, and that was misleading to other people. I just want to help the community to learn how to properly use Blueprints and why some nodes are not good for their games. I've replied in such manner because I'm trying to protect the aspiring developers and beginners of reading these type of nonsense. Regarding bold statement, I'm explaining in the video why you should never use Casting, that means everytime when you are using Casting you are loading and referencing the Casting Class and therefore it's loading up unnecessary files and assets that Class contains. I'm here for the community, not to get rich or something :) In the video I'm not showing what to replace the Casting with, is because I have a complete Course on Udemy and I'm teaching the students all of this in depth. Kindly check it out, you might find it useful. Thanks for your comment and feedback, I appreciate it.
@@chankulovski Saying you do this for the community and not to get rich, but then directly advertising your course in the next sentence is wild. If it was "just for the community" you could've just explained all that in a youtube video.
@@crspybtw Advertising a course of A$10 will not make me rich at all. People want to learn as soon as they can and the Course is alreary published with lots of information to help many people. Of course I will post another Tutorial on UA-cam according to user's feedback. This was just 1 video and I didn't know the interest is going to be this high.
Edit: This video is from the Course on Udemy.
@@chankulovski i apology on behalf of toxics reactions cause it realy look like ur not that bad and the course is not the problem even with the way u did it like the guy said previously, the reason why u get that much toxicity is cause ur not the first doing that and this look even worst, and its sad cause it seem like u understood enough but we can't aknowledge it with this amount of information u give, and i personaly think u know how it work but u dont have the correct word and u are indeed using those given in bad video, and despite me thinking i understand it enought i think u could learn me something cause i can still perfect my own understanding for sure
@@edgardsimon983 I am making more Tutorials with further explanations. I cannot put every information in one video because the video would last 2h minimum. I've put the most important information to wake up the developers/designers who believe that there's nothing wrong with the Casting. EVERYTHING IS WRONG WITH THE CASTING, so it's up to them to decide whether they will optimize their code and put up that extra work that's needed, or they will stay in their comfort zone and keep lying to themselves that Casting is great...
Out of curiosity, iv been using casting for any interactive elements. So i have ledges that can be grabbed which hold all of the logic when the user has grabbed them. Same with vents, switches for doors etc. How can you get the player and the interactive elements to speak to each other without casting?
You can use "Actor has Tag", or "Component has Tag", or Blueprint Interface. There are many other alternatives than Casting, depends how's your Blueprint setup. But definitely ditch the Casting, for the sake of your game's performance please.
@chankulovski So if the player pawn line traces to an actor which then will perform functionality based on the player characters variables, how can that be achieved without casting?
@@Jack-yk3nl Break the Out Hit, from Hit Actor create Interface with a name Interact, and connect the Hit Actor with the Target in the Interact Interface. Add the Interact Interface in the Actor you want to do interact with, and when you implement the Interface you can interact with this Actor. This is a bit more work ( that's why nobody wants to go through this setup, so instead they are using Casting cuz it's easy ), but once it's done properly, you can be sure that this setup will not kill your game.
casting node doesn't communicate with ur other bp, it convert the output pin for the actor to you to be able to read is specific property, there is no such a thing as communicating between thing, U GET AND CONVERT SOMETHING, it took me month to find finnaly a guy capable of saying me this simple specific thing.
@@edgardsimon983 Sorry but this comment is really funny ... ok, it's like you and the other guy is saying :)
overlapping is the easiest part. How can I make communication between diffrent BPs without overlapping and without casting?
try interfaces.
Like the other comment suggested it, try Blueprint Interface :)
@@chankulovski but still you need to provide reference to object and how can I achive that without casting or direct reference?
@@mikoajtarkowski4083 I have the whole course on Udemy explaining everything in details, because these things needs to be properly explained and you can't do it in 2mins like the videos with Casting. Check the link in the description for the Course, you should find it very useful.
@@mikoajtarkowski4083 You can call an interface function on any object. You can pass it in via a function, an overlap, an apply damage, exposed variable (though a soft reference is a better option). If the object implements the interface then it is called, if not it just fails and continues on with further blueprints.
My question is, for this case, if the player is already loaded into memory, does it "copy" all the player content into each one of the actors that cast it? Or just call the already loaded content in memory? In your example, if you create 100 actors waiting to cast the player you can have 3GB of memory just for this casting process, that doesn't sound real to me. It makes more sense if you cast 100 actors against another 100 actors that force to put all the actors in memory and then that is a case when is not recommended and can cause terrible problems. If someone know how this work exactly. Thanks
If you have 100 actors with Cast, you will not have 100x the memory size ( I checked and I was wrong about that and I apologize for the mistake ). But the problem remains the same, if you have 100 Actors in your game and you have a Cast inside, everytime when you Cast you will load that memory into the system everytime and that will strain your computer and it will cause to crash. And at the end of the day, Casting is still bad and you should not use it, period :)
@@chankulovski You have no clue what you are talking about
Casting issue is just creating hard reference to other assets, so even if the code is not called , just loading the first actor that has the casting node will load the class it cast to to memory with it even if you didn't call the function yet
But if that actor is already loaded then the cast won't hurt your memory or anything@@chankulovski
@@arrowsdev It's always the best practice to simply not use it at all. Imagine you are shooting a Projectiles fo example. You are spawning the Projectiles and every time when you spawn them, that loads up the memory and it's straining the system.Thanks for your feedback.
What about casting in AI Taks/Services/Decorators? As far as I know casting there is most reliable way of working, because otherwise you will need to find a shit tone workarounds for each of these entities, and btw even official UE tutorials show that you should work with casting for AI
It's like Epic games staff once said: "Epic made the engine for us and there are nodes to help you quickly test an idea and prototype something real quick ( casting, tick, delay etc ), but doing the proper way is your job and you should do it, Epic won't do it for you". That's why people are trying to convince me ( and themselves :))) that Casting is good, IT'S NOT. I know that therr is a lot of workaround like you've said, but that's the proper way of programming with Blueprints. It's not most reliable using Cast, it's the easiest and fastest way, yes, but with bad consequences. I wasn't working much with AI Tasks but the problem remains the same, if you Cast you are increasing the chances your game to crash and behave weird.
@@chankulovski I can agree to some degree, but than again, Epics have sample projects (Lyra for example), where they demonstrate not "prototypish" solutions, but solutions that they use themself in production of their projects (Fortnite), and these best practices also use casting when its best to be used
@@UELearning-bc7uu Epic also is using Casting for Animation Blueprint in the Default Templates, that doesn't mean we should not make it better. At the end of the day, it's all a matter of preferences, if you want the quick way with a possibility your game to behave unexpectedly, or the long way with a proper polished Blueprints for smoother gameplay experience. First time I hear Fortnite is using Casting, but even if they do, they are Casting to a C++ classes. When you use Casting in C++ classes, I've heard that the performance might not be that much affected. But my Courses are for Blueprints and Casting from Blueprint to Blueprint. ( I'm making another Tutorial as we speak, to demonstrate my point even further ), stay tuned. Thanks for your feedback, I appreciate sharing your thoughts.
@@UELearning-bc7uu This dude is absolutely off his tree. Unreal Engine is a very large ecosystem to wrap your head around.
Epic Games has made Lyra as a living project that follow their recommended standards. Who do you follow? The people who build this engine or some UA-camr spewing really bad advice.
@@fragileglass9622 I follow Epic staff and their Gamedev talks and GDC events. Hover over the Casting node and read what it says. I bet you've never read any documentation or whatsoever. Keep it up
Great video - thanks! - However lets say we are interacting with an actor that implements an interface - I have to cast it to a type of that interface to be able to call the methods defined on that interface! - how would I do this without casting? - seems the implementation of casts in blueprints is badly implemented!
Hey there, thanks for your comment! Try watching this Tutorial, hopefully it's what you are looking for:
ua-cam.com/video/DmpRbWwJCzY/v-deo.html&ab_channel=Chankulovski
If not, try to check my other Tutorials. Casting node is bad for your final game, and it's made for quick prototype and testing, there is almost always a way around it! :)
@@chankulovski Awesome I will do that... thanks a million for your quick reply!
@@cmulder007 Always! :) Let me know if this was what you were looking for, if not, I will try to explain in a comment, or make a Tutorial for it. Thanks again
That is also a great video... however in that example you are able to avoid casting because you know the object that you are going to be calling the function on is the player character (you check this with ==) and then you call GetPlayerCharacter ...... however in a more generic system where you want to check against ANY object that implements the interface, like for instance I_CanBeClicked.... and if the object does implement it you want to then call the ClickMe function defined on that interface, you still need a reference to the object as that interface.... hope that makes sense... I know there is a node to check if an object implements an interface but that just returns a boolean, I cannot find a way of calling the function on an abstracted object reference without a cast... however I guess a cast to will only increase the size of the blueprint by the size of the interface though so maybe not so much of an issue?
@@cmulder007 The node is called "Does Implement Interface" with a Boolean Return, but you have a Target to assign in that node, so you can still do things with it. You can always Call an Interface and avoid the Casting :)
And how big is that new way of casting?
Hi, thanks for your interest in this. What new way of casting you mean, I didn't understand. Thanks
@@chankulovskithe size map when you do the check and branching
@@iamagenius2646 What about it?
@@chankulovski this is what g3lon0s wants to see
I've used casting many times and my packaged game crashes. IG this is the reason. But then how are you going to target specific variables from the thirdpersoncharacter bp? For example, I made my character to switch between tps and fps mode. So I casted the thirdpersoncharacter in widget ui and let the player switch between the cameras with the "F" key. How can I switch now without the casting please let me know////
You can target any variable from your Character to your Widget without Casting. I've made Health and Damage System without casting and without Event Tick. This subject is not that simple as doing with the Casting ( that's why there aren't any/much Tutorials for this ). The whole course for this I've recently posted on Udemy. If you have a chance have a look, if not, I need to plan for my future content whether to be completely on UA-cam or on Udemy, or both.
@@chankulovski have you turned of replies on this comment?
@@connorjade5460 No, why?
@@chankulovski I'm trying to write a comment but youtube keeps removing it
@@connorjade5460 Sorry to hear that, I haven't touched anything in the settings. I've deleted few comments from some users due to overly toxic, but I haven't disable anything. I will double check now. Thanks for letting me know and sorry for the inconvenience.
bro your video are amazing and i changed or my event ticks and delays man i like this, but there is something dangerous that i cant understand regarding casting, i understand that on maybe overlapp events can usee if = to player etc , but lets say idk whatever lets say that i want to spawn a BP or 10' times this blueprint so i want to change things on this blueprints for each of them , so how i can edit things inside these spawnewd bluieprintts if i dont cast ? i mean how i can load a parf of it into memory so i ca n edit it ? or take thius example spawning 5 AI enemy but you still need to cast to these AI to set variables or whatever i dont understand how to not load everything into memory and just a part what i want to edit from it
@@TheSuperGameHD Hey man, I'm happy you like the Tutorials. For the things to work as you were asking, you should use Blueprint Interface. I'm not sure if this will help, but you can try it and let me know if it helped: ua-cam.com/video/DmpRbWwJCzY/v-deo.htmlsi=QcS72Bcj6aK8QX9Z
The things you were asking are a bit complex, so I have to make a whole Tutorial for it, probably I will do in the near future. Thanks again.
@@chankulovski Thats right bro , interfaces broooo, i will change now the rest of all casting sht , in sure my big project will run on windows xp with 4 gb ram or less xD
Now i understand that when i play gta v my 3080 grafics card the fans are always running and when playing the big game star Citizen the fans run only sometimes maybe in 1 hour of playing only 1 minute the fans are spinning thats amazing, and for the casting thing im hate it so much after watching your videos , but i was thinking if i want to test just something fast that will never be published i can just cast for testing so i think from hating it its more.like for testing , but when i think in the past vro casting was normal in my mind and now its just sht
@@RaulRadulescu You can use to quickly test something, but make sure that won't turn into a habit :) I'm using Optimized Blueprints even for testing, because if I like that what I'm testing, I will just leave it that way, I don't have to change the code 100 times :)
@chankulovski somehow bro i m envious that you showing this professional information for every nub for free like me
Wow this comment section is a laugh. I guess this is what you get for trying to help people to make good design choices. Your heart is in the right place I think, but people seem to have a hard time stomaching the truth. You guys can pick apart his example and come up with your own logic that validates your insecurities but that doesn't make what he is saying any less true. I agree with his methodology & try to avoid casting as much as possible. His example is perfect in demonstrating that there are other options like "get player character".
Thank you for your supportive comment, I really appreciate this ! Like I was telling them before, they just want to follow 6mins Tutorial full of Casting, Event Tick, connect 3 nodes and that's it, they are now Game Developers. But what really gives me hope is people like you who understand and acknowledge my hard work, and people who are really willing to go that extra mile to make their games optimized and enjoyable. Thanks again ! :)
@@chankulovski Honestly my bro... To your point I specifically watch for bad practices like using event tick & a lot of casting. Interfaces, use of components, & overall approach to design, would be some of my first boxes to check when it comes to a good tutorial. The reality of the state of learning on UA-cam is you really can't depend on one tutorial to explain how to do something. Sometimes even people with poor design framework will do something in such a way that it will surprise you. Keep up the work. I for 1 would love to see you release a tutorial series in UE 5.4 covering some of your optimized systems.
@@moosehead13 Thanks for your supportive comment ! I will continue releasing Tutorials for best practices, and making cool Gameplay Actions and UI programming as well. I will cover UE 5.4 but it will take some time for that. Reason 1: There are still a lot of people who cannot afford to use UE 5.4 and UE5.0.3 is very close to UE4, so a lot of things are relevant between these versions. Reason 2: UE5.4 is very new and unstable version, it will take time until they stabilize the version. Thanks again ! :)
Maybe your statement is just a bit too bold. When data is already loaded, casting to this data is not a bad thing. If it has to be loaded just for the cast, then it is a bad thing and you pointing this out correctly. So the title should be something like: be careful with casting.
Not bold at all, Devs and Designers should avoid using Casting if they want their game to be performant. It's a simple as that :) but for people who wants to accept the reality only.
@@chankulovski if the file is already in memory, like a game state, what is the harm to cast to this already loaded data?
@@erik8120 What file in memory? You have created Blueprint Actors in your Content Drawer like Projectiles, Loot Box etc. As long as you don't Drag and Drop them into the Level ( World ) they are NOT LOADED. So when you have a Projectile Actor in your Content drawer, this Actor is NOT LOADED. So when the Player spawns this Projectile, then it loads everything in it. If you have a Casting in the Projectile ( probably you do ), then you will make the Projectile more expensive than you should. Imagine when you spawn hundreds of Projectiles how bad this is for performance?
@@chankulovski yeah for sure, but that was not my point. You have to be careful with casting in general. But if you cast for example to your game instance class, which is spawned by default, then what is bad about this ? Just read my comments carefully. My point is that it’s not always bad or good, it depends on the situation and if the class is already loaded or not.
@@erik8120 It's your game after all, you can have 300 casting nodes if you want. I've explained in 200 comments and the Tutorial why Casting is bad. Just hover over you Casting node and READ what it says.
Thank you for this nice tutorial… I have purchased your Udemy class as a result. ;) Good teachings.
I'm glad it helped, feedback like this gives me even more motivation to create valuable content.Thank you for your nice words and support, it means a lot !
@@chankulovski teaching people is an honorable thing to do… you deserve support and respect. Don’t let the trolls nag you…
@@BingoBabyO Thank you very much for your support and inspiration, it means a lot ! The thing is, I know they won't nag me because I'm mentally very strong, but the problem is, there are so many aspiring developers and complete beginners who are just starting with Unreal, and they can be easily misguided, confused, and that will lead to quitting their gamedev dream job. When I started first, I was experiencing exactly the same thing and I wanted to quit, but thankfully I didn't. So I'm trying my best to pass my knowledge to the best of my abilities and to protect the beginners of being trolled and misguided. Thanks again for your support !
I tend to use get actor of class or get actor of class with tag, seems to work for me but it's early days, are there downsides to using this?
Even though they are not that heavy as the Casting node, you can still use different nodes to improve your Blueprints even better. If you want to interact or do something with an Actor, you should use "Actor Has Tag", or if you want to interact with a Component, you should use "Component Has Tag". These are lightweight because they are simply sending a message between Tag names.
@@chankulovski makes sense, thankyou!
@@hardcorerick8514 You are very welcome ! I am preparing another good Tutorial with some really useful information. Keep an eye on the Channel :)
And what about casting to interface? Do you think it is bad too?
Any Casting is bad, ESPECIALLY TO THE CHARACTER. That's why you should use Interface instead. I know it's a bit of a work, but it's worth it on the long run. Trust me, you don't want to spend 1-2 years of developing your game full of Casting inside ... I've regretted and it cost me BIG TIME, that's why I'm teaching everyone not to make the same expensive mistake I did ...
@@chankulovski But the question is if i create for example blueprint interface BPI_Interactable and somewhere cast to BPI_Interactable and then do interface call instead of interface message. You think this is bad too? And if so what is the reason?
@@geltun1 You simply don't need it, you are doing double the work if you Cast with that Interface. It's completely unnecessary. And also bad thing with that, is that you will load and reference everything within that Casting. It's just bad idea either way with Casting, you really really don't need it.
@chankulovski context is everything dude your argument is correct in some cases let's say you have 5 characters that the player can pick from if you cast to all 5 in that BP you will create a hard ref to all 5 characters which will cause them to be in memory and that is a case you would definitely not want to use casting but if you game only has one character there is nothing wrong with casting to it in that case as that 1 character will be loaded into memory regardless if you make a hard ref to it or not
@@Dante1243 Either way, Casting should be avoided at all cost. There are many other ways to do that, if the developer is willing to put that extra work and optimize their code. Casting is for lazy people.
Great explanation thank you!
Thanks for your feedback, I'm glad it helped !
Why u should use casting (ps : not realy, it was to offset the title) but u could : casting doesn't summon thing, it convert the object pinned to be read with the same object data propertie that the cast he is named at. Its a converter
When u want to get a specific variable from a specific actor in a scene u need to convert this actor to read his property with the apropriate class wich mean u first get the actor wich cost performance then convert the get output to the correct class to read his information, property whatever u call it from that class and instance of it.
The get and the cast are different thing, to better understand a cast node u can also try to understand his wildcard input and how this work and why interface replace them.
Im not a total noob but im not a pro and i'd say if u can't use cast and u have to use a lot of interface u probably need to do what u are doing in c++ cause from what im doing im using realy few interface, everything is in my character bp except actual game system logic i have cast everywhere from bp that are loaded constantly anyway and it work fine so far
OK :)))))) make sure you have 1000 Casting in your Blueprints :)
@@chankulovski nvm i thought u was deleting ur comment but i was not seing ur comment anymore at first
@@edgardsimon983 Why would I delete my own comments, I don't understand? When I see a comment from a user I'm replying, why would I delete my own comment? I've replied to your previous comment with: "Ok make sure you have 1000 Castings in your game", and that was it...
@@edgardsimon983 No no. Doesn't mean if we disagree on something that I will go crazy and delete comments :) There are so many comments that I can't find the new users who are commenting anymore :D
@@chankulovski bro pliz dont mock me to not give further answer u dont actualy explain anything and u dont tell why my understanding of casting is wrong. Im not talking about if yes or not its bad or if it will implie performance issue, tell me what a cast node do for u pliz
The title can easily cause misunderstandings for newcomers, right? When Character interacts with Actor in the level, there is really no need to use "cast to". In addition to "Other Actor = Character" in the video, you can also use "Get Tag" and so on instead, but in the Character blueprint and controller blueprint or animation For the interaction of blueprints, in this case, using "Cast to" will have better benefits. "Cast to" is not a bad thing, it needs to be used when appropriate.
True, you can use "Actor Has Tag", "Component Has Tag, "Does Implement Interface" nodes and so on instead of Casting. In the Controller Blueprint, Animation Blueprint YOU DON'T HAVE TO use Casting. I've done it, and it's much better performance without Casting. Everyone who says that Casting has benefits or it's used when appropriate, that person simply doesn't care for their game performance and don't want to put extra work, because it's quick and easy node that does everything, at the cost of the game performance. Casting IS A BAD PRACTICE, it's as simple as that.
Блин, вот совершенно случайно наткнулся, на видео. Не вводи людей в заблуждение, они этого не оценят, если не знаешь как работает каст, лучше не показывать подобное. Надеюсь ты понимаешь, что бывают такие механики в которых без каста ты не обойдешься. Без негатива.
I know what I'm teaching, that's why I'm teaching. Nothing is misleading. Everyone who says Casting is good or great, is either lazy or not knowing how much damage it causes to your game. But don't say misleading just because you love using Casting and don't want to hear about it.
You got my subs .keep making like this video
Thank you for the subs! I appreciate your support and I hope this video was helpful to you. I will post other important content definitely.
Thanks a lot . I will wait for new tutorial like this. You have earned a new sub bro.
Thank you, I really appreciate it ! Soon I will post more interesting and valuable Tutorials.
Thank you great video fo me at least I'm a begginer and following a lot of tutorial that use cast and always wonder if there another way to do things and this is way more better for optimization purposes and for learning principles too. Do you have any information or where to find if the cast to character in the character BP that is default in third person blueprint has another way to do it ? Or in that case (movement control with the enhance input....) can be used. Thanks again keep going with the tutorial.
Hi there, thanks for your comment. I was following Tutorials the same like you, they are all with Casting ( because it's quick and easy to make a video for it ) and people are easily misguided ( just like you and me ). One of the best alternatives to avoid using Casting is Blueprint Interface. I have a whole Course on Udemy explaining all this stuff into great detail, check the link in description ( discount coupon is applied ).
@@chankulovski Will do thank you!
I think you're blowing this idea way out of proportion and are pretty wrong about the blanket statement in the title. What next? are you planning "never use tick". I've seen some of these lately as well, by people who clearly don't understanding that tick is fundamental to every game, it's about choosing *what* ticks. Not avoiding it. Likewise, casting is sometimes unavoidable due to API restrictions. Its also great to enforce code on a part of the built-in game framework's hierarchy, like ACharacter / APawn. The real message should be to use it wisely and ALWAYS test cast failure but I guess that won't sell as good.
Do you know what sells? Content creators that are making Tutorials that the audience WANTS TO SEE ( Video of 6-12mins length, quick, easy, full of Casting, Event Ticks, and that's it, in 6mins you've learned how to setup a Health Bar, congratulations :)))) THIS sells my friend... if I wanted to sell, I would give the people what they wanna hear, not what they really need...
But NOBODY wants to see the reality, that instead of using Casting and Event Ticks, you should use Blueprint Interface and Custom Events with Timers ( which takes around 30-60mins of work to setup a proper mechanics ).
But hey, everybody wants to go the easy way: CAST TO CHARACTER, Event Tick, Delay - Congrats, you've become a game developer with 6mins Tutorial :)))
On the side note, I have a video for "Never use Event Tick", and yes, you should NEVER use Tick.
If you ever watched Epic Game Dev talks, you wouldn't write this comment.
A legendary Epic Games staff Zak Parrish said: " I try to tell artists and people who are not skilled scripters to never use Tick. Just don't look at it, don't touch it, pretend it's not there, and even if you think you need it and if you're sure you need it - STILL DON'T USE IT !".
Many of the comments made me see that people simply don't want to get out of their comfort zone, they don't want to do the heavy lifting for best game performance...
@@chankulovski Casting is a fundamental property of code with almost no performance costs and no cost in native code. The only drawbacks is BP casting fills ram with potentially unneeded class data. Which is a non-issue when your cast is ACharacter since its already in memory in 99% of cases. You're right in warning people against building frankenstein-switch-like statements out of multiple casts one after the other tho, that's a given.
@@l_t_m_f Just Hover over the Casting Node and read what it says please, it's written in the node itself. Casting is not a fundamental property, it's meant to be for debugging and quick prototype purposes mostly. Please read what it says when you hover over the Casting node and let me know :) Thanks
@@chankulovski I know from another comment you said you don't do C++ so I think you'd have a heart attack if you take a look at casting at the C++ side. Casting is perfectly normal, only difference in BP is that you can add lots of meshes, materials, whereas in C++ it's merely code. Which is why inheritance should be used, casting to the parent base class with only code is perfectly fine and done in the industry, even Epic does it.
This is the "Never use ngon, only quad!!!" for the programming side. There's no absolute reason to not use casting the right way, and I'm sure that the author of this video know, but if you need to use clickbaity titles just to acquire more viewers I think you are not good enough to give lessons.
My only goal with these Tutorials, is to teach developers ( especially beginners, and advanced ), how to properly use Blueprints so their game will run smoothly with a minimum chances of crashing.
This is as terrible as the Tick video, and no epic devs do not state u should never use casting or tick, u just need to know when to use them and when it can be used without any issues, this guy has no idea what he is talking about like other noticed too.
He didn't even release any big commercial game and he is selling an optimization course..., thats all u need to know, do listen to this, u wont learn anything here.
An Epic Games staff said: "" I try to tell artists and people who are not skilled scripters to never use Tick. Just don't look at it, don't touch it, pretend it's not there, and even if you think you need it and if you're sure you need it - STILL DON'T USE IT !"
If you've ever watched a Gamedev Talk from Epic Games, you would've know. But you are simply jealous troll, that's it :)
Better take down this video buddy, this is pure misinformation, your Damage-Heal actor will use the same object in memory for the character that's already loaded in the world.
Imagine how dumb it would be if for each actor that does a cast to the character, the whole thing was copied into memory? It wouldn't exist a rig capable of running the game for god sake.
I've corrected myself in the comments. If you have a Casting in one Actor and you duplicate that Actor, the Casting WILL NOT DOUBLE the size. But if you have 10 different Actors and these 10 Actors have Casting, everytime when you call these Actors will load everything from the Character.
@@chankulovski this is the second channel claiming insane bs about cast. You check the provided pointer's object type. if cast succeeds it was the appropriate object. Nothing is duplicated/loaded/whatever the thing is and was in memory. It's a fancy c++ cast but there lies the problem, none of you understand c++ and are creating this alternate universe where the craziest rules apply. It should make you think that you might not be the right person to offer a course on this matter...
@@indiesigi7807 Everything is LOADED into the Memory even if you don't use the Cast. Watch the video first, before commenting nonsense.
@@chankulovski Try and explain this: But if you have 10 different Actors and these 10 Actors have Casting, everytime when you call these Actors will load everything from the Character. What do you mean by this? It doesn't make sense in c++ terms nor in blueprint terms. When you cast you really do expect the object to be there right?
@@chankulovski Another misconception would be that interfaces only load parts of the object but that isn't true. The object is fully in memory and you cast the pointer to the interface type. Nothing is or is not loaded... This is all c++ you know?
Clickbait, stay away.
Internet troll, stay away.