Compiling object based blueprint invalidates all references

Development Programming & Scripting
1

Steps to reproduce:

I. Create a class based on object (UMyObject) with the EditInlineNew modifier

UCLASS(Blueprintable, BlueprintType, EditInlineNew, Abstract)
class BUGTESTPROJECT_API UMyObject : public UObject
{
	GENERATED_BODY()
};

II. Create a C++ actor child class (AMyActor) with an UObject (or UMyObject, doesn’t matter) Instanced member variable:

UPROPERTY(BlueprintReadWrite, EditAnywhere, Instanced)
UObject* MyObject;

III. Create two Blueprints: one as a child of AMyActor(BPMyActor), one as a child of UMyObject(BPMyObject)

IV. Create some variable in the BPMyObject (I created a public bool)

V. In BPMyActor choose BPMyObject for MyObject in the details panel. Variables of BPMyObject can be edited here.

VI. Open BPMyObject again, and recompile it

VII: Check BPMyActor: the reference to BPMyObject became invalid - it is called “REINST BPMy Object C 38” now, and it has to be reset manually - BPMyObject has to be selected again.

2

The main problem is the fact that all the variable values of the UMyObject instance are lost.

I have a rather complicated UObject based class hierarchy. I use them to define behaviour - I can select different UObjects from the same parent and setup some variable. This way I can build my building blocks in C++ and have really much freedom how to use them in blueprint.

This bug kills the whole idea, and I am not sure how could I achieve the same thing avoiding it.

I try to organise stuff in a way that the actual BP is not need to be modified at all, but I don’t really feel safe with this.

Btw. if UMyObject does not have a blueprint child and I use it in C++ only the bug does not happen. But I want to have blueprint enums in the system - they are handled as uint8 in the C++ level, I have a blueprint implementable function uint8 GetValue().
This way I can use the same C++ base with different blueprint enums.

3

Hey -

The REINST issue when compiling blueprints has come up before however is unlikely to be fixed as there are workarounds to continue using the information from your UObject blueprint. That being said, if you are having problems accessing the information from your BPMyObject, I found that by marking the actor member variable as a TSubclassOf you are still able to set the variable value in the actor blueprint to your BPMyObject blueprint. Even if BPMyObject is compiled, it does not cause the reference to show as REINST and is still usable to access variables declared / set inside BPMyObject.

The following screenshot is from my BPMyActor where “Ref Num 2” is a TSubclassOf declared in code and the “New Var 2” float is a variable declared inside BPMyObject.

109892-tsubclassof.png
109892-tsubclassof.png1073×159 53.1 KB

Cheers

4

Hey,

Thanks for the reply.
Unfortunately TSubclassOf does not work with “Instanced”.
This makes the workaround really bad in my case.

Normally I would have a few arrays, all with different UObject instances. I can setup default properties for them in the detail panel for every actor. Then I place my actors in the level, and I can edit the values for the different placed actors.

I could initialize the arrays in the begin play theoretically, and I could create bp actor member variables in order to modify the values for the different actor instances, but that’s really a huge overhead in my case. The whole stuff would be too much work to create and too hard to .

I would be really happy if something could be done about it - as it is now I still consider having the old way and praying that the blueprint is not changed.

Still it is kinda scary, and I am a bit afraid that an engine update or something could force the bluerpint to recompile… and everything is lost :frowning:

5

I went ahead and entered a report for the specific case of the blueprint variable showing “REINST” after a compile that you can follow here: Unreal Engine Issues and Bug Tracker (UE-37023) . You can track the report’s status as the issue is reviewed by our development staff.

Cheers

6

I see the scheduled fix has been pushed back again. Please fix this - it’s been around so long and destroys what would otherwise be an excellent workflow for exposing elements of a complex system to designers.

7

I see the issue (Unreal Engine Issues and Bug Tracker (UE-37023))
is fixed for 4.17.

I’m having the problem right now and 4.16 has just been released. Can the solution in-engine be shared so that we can still work until it’s officialy released or simply push has a patched?

8

Hey Fawar-

The github commit for this fix is https://github.com/EpicGames/UnrealEngine/commit/6b6401e9689fc681812f0503b7002d41f375b45f . The specific fix appears to have been made in BlueprintCompilationManager.cpp . You can find it by clicking Browse Files in the top right of the page and navigating to Engine/Source/Editor/Kismet/Private/BlueprintCompilationManager.cpp. Merging this file into your engine should fix the issue for you locally.