Blueprint Funtion Librairy Risks and Usage

Hello, i need some clarifications about BFL and their usage and risks on performances

Im just learning the power of BFL to make some repetitive blueprint operations easier to do.

One example is a Cast To Player, i made a BFL function for this kind of operations.
Here’s the idea :

I made a Cast to player with a print string that would tell me if the cast failed.

This is the typical situation where if i need to cast to player on a component overlap event, its annoying to set tup the cast, needs a lot of BP space and a Function like this is just really handy.

Same for Cast to Game Instance or specific Savegames from the GI.

Could it be bad for performances or could it lead to other kind of problems ?

I rather know before i start to replace all of my casts with the BFL one…

Please, inform me on all the risks about BFL.

Thanks

it will have the same effective performance as calling the functions within your other BP with a VERY TINY bit of overhead. Not worth considering unless you’re calling this function a lot per tick or within a large loop.

The biggest risk of relying on this is you lose encapsulation of your data and functionality, and that function in the BPFL will load your BP_Player into memory even if you’re not spawning one. This may not be an issue if BP_Player is always loaded anyways. This is more of a design issue than performance consideration.

Could you elaborate a bit on that please ?

You mean that if i have a BFL that cast to the player, and i dont actually use that function anywhere, the reference in the BFL will still be loaded at all time ?

like if the BLF is always running in the background somehow ?

If you have a reference to the class type with the Cast, it will load the BP_Player class up to be able to attempt to cast to it. If you don’t call the function ever, I’m not sure if it will load the class, honestly. But then what would the point of the function be?

It’s not that it’s ‘running’… it is ‘what data structure does the function need’ to be able to make the call. There is basically no overhead besides memory allocation to having the class available in memory. If you need access to it, you have no choice. You might be able to get around this with Interfaces, but may not make sense for your main player character if it’s a ref to a class that’s always loaded anyways.

I wouldn’t get too hung up on this. Just know hard-reference to class types (like a Cast, or a BP_Player object variable type) will load them in memory. Casting and object pointers are normal things to do in a game situation. The big issue is having Casts and refs all over the place that load in a bunch of classes/objects and creating a spider web of refs that load way too much into memory. That’s the place for soft-refs or maybe interfaces, but may not be applicable in your situation.

1 Like

Okay i think i understand, thanks for your help !

1 Like

it will as long as that function library is referenced anywhere.

the real danger is if you use a single function library for GetPlayer, GetGameMode, GetGameState etc then when you access one like GetPlayer you create a dependancy to all those classes because you’re referencing the FL.

that starts out fine but then you add an FX manager to your GameState and now thats loaded and all referenced effects etc and it can spiral.

this isnt anything to panic about in a small project but the point was to understand

1 Like