You can Cast more Safely by Doing THIS

[@FluteboxFan]

The reason why (loading textures, meches, animation), and the way how to analyze was actually interesting - thank you for explaining!

[@Punisher1992]

they said, preattached child actors, are very buggy and we should not use them directly in an actor as a child, its better to spawn them and then attach.

[@krookedliptv9852]

Yeah I use zero forms of inheritance. You should check out what gameplay tags are and how to use them with primary data assets and data structures

[@thegamedevcave]

yeah child actor components are a little weird. It's adviced to not use them as prefabs, for simple stuff like this though, in my experience they are fine. of course if you CAN make something a proper component instead that's always preferable

[@Punisher1992]

@@thegamedevcave made the same experience, but it was not really hard to make an actor component that attaches the actors on begin play anyway.

[@kattenmusen10kofficial]

Good video! I think there should be a simple tool that lets you define c++ classes with just a few clicks, for people who aren't interested in learning how to code c++, in case they have the need to benefit from the extra marginal performance boost.

[@thegamedevcave]

If you’re not going to code in c++ there’s very little reason to make a c++ class because you’d be casting to an empty class :)

[@IWillYeah]

You supposedly use to be able to build your game with BP to c++ auto converted code, but they got rid of it for some reason.

[@velha2999]

Great insights!

[@musichopper3644]

You should look into the "IsA" Node that I believe was introduced in UE5.5

[@thegamedevcave]

I heard about that in a presentation on the unreal YT channel. Still, that only does a class check, which is what many people use casts for. But it doesn't replace the full functionality of casting, where the actual use for it is getting to access functions or components on another class.

[@musichopper3644]

@ I see. I don’t tent to run into cast problems cause I usually just use an interface call to have the item return the type it is. Like for my player character, I’ll do an interface call on it to see if it’s a characters, which will also return the class, check if it’s valid, and then you have access to all the class functions.

[@thegamedevcave]

@@musichopper3644 so with that you're pretty much just creating a cast that youve set up by yourself. because if you return a reference that can run class specific functions or access variables, that has to be a reference of that class type, meaning it is a hard reference (unless youre very specifically setting it up to be a soft reference of course). So in the end you've re-created the issue with the casting node, which is that it creates hard references to other classes (and any used assets in those classes)

[@musichopper3644]

@@thegamedevcave So I decide to test it out, so the memory usage is basically the same, except for the editor memory because needing to do a manual validation on the interface version takes up memory and so does the interface call node. I also decide to test out if the interface was faster vs casting, and it turns out casting was faster by around 5-10ms on a 100,000 iteration loop, all I did was get the reference and set a variable on the actor. This might be the validation check on blueprints, so c++ could make the difference more negligible but I don't feel like testing it. So lol, the main reason I was using interfaces was because I thought it was a faster lookup time. But I'm willing to be wrong. Guess I actually have to stop putting off learning how to use soft references now. I'm also going to preface this with, I think people focus too much on the memory cost of casting, generally it's fine to use unless you're genuinely abusing it, where an interface call would have been better, like for doing damage. Also, I appreciate the video on GUID you did recently, I feel like it doesn't get talked about enough despite being super useful for saving/loading.

[@musichopper3644]

@@thegamedevcave My first typed out response didn't send for some reason, so here's attempt 2. Basically, I tested casting and interface, and their memory cost is basically the same. However, casting is faster than interfaces (anywhere between 5-10ms) after testing them out on a 100,000 iteration loop (let's be honest, you're realistically not running that many casts). Which is not what I expected, but it could have also been due to the blueprint validation check done on the interface, so maybe c++ makes the difference more negligible. Generally I feel people think that casts are evil, but honestly as long as you don't abuse them, and use interfaces when necessary, they're generally not a problem. Also, now I have no excuses putting off learning how to use soft references. I'll definitely look into returning a soft reference through the interface and see how well that goes.

[@taariqmartin7743]

Ok I cast to the master how to I get gun 1 from it

[@thegamedevcave]

you don't. Gun 1 shouldn't need to be cast to. all the functions and relevant components exist on the master. Running "attack" on the master version of the class will run whatever version of it you program in Gun 1, that's what inheritance does :)

[@IWillYeah]

​​@thegamedevcave That is one way, but holding all of the variables, functions (and child components) in the parent will noticeably increase runtime memory footprint as each child will allocate memory etc PER instance to facilate functionality it doesn't well, facilate. Which is a bit counterintuitive verse simply casting (loading in the class and existing world object). e.g. if an actor was spawned in the world, casting has zero cost as likely all of its dependences are already in memory.

[@thegamedevcave]

@ the amount you save with not loading even a single asset will require a LOT of variables and instances to get to the same level. Most variable types are of a size where we describe them as bytes. Where most assets are comfortably in the megabytes range. It’s super unlikely that you’re actually saving any memory on instances with variables while also loading a bunch of assets. Besides, you likely need those variables anyway so that memory cost doesn’t go away. Dividing the variables between a few different “branches” of classes might be a good idea though to prevent actors from having variables they don’t need. The point isn’t to have 1 massive monster of a master class for your whole game, it’s that functions and variables ideally exist on a base class. Of course you can make as many different base classes as you need