Hi everyone I am looking at tutorials on BP Interfaces and I am just wondering which is faster in terms of engine overhead Casting or Interfaces?
Something tells me a BPInterface would be a lot better to use and easier on the engine than Casting but I just want to make sure before I start doing everything with Interface BPies.
Are there some things you should always use Casting with and some things you should always use Interfaces with for example?
Is it a good strategy to abandon Casting completely and just do everything with Interfaces or is that a bad idea?
The reason why I ask is it seems more work to set up an interface than adding a Casting node so I guess I am just wondering why not just use a Casting node? Is Casting “heavier” for the engine to handle than an Interface or is it simply a matter of you save time in the long run if you have a lot of cross communication going on between BPies?
I would say that most people use casting in their tutorials, because it’s just easier to set it up, makes the tutorials easier to follow along etc. But as everything else with UE4 it all depends on individual needs. If you need to cast a lot then it might be better to look for an alternative solution. In terms of one being faster then the other I do not know the answer as I am not that advanced with the engine myself.
And if you need more theory behind Interfaces as a programming language feature take a look at C# interfaces, or Delphi Interfaces to have better understanding how and when to use them.
So lets say I want to eliminate the level BP altogether … how would I deal with standalone triggers and actors? There doesn’t seem to be a way to create an “onactorbeginoverlap” inside the node graph of a Pawn Class BP or even a reference to a standalone trigger or object.
I was thinking of putting all triggers on their own BP so then it would be easy to cast in between them and other BPies but I don’t know if that would be overkill or not.
Or is it common practice to still use the level BP in cases like that?
Depends. If your actor is static level BP is enough.
if your actor moves, then the interactions should go with.
To get a pawn to have some sort of trigger you just create a mesh of any type on it, set it to invisible and create a custom on begin overlap event for it.
Be warned, you need to make sure your collisions are set up correctly - and that the pawn ignores that collision.
There is and there are a few ways to pull it off and they’re pretty much indispensable. Below, whenever *anything valid *overlaps the Opponent, the player will know who was overlapped by whom, even though the player was not the instigator.
[HR][/HR]
Imagine a game that is completely procedurally generated and there’s absolutely nothing in the Level Blueprint, so doing the above also does nothing. Since you do not have references to the pickups that will be randomly popping up, there’s nothing to register at Begin Play. But you can register events dynamically as the objects are spawned (via Actor from Class). This can be done by the blueprint that spawns them (like an item generator responsible for binding and unbinding), by the player, or you can have functionality in the spawned object itself hooking up its elements to a relevant framework class.
As you spawn objects, you register their events and use additional dispatchers if the components’ are not enough and you need to send more data. [HR][/HR]
Not an overkill at all - and in many cases no casting is required. Or you cast only once when the object is spawned to register something inside or set up a dispatcher. Casting is often required when you go heavy on the inheritance. You have a base Pick-up class and several sub classes with unique functionality. You call talk to the base class and call Collected and all children subclasses will know what you’re on about. But when you need to talk to a specific child class and call something unique to them only, you’d need to cast.
What I mean is a Pickup that repairs your ship and a Pickup that is a trap that destroys your ship. They share the same base class and both can be picked up and float about in space (I *know *about your cool little drones o_O), but they do something fundamentally different.
I’ve been using Interfaces for classes that are completely unrelated. Not sure if that’s the right way to do it, but it has worked well for me so far.
The common practice is picking the right tool for the job and eventually you’ll be casting, dispatching events and calling interfaces functions. It’s hard to tell (for me) what works best for what unless you have a specific scenario in mind.
Great info thank you. Yes makes sense. No “safe strategy” one just has to venture into this and figure out the best way I guess. Think on your feet.
Kind of already stated - but a huge benefit of interfaces over casting is the decoupling of dependencies it provides.
A lot of casting can result in a hierarchy of dependencies that must be resolved when that asset is loaded. This directly impacts load times and memory footprints.
It can be enlightening to use the sizemap (right-click on asset). Casting causes hard dependencies that will result in fairly huge size maps…
imo prefer interfaces over casting unless the objects are always dependent and coupled.
In addition to what was already said about memory usage, which is the biggest issue, I just wanted to add: NEVER cast in any of your Behavior Trees. That includes Decorators, Services and Tasks. It causes a circular dependency that doesn’t throw an error right away, but will break randomly and corrupt your behavior tree. This is a known issue.
Think on your feet.