It's a quick video to let you know about BPL but doesn't explain some issues you might face and how to use the efficiently, so i'll say a few words from a game dev. 1. One point has already been raised, and that is memory. Whenever you use any function from that library anywhere, it will paste the whole library, and it will load every ref to memory. Anytime you cast, you load that asset. So you can end up with a serious memory chain if you're not careful. Learn about soft references. 2. In addition to making those functions pure, you can input something in "Compact Node Title" to make the node even slimmer. 3. Keep in mind those are functions, and they're just grouped in a library, they do not have persistent memory. Anytime you wanna use a delay or save some variable for later use, you will have to do it somewhere else. 4. I don't recommend making popups in BPL, just do it in a HUD that you can access from anywhere anyway but without BPL drawback. Thank me later.
Blueprint function library is great together with data assets, for making easy to modify "global" values. Like you want color scheme that is easy to tweak for all widgets? Make struct with all colors or tints or brushes. Put it into data asset. Then make function (or functions) that get data asset, read required value and return it. Make them pure. Edit data assets to tweak them.
Be careful when casting from/having hard references in your function libraries. Whatever the size of the function library is will be added to any BP you use a function from that's in that library. So, if you use that createpopup function somewhere, it will load your 3rd person character (from the cast) I to that blueprint as its in the same function library. I had just realized this last night, easily fixed by making multiple function libraries. I would suggest making a separate library for each function that will have a cast/hard ref.
@@polyplayground i got in the habbit of checking my size maps for things I've worked on before calling it a day. Has really helped my understanding of how refs work and is also making my game leaner and cleaner. Same vibe as checking your bank account each morning. It hurts, but it's a good habbit 😂
@@VeryTori Right click a blueprint then go to "Size Map". Another tip, unconnected nodes and textures ARE in that blueprint's memory! I had to clear a bunch of duplicated materials because I had 3 high quality textures in each of them and the game saw those in the size map!
Its not. Its still a cast node. And usualy you dont gain fps with cpu calculation optimizations. And ofcourse using blueprint interfaces is a lot more optimized than casting.
@@polyplayground i think you are not getting it. I mean to say I will use Interfaces instead of casting. It can be use for anything anywhere just like function libraries. We can add functions to interfaces instead.
I agree, creating hard references, like when casting, is not a good idea to use in a library. It will increase the size of your blueprints. Instead of that, I would better use blueprint interfaces. In a library, I would use other general functions.@@rabitkhaitu
@@rabitkhaitu You can still (and probably should) use interfaces. In the function library function just use an interface instead. Libraries just save you from creating the same nodes over and over again. Simply a cleaner approach.
I said some bad words out loud when I saw this! Wife thought that I learned some very bad news or that someone died. 😂. I knew about making functions but this is new to me. Thanks.
Good tutorial and example with casting, but don't learn to avoid casting. It bloats memory size, is inefficient and makes me wonder why it's even in the engine.
Casting is great when used properly. Check out my long ass comment i made elsewhere on this video, but I go a bit into what casting actually is. Casting is by far the fastest and most efficient method to communicate between blueprints if used correctly. If An AC is casting to a blueprint it is added to, then the cast adds no extra memory bloating at runtime and if you cast to a parent class, that is also free memory. The memory map can be deceiving as it doesn't know how you plan on using things, so it assumes nothing. For instance scene component, or really anything that is attached to FPC that casts to FPC as a part of its functions/events/whatever will show an instance of FPC in it's memory map making it look bloated. However, the memory map is just assuming that it doesn't already have a ref to FPC. when that component is added to FPC as a component, it will already have that reference due to the fact that it's is nested inside of FPC already. It won't load a second instance of FPC into FPC to accomplish that. However, you need to do this without creating a hard variable reference in the Component, so drag off of the cast input ref and select "get owner" but make sure it's the component variant. You normally have to de-select context to get this one for some reason. If you create a hard ref variable to FPC in a component in FPC I think you will load FPC into FPC. (this is something i'm going to test in insights pretty soon as i'm curious) You can also cast down the inheritance tree in a similar manner for free. This one is a weird one which i'm just starting to understand. But You can cast to a parent class ref with a child object ref as the input and access stuff inside of the child while only having the memory weight of the parent This is why proper inheritance and using actor components in a meaningful manner can really make stuff easier on you. As the data flow never needs to reach outside of the BP in order to take that action when you cast. I love BPIs but if you use a BPI to send a message to something you have a common inheritance to or are attached to. You're reaching out of the blueprint to the bpi, then back into the blueprint. It's slightly more overhead
1.) Use casting when you have common inheritance. 2.) Use BPIs when it's easier for the object sending the message to get a ref to the object that needs the ref. 3.) Use dispatches when it's easier for the objects that need the message to get a ref to the thing sending the message I say this not trying to be a dick, but in trying to help. Understanding what all 3 of those are on a very deep level has really upped my game and made programming in Blueprint a ton more enjoyable. A few years ago unreal released a live training video called something like "Blueprint communication Live training" It's the most fruitful 3 hours you'll ever spend on youtube during your UE journey. Really helped me understand that stuff.
@@shrek_yourself Did I strike a nerve lol I didn't say you shouldn't use it just that not using it is a possible way to make better games. Also I started with BP in 2014. Don't know what you mean by shitty code and I don't use VS because it's garbage.
@shrek_yourself oh damn, you got owned. They don't even use VS, they're a hipster who probably uses their own custom compiler, that probably allows them to code in lisp or haskell or some other hipster language instead. You got wrecked Shrek. Give up.
It's a quick video to let you know about BPL but doesn't explain some issues you might face and how to use the efficiently, so i'll say a few words from a game dev.
1. One point has already been raised, and that is memory. Whenever you use any function from that library anywhere, it will paste the whole library, and it will load every ref to memory. Anytime you cast, you load that asset. So you can end up with a serious memory chain if you're not careful. Learn about soft references.
2. In addition to making those functions pure, you can input something in "Compact Node Title" to make the node even slimmer.
3. Keep in mind those are functions, and they're just grouped in a library, they do not have persistent memory. Anytime you wanna use a delay or save some variable for later use, you will have to do it somewhere else.
4. I don't recommend making popups in BPL, just do it in a HUD that you can access from anywhere anyway but without BPL drawback. Thank me later.
Woah, I knew about macros and functions but no idea about this. Thanks so much for a quick and concise video!
Glad it was helpful!
Short and easy to follow tutorial. Thanks.
Glad it helped!
Blueprint function library is great together with data assets, for making easy to modify "global" values. Like you want color scheme that is easy to tweak for all widgets? Make struct with all colors or tints or brushes. Put it into data asset. Then make function (or functions) that get data asset, read required value and return it. Make them pure. Edit data assets to tweak them.
Be careful when casting from/having hard references in your function libraries.
Whatever the size of the function library is will be added to any BP you use a function from that's in that library.
So, if you use that createpopup function somewhere, it will load your 3rd person character (from the cast) I to that blueprint as its in the same function library.
I had just realized this last night, easily fixed by making multiple function libraries. I would suggest making a separate library for each function that will have a cast/hard ref.
Thank you for the input! Good point!
@@polyplayground i got in the habbit of checking my size maps for things I've worked on before calling it a day.
Has really helped my understanding of how refs work and is also making my game leaner and cleaner.
Same vibe as checking your bank account each morning. It hurts, but it's a good habbit 😂
Haha, love it! Yeah always good practice to check size maps, a lot of optimising can be done by checking those
I am an advanced beginner Unreal game dev (and game dev in general). How do I check my size maps? I guess that means the file size of things?
@@VeryTori Right click a blueprint then go to "Size Map".
Another tip, unconnected nodes and textures ARE in that blueprint's memory! I had to clear a bunch of duplicated materials because I had 3 high quality textures in each of them and the game saw those in the size map!
Congrats on the new channel! You have made a great start!
Really appreciate it! Thank you!
Thanks for all the content you made so far. All of them are 10/10. Im new to Blender and UE5 and this stuff helped me very much. Keep up great work!
Thank you! Welcome to the world of Blender and Unreal Engine! Glad it’s helping you!
Quick and effective! Subscribed.
Thank you!
Won't this force hard references for the entire project for each non CPP class you do this with?
Awesome Vid thanks!
No problem!
Is this more optimized way to cast? Can we gain some fps?
Its not. Its still a cast node. And usualy you dont gain fps with cpu calculation optimizations.
And ofcourse using blueprint interfaces is a lot more optimized than casting.
Why should I use Interfaces then?
Because it makes repeated tasks like casting to your character and any other repeated tasks a lot faster 😊👍
@@polyplayground i think you are not getting it. I mean to say I will use Interfaces instead of casting. It can be use for anything anywhere just like function libraries. We can add functions to interfaces instead.
I agree, creating hard references, like when casting, is not a good idea to use in a library. It will increase the size of your blueprints. Instead of that, I would better use blueprint interfaces. In a library, I would use other general functions.@@rabitkhaitu
@@rabitkhaitu You can still (and probably should) use interfaces. In the function library function just use an interface instead. Libraries just save you from creating the same nodes over and over again. Simply a cleaner approach.
@@rabitkhaituInterfaces functions themselves don't have any functionality. It's the receiving blueprint that implements the functionality.
I said some bad words out loud when I saw this! Wife thought that I learned some very bad news or that someone died. 😂. I knew about making functions but this is new to me. Thanks.
This is great for beginners but a function that casts should not be pure and also you should cache the player in a variable
Good tutorial and example with casting, but don't learn to avoid casting. It bloats memory size, is inefficient and makes me wonder why it's even in the engine.
Casting is great when used properly. Check out my long ass comment i made elsewhere on this video, but I go a bit into what casting actually is.
Casting is by far the fastest and most efficient method to communicate between blueprints if used correctly.
If An AC is casting to a blueprint it is added to, then the cast adds no extra memory bloating at runtime and if you cast to a parent class, that is also free memory. The memory map can be deceiving as it doesn't know how you plan on using things, so it assumes nothing.
For instance scene component, or really anything that is attached to FPC that casts to FPC as a part of its functions/events/whatever will show an instance of FPC in it's memory map making it look bloated. However, the memory map is just assuming that it doesn't already have a ref to FPC. when that component is added to FPC as a component, it will already have that reference due to the fact that it's is nested inside of FPC already. It won't load a second instance of FPC into FPC to accomplish that.
However, you need to do this without creating a hard variable reference in the Component, so drag off of the cast input ref and select "get owner" but make sure it's the component variant. You normally have to de-select context to get this one for some reason. If you create a hard ref variable to FPC in a component in FPC I think you will load FPC into FPC. (this is something i'm going to test in insights pretty soon as i'm curious)
You can also cast down the inheritance tree in a similar manner for free. This one is a weird one which i'm just starting to understand. But You can cast to a parent class ref with a child object ref as the input and access stuff inside of the child while only having the memory weight of the parent
This is why proper inheritance and using actor components in a meaningful manner can really make stuff easier on you. As the data flow never needs to reach outside of the BP in order to take that action when you cast.
I love BPIs but if you use a BPI to send a message to something you have a common inheritance to or are attached to. You're reaching out of the blueprint to the bpi, then back into the blueprint. It's slightly more overhead
1.) Use casting when you have common inheritance.
2.) Use BPIs when it's easier for the object sending the message to get a ref to the object that needs the ref.
3.) Use dispatches when it's easier for the objects that need the message to get a ref to the thing sending the message
I say this not trying to be a dick, but in trying to help. Understanding what all 3 of those are on a very deep level has really upped my game and made programming in Blueprint a ton more enjoyable.
A few years ago unreal released a live training video called something like "Blueprint communication Live training" It's the most fruitful 3 hours you'll ever spend on youtube during your UE journey. Really helped me understand that stuff.
@@NaOHNoahyou got more of those tips. I’m trying to learn proper fundamentals, and the information out there is limited or unhealthy for new people.
@@TheFunDimension my tags keep popping off
@TheFunDimension also, it apparently deleted my entire comment 😢
🤔🤔🤔🤔🤔
or don't use bps
lol, seems like someone is upset that game making is accessible and not gatekept behind shitty code and visual studio
@@shrek_yourself Did I strike a nerve lol I didn't say you shouldn't use it just that not using it is a possible way to make better games. Also I started with BP in 2014. Don't know what you mean by shitty code and I don't use VS because it's garbage.
@shrek_yourself oh damn, you got owned. They don't even use VS, they're a hipster who probably uses their own custom compiler, that probably allows them to code in lisp or haskell or some other hipster language instead. You got wrecked Shrek. Give up.
@@NaOHNoah Yes I write cobol in vim and then convert it to UE5 C++. Or I just use Rider lol.
Cut Dev time in half by deleting half of your nodes
Save all your time, delete your project