I saw this tutorial about how to use a blueprint interface instead of casting to my player character for better memory management, and it works great.
The thing is, I have this blueprint that just contains a bunch of events and function that different blueprints can then cast to and use.
So this main blueprint is like a main brain that the other blueprints can use.
But each blueprint that uses it has to cast to it and thus load it into memory.
Is there a way to use BP interface in that scenario?
The player’s BPI can be accessed with the ‘get player character’ node, but how do I access a BPI that is not the player character’s?
• casting to framework (pawn, character, game mode, controller) is cleaner than using an interface.
• casting to your Brain is fine; again, it’s already loaded anyway. You can’t optimise anything like this.
There is a misunderstanding. You’re not accessing the interface here. You are accessing the pawn who may or may not have an interface implemented. To me it sounds as if you had an issue with obtaining actor references.
And yes, you can interface message any actor - that’s the main reason interface comms exists. You do need a reference, a target instance.
Interfaces shine when you’re trying to talk to actors and you do not know what actor it is. Especially when you want to comunicate with various, often unreleated classes. Imagine a player walking around and pressing E to interact. They will spam it on everything - that’s the job for the interface comms.
Hi @ClockworkOcean ! Thanks for the reply! Can you give an example of what you mean? How do you use an actor ref?
Do you mean get an actor by class?
Because if so, isn’t that just like casting anyway?
casting to your Brain is better; again, it’s already loaded anyway. You can’t optimise anything like this.
Why? I mean, it’s a pretty big blueprint and when I do ‘show map size’ on the other blueprints that use it, it seems they are added over 1GB of data just for loading it into memory. And I have like 3 blueprints that use it at any given time.
Surely using a BPI is better for something like that?
Or is there any way to reduce the strain on memory?
Let’s say you have a BrainBP, and another OtherBP want’s to talk to it using an interface.
In OtherBP, you make a variable of type ‘actor’ ( not BrainBP ). Then you can send and receive interface messages to your hearts content, without using a BrainBP type reference.
If your BrainBP is in the level, you can set the actor ref in OtherBP using the eye dropper tool, all done.
If you are spawning the BrainBP, or for some reason need to setup the reference at runtime, you can use ‘get all actors with tag’ to get an actor reference. ( So you need to make sure the BrainBP has the actor tag ).
Does it make sense?
Also, any reference type that comes with the engine ( like get player character ) comes for free, it won’t make a hard ref, or unnecessary dependence. Good examples are the game mode, game instance, player controller, and so on.
Regarding your conversation with @Everynone, if you are always going to using BrainBP, there’s no real need to talk to it with an interface, because if it’s always loaded, there’s no point in trying to avoid loading it ( it only gets loaded once, not for every reference ).
@ClockworkOcean thank you for the detailed explanation! Yes, that does make sense!
One thing I’m still confused about:
if you are always going to using BrainBP, there’s no real need to talk to it with an interface, because if it’s always loaded, there’s no point in trying to avoid loading it ( it only gets loaded once, not for every reference ).
The tutorial that I saw about BPIs said that using a BPI to communicate with the player’s character is better memory management than casting to it.
But if I understand you, you say that it doesn’t make a difference? Because the player’s character is loaded anyway as well, isn’t it?
The way the tutorial presented it was that because every blueprint that needs to cast to the player’s character has to load it into memory, it is getting loaded multiple times as part of each blueprint that does that.
Is that not the case?
If not, then what’s the point of BPIs?
And if it is the case, is it not also true for my BrainBP? So wouldn’t it be better to have an interface instead of casting to it or using ‘get all actors by class’?
Sorry to bombard you with questions, just trying to wrap my head around this memory management issue.
It will not be loaded multiple times, as Clockwork clarified previously, only once (regardless of the number of references to it, so long as that is > 0).
Context is very important here, and not knowing the details of the tutorial you followed we are probably not in a position to comment on the accuracy or otherwise of it.
If your player can switch characters, and the ‘old’ character is removed (not taken over by an AI, which will keep it loaded anyway) then the interface suggestion is still good.
If you have only one character for your player, then as established by others above: interface == pointless indirection.
The last paragraph of Evernone’s reply describes an example that demonstrates the ‘point’ of them, to flash that example out a bit, your game may have, let’s say, 50 ‘things’ that can be interacted with (types, not instances, so all doors are one of this number). There a two super good reasons why you would want to use an interface here:
If you were casting you would need a ‘cast chain’ with 50 casts. I hope it is obvious why you would not want to do this.
If any given level only has X of the interactable types, all 50 of them would be loaded anyway because of your cast chain.
So the interface is a win both for your sanity, and for memory usage
Now, it is very possible that he just gives that example as a demonstration and I misunderstood, but to me it sounded like he says that every blueprint that casts into the player’s character loads it into memory and becomes huge because of that.
Are you guys saying that is wrong and what he does in this tutorial is actually pointless?
And if so, are there any other technics I should know about for optimizing memory usage?
I guess he should get points for trying, but based on the first 2 minutes this video is about as good as his others
One actor referencing another actor does NOT include that referenced actor within the first, it just means that other actor will be loaded if the first one is. If the referenced actor is your character which is always going to be loaded anyway, it means nothing.
That memory map is not showing how big the object is, it is showing how big the object AND all of it’s dependencies are. Hard references do not bloat the source object, they just cause the referenced thing to be loaded (which may bloat your game, if that thing did not otherwise need to be loaded).
I can only speak for myself (and I didn’t watch the whole thing): My answer is yes.
Use interfaces (When the referenced thing is not going to be loaded all the time anyway).
(When the referenced thing is not going to be loaded all the time anyway).
