I made a macro to make interface calls simpler. It acts like a cast node without being so expensive. I want to be able to call it anywhere, so I placed it in a macro library with Object as the parent. I noticed that it says error under the interface call. It hasn’t caused any issues yet, and works fine in every blueprint I’ve used it in. Why does it think there’s an error?
A while ago, I believe I tried something similar. I don’t remember the specifics of it, but I recall that I edited the macro once, and that basically broke every instance of the macro. Even restoring it wouldn’t help.
The function version works in blueprints like the HUD, but not in things like Notify States.
Do you know if it’s the call to the interface that’s breaking the macro, or is it the fact that it’s parented to object? Maybe it’s not realistic to try and create something like this that works everywhere?
Why not just implement the interface that returns the needed elements.
If the object has the interface it will work, it it’s missing the interface it will be ignored.
The point of interfaces is decoupling.
If you need any tests then you could check the validity of an important object passed in the interface return value.
Pretty much. It’s over-engineering. Also make sure you take into account which elements that are returned are singletons.
GameState => it lives on the server, client’s don’t have one, you can return the server gameState only. At that point it’s a singleton so no need to grab it though a custom function, just use the “Get Game State” node.
And if you have to call a bp implantation function of you own gamestate bp version then add an interface to it and call the interface on the generic gamestate => it will work
yeah ive heard mixed reviews on whats actually faster between interfaces and casts, that said when you wrap interface calls in blueprint you incur an extra overhead, add in all the extra checks you had to do and its just not worth it.
both have their uses though so dont let that scare you off
