Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

Unable to implement a C++ interface in Blueprint?


Loving the C++ reflection facilities of UClass/UObject. Very cool that an object can provide implementation either through native code or through Blueprints.

I have however what looks to be a restriction in code, one that prevents these features working out to their beautiful conclusion.

I have declared an interface with a function in C++. I can specify in the Blueprint editor that my blueprint should implement the interface. I can see the function, and can provide a blueprint implementation.

All good so far. The problem comes when I try to use the interface in C++. It is my understanding that InterfaceCast<> is the correct way to resolve an interface pointer from an object. In my use case this function always results in a nullptr result, even though in the debugger I can see the interface I need nested in my UClass struct.

I took a look at the code in InterfaceCast<> which calls into UObjectBaseUtility::GetInterfaceAddress. The issue is here:

 // Script interface
 if ( !InterfaceClass->HasAnyClassFlags(CLASS_Native) )

So if you have an interface that is defined in code you do not even bother to check to see if there is an implementation provided by script. I copied and modified this code, removing the CLASS_Native check and making it so that the // script interface query only returns a valid interface if can match to an interface with bImplementedByK2 set. Having done this, everything works as expected.

This code change is seems kosher and it enables the desired ability to define a code interface, perhaps even with a default implementation, and to be able to specialise it in blueprints. Mix-in magic.

So I guess the question is: Is the current state of the code an oversight/bug or is it a feature? I could well imagine the code is in this shape because modifying it in this way creates the potential for interfaces which have mixed native and blueprint implementations and maybe there are assumptions made elsewhere in the code that an interface will either be 100% native or 100% blueprint? This is just a guess though - maybe it's fine?!

Please let me know!


Product Version: Not Selected
more ▼

asked Dec 02 '14 at 01:35 PM in Bug Reports

avatar image

26 2 6 10

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

1 answer: sort voted first

Hi Joss,

Are you still having trouble with this in version 4.6? InterfaceCast has been deprecated in this version, and we recommend using Cast or dynamic_cast instead.


more ▼

answered Dec 08 '14 at 03:41 PM

avatar image Tim C ♦♦ STAFF Dec 31 '14 at 11:56 PM

Hi Joss,

We have not heard back from you for a little while. Do you still need any assistance with this issue? I will be marking this issue as resolved for tracking purposes, but if you still need help please feel free to re-open it.


(comments are locked)
10|2000 characters needed characters left
Viewable by all users
Your answer
toggle preview:

Up to 5 attachments (including images) can be used with a maximum of 5.2 MB each and 5.2 MB total.

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question