Nativize blueprint fails with C++ interface

With 4.16 preview 1 and 2, we are getting the below error when trying to nativize (Exclusive method) certain blueprints which inherit C++ interfaces (seen below).

We have not been able to re-produce the issue in a new blank project but we did not see these errors in 4.15. In 4.15 we had a different issue with nativizing UE-42676.

The output log error does not make much sense to us, because our c++ interface is not set as a pure virtual function. This seems like a new engine bug? If not do you see anything wrong on the interface declaration code? Normal packaging works fine.

Thanks!


Nativize Error from Output log:

UATHelper: Packaging (Windows
(32-bit)): Cook:
LogBlueprintCodeGen:Error: BP
/Game/Gameplay/Galaxy/PlanetarySystem/BP_PlanetarySystem.BP_PlanetarySystem
is selected for nativization, but it
cannot be nativized because it
currently implements an interface
class
(/Script/GalaxySample.HasPlanetaryHostManager)
that declares one or more pure virtual
functions.

The C++ Interface is defined as:

IHasPlanetaryHostManager.h

#pragma once

#include "Interface.h"
#include "IHasPlanetaryHostManager.generated.h"

UINTERFACE(MinimalAPI)
class UHasPlanetaryHostManager : public UInterface
{
	GENERATED_BODY()
};

class IHasPlanetaryHostManager
{
	GENERATED_BODY()

public:

	UFUNCTION(BlueprintCallable, BlueprintNativeEvent, Category = "PlanetaryHostManager")
	class APlanetaryHostManager* GetPlanetaryHostManager() const;
	virtual class APlanetaryHostManager* GetPlanetaryHostManager_Implementation() const { return nullptr; }
};

IHasPlanetaryHostManager.cpp

#include "GalaxySample.h"
#include "IHasPlanetaryHostManager.h"

Hey Raf-

After copying your interface into a local project I was unable to reproduce the failed package as well. Are you using the interface in multiple blueprints and only specific ones are giving an error message? If so, can you try transferring the interface class and affected blueprints to a new project and let me know if that packages or not? Additionally, can you provide the full log from the package attempt as well?

The interface is used in multiple blueprints and I believe all of them are giving the errors. I moved a couple of blueprints to a new project but it nativized fine with the corresponding c++ interface. So I don’t know why it won’t work with the real project except there are many more interconnections between the blueprints and many files use the interfaces. Our project is very large and was started with UE4.6 and a lot of the classed are c++ based and blueprints derive from them.

Note that we could not nativize in 4.15 either but the errors were different and there was the issue UE-42676 which affected our projected so we have been waiting for 4.16 to try nativizing. I’ve attached the log with 4.15 packaging as well in case it helps.

link text

Are you attempting to package through the editor or from the command line?
If you’re compiling from the command line, can you provide the full list of arguments you’re using? Additionally as a test, could you comment out either/both of the functions in your interface and then try to package?

We have been packaging through the editor.

After several attempts and a few changes we have managed to nativize a standalone Blueprint inside our project with all our C++ interfaces added to it.

Fix1: We had to replace the virtual implementation from using TSubclassOf to UClass* , interestingly we were able to leave the c++ declaration as TSubclassOf so we still get the benefit in Blueprint of filtering the class and no changes required to existing blueprint using the interface. See below.

BEFORE:

	UFUNCTION(BlueprintCallable, BlueprintNativeEvent, Category = "Tech")
	TSubclassOf<class UTech> GetTechClass(const UObject* FromObj = nullptr) const;
	virtual TSubclassOf<class UTech> GetTechClass_Implementation(const UObject* FromObj = nullptr) const { return nullptr; }	

AFTER:

	UFUNCTION(BlueprintCallable, BlueprintNativeEvent, Category = "Tech")
	TSubclassOf<class UTech> GetTechClass(const UObject* FromObj = nullptr) const;
	virtual UClass* GetTechClass_Implementation(const UObject* FromObj = nullptr) const { return nullptr; }

Fix 2: The other case, had to do with the interface function requiring an array return paramater in blueprint but the blueprint compiler wasn’t enforcing it, letting you compile it but failed when nativized. Below is the interface function.

UFUNCTION(BlueprintImplementableEvent, Category = "Planet")
TArray<class AUnitPawn*> GetAssignedDefendersUpdate() const;

We can’t run a nativized executable to test further (crashes immediately) but that’s due to another issue we have identified in 4.16 (I’ll open a separate report since it has nothing to do with this one). Once we get past that I will test further and see if we still get the original error reported with our other blueprints marked for nativizing. Thanks again!

I tried adding the BEFORE section to an interface however I did not have any issue with packaging after enabling blueprint nativization on a blueprint that used the interface. If you are able to provide a sample project that demonstrates the behavior your seeing it would also be helpful. It sounds as though you were able to find a solution to your issue by updating the code, however a sample project would still help me investigate the issue on my end.

Here is a sample project. I had to spawn the BP actor class implementing the C++ interface into the level to reproduce it.

Open the main map level blueprint, this is where I am spawning the actor. If you remove the spawn on BeginPlay it will nativize without issue.

link text

Hey Raf-

Thank you for the sample project. It appears that the virtual function that returns a null pointer is the cause. If you change the function signature so that a null pointer is not returned the project can then be packaged successfully. I have entered a report for the difference in behavior from other engine versions that you can find here: Unreal Engine Issues and Bug Tracker (UE-45171) . You can track the report’s status as the issue is reviewed by our development staff. Please be aware that this issue may not be prioritized or fixed soon.

Cheers

Doug Wilson