Alright, so: first of all thank you Dynamiquel and MagForceSeven for your help and insights <3
This is not a solution, but a summary of what to expect and the choices to make. There is no solution because its something Epic has to work on… (dont expect it to happen tho) or someone else maybe find a hack around.
Its a fact that cpp interfaces implemented in blueprints will always cast to null, see links below for why.
Sure there is another method to see if they implement the interface and use the interface’s methods… and these are reliable no matter if implementation is BP or CPP.
But there’s nothing safe for casting.
So if you got an actor by raycasting and a method that takes an interface, and want that method to take it: you can’t do nothing (well, you may still make another method that takes an actor, but thats what we’re trying to avoid).
From here on, you can make one of these 2 choices for your project:
A. NEVER implement interfaces in blueprints.
B. Implement interfaces in blueprint whenever.
(These are for good practices and consistency reasons).
I’m very noob on this and still have to grasp the full extent of these decisions, if you have insight, please share!
Why A:
- Allow methods to enforce the usage of Interfaces as parameters. ie.: DoSomething(TScriptInterface& v). This is awesome because you never have to cast and verify at runtime, thus saving headaches. IMHO this is too useful.
- Although blueprint ‘BP_Coconut’ may never directly implement an interface, you can make a cpp class ‘CPP_Coconut_base’ that implements the interface and then BP_Coconut can override these methods.
- Works for casting to interfaces!
- Never have to think if method M takes paramer P with interface I and if passed parameter P implements interface I. You cant go wrong, “the master works hard”*1.
Why B:
- Freedom of implementing interfaces in BPs without a cpp overhead. Depending of your project, this may simplify work and readability.
If B: - Never cast in cpp (not an issue if none of your methods take interfaces)
- Never declare methods exposed to blueprints with explicit interfaces (always take in uobjects and verifiy at runtime)
*1 Sorry, those who know, know.
Good reads about interfaces by these fine fellas <3