I’m trying to implement a new GC system where my GC manager actor keeps a list of stuff to delete.
I thought to use interfaces so that any actor could communicate with my GC manager (basically send over the actor they want to add to the list) without having to cast or already have a reference to the GC manager actor.
After hooking everything up, I found this error message: “Message node AddToGC must have a valid target or reference to self.”
Realizing that I still need to hook up a reference to the GC manager in the “target” input node made me ponder the question: why in god’s name would I use an interface when it is functionally no different from calling a function or a custom event since I still need to go through the trouble of fetching it during runtime?
Unfortunately, I can’t seem to find any good reasons. They all seem to boil to “because” or “Well [something about C++ that does not seem to apply to blueprint]”.
The only somewhat valid reason I found was in the event that multiple classes might share a function that expects to execute the same logic, but that seems like encouraging objectively incorrect OOP adherence. Just make a child class in that case.
Can someone please explain my pea-sized brained self what the point of these darned things are? And how can I achieve the very simple task of being able to send data over to my GC manager reliably without the performance and extreme danger of a failed cast that having to fetch this stuff in real time so it can be stored and then referenced poses.
Yes, interfaces still need a reference, but unlike casting, you don’t have to specify the specific target class. It saves memory and is generally easier to implement.
For example, if you have a ton of interactable classes inheriting from actor class, you can call actor and it works.
If you cast it, you’d either cast a bunch of BPs or have to make a base Bp as the parent.
Performance wise, there is no limit. It is Unreal, after all. The GPU bottleneck is so large that no amount of casts will decrease performance. But what I’m more afraid is of failed casts, or a race condition happening in the gap between an object existing and it fetching a reference to an object it needs to interact with.
Various. Some are static meshes, some are blueprint actors.
My current GCManager actor has two function interfaces:
Add item to a list to be destroyed (usually a mesh, but it takes in generic actors to be more flexible)
Add physobject (actor class) to a list to then be reset (instead of deleting, we call a function in that actor to reset its position)
Then, when a game round ends, a custom event executes that operates on those two lists.
I’m really hoping to find a way to just broadcast an actor to be send to the GCManager without needing to do stuff that could (for whatever reason) fail.
Second list you could manage with a dispatcher. Trouble with dispatchers is you have to know the type of object you are binding to, but apart from that, one call will notify all bound actors.
First list you will need to manage. If you don’t want to get a ref to your GC, you can use something like the game instance. Yes you have to use ‘get game instance’, but then it’s a generic type, and you can call your interface on it, without causing any tight coupling. So some way of talking to your GC from the game instance, or just putting the code in the game instance would work there.
imho i find interfaces of little or no use.
i rather use inheritance and polymorphism. is much more powerful.
the only case where interfaces would be valuable to me, is if for some weird reason i need to share a function api across different classes, and i can’t make them child of a specific class.
which in several years of working with ue i have never needed to do.
casting is tentatively faster than interfaces btw, is actually really fast. if you dig the code, the interfaces does a ton more work.
if you work on cpp the “class does not needs to be loaded” is not important, since, afaik, cpp classes are always loaded.