Hi! So I’m going through my project looking for different optimization and just overall better approaches to things that I had done a couple years ago when I first started this project. Right now, I’m focusing on how to get more out of my blueprint interfaces. In the past, if the player character or player controller contained a component that I wanted to reference, I would just create a BPI to return that whole component. I’ve learned over the past few years that isn’t the best approach for BPIs. So then I was wondering what would be a nicer way to break the BPIs up. For example, I have a BPI that is just for my Player Controller and it allows me to say GetPlayerController->CallToPlayerControllerBPI() and that works fine. However, sometimes it really helps out to be able to pass values as parameters, even maybe a whole component. But that means that any actor that references the PlayerController BPI now has to reference a component that it may not need. So should I just avoid passing in components or actors through as parameters in BPIs, or should I make different BPIs for the PlayerController? Like one that is for quests and another one that’s for the inventory and another for weapons/loadout, etc.? And they would just be labeled something like BPI_PlayerControllerQuests and BPI_PlayerControllerInventory? Any thoughts you may have on this or advice would be greatly appreciated! 
I love these in general and keeps me tidy and organised, lowers my brain memory load on the things that I need to keep in mind. Makes my game dev life easier 
so I don’t have to talk with actors but talk with subsystems in general.
Here is some subsystem since you mentioned inventory and weapons.
So when an event happens like shoot, I have reference to shooting actor already on event to its component etc and I can simply get a component from that reference and check. Can do that with subsystem also however for component referencing I generally do like this. Remove item from component calls players inventory subsystem from code.
I do like this can be better ways ofcourse I am quite new to C++
Interesting. Do you know if this system works in Blueprint only projects? I’m really familiar with C++, but I haven’t done much with using it in unreal projects and I don’t really want to introduce it in if I don’t have to. Thanks again for your help
Generally C++ in subsystems, think there is some plugins for it to use it BP only. Well basically I use sometimes like event system on it so it manages messages too depending on the system.
Interfaces I think like them as gateway generally to push some messages to all listeners without knowing them at all. I use sometimes with enemies still I do the same, generally keep a referencing actor in interface and do job on top of that like get component so I don’t have to put component there. Still I find it hard to utilize them without knowing too much how interfaces work in lower level.
If you are familiar with c++ think should no problem at all for you.
BPI functions passing params specific to the task is a good way to go. It’s mostly macros gathering the data in the core class and passing them on the return. I do this with a lot of mechanics. Controller, Character, weapon classes, loot items, interactions etc.
Just out of curiosity want to ask,
Let’s say I have a HUD message system and some actor from world sends a message to HUD, that puts a text for a while then removes itself.
As an example it says : Discovered Shire.
Can send this message with an BPI or can call a UI subsystem that creates an event for it,
and some script in a UMG processes it.
on cases like this BPI is better? If so why? What is the difference since I am struggling with it aswell and prefer to use events more likely.
Thanks
BPI doesn’t require a fully casted reference. You just need a simple base reference (actor, actor component).
Overlap Event → other Actor → does implement interface → call event
Hit Event → Hit Actor → does implement interface → call event
Let’s take a location discovery event where the pawn overlaps a boundary collision.
You take the Other Actor (pawn/character) and call a BPI function on it. The function would implemented in the character class, which could then use a BPI to call the controller to display the UI message.
I understand, still I don’t think using subsystem requires a cast at all.
You can access a local player subsystem basically from any actor and call an event over there which is being listened by the HUD itself.
Subsystem basically can basically send a message which is being listened on the same event binded on HUD.
Thanks anyway.
EventDispatchers are better, maybe through a central manager if you like.
reason being, the shire doesn’t care about the HUD or whoever else is ‘listening’ (minimap, achievements etc) but the HUD cares about the shire because it has to display the message.