Blueprint compilation fails with nested instanced fields

Development Pipeline & Plugins
, ,
1

After integrating 5.5 we’ve encountered a bug during Blueprint compilation where nested instanced fields fail to correctly update their internal references. This causes them to point to outdated object instances after reinstancing, which is breaking our pipeline. This issue is a major blocker for us, as we’re currently unable to work with Blueprints that rely on this feature.The problematic property looks something like this

UPROPERTY(Instanced, EditAnywhere, NoClear, BlueprintReadOnly) TArray<TObjectPtr<UCustomField>> CustomFieldList;There are a few similar reports already on EPS, like: [Content removed]

It looks like the problem originated with this commit:

https://github.com/EpicGames/UnrealEngine/commit/d042e6634e23fb74b9ed2df75c23950d27de3fe2

Reverting the commit or replacing

for (const auto&amp; Pair : OrderedListOfObjectToCopy) with

for (const auto&amp; Pair : CreatedInstanceMap) in BlueprintCompilationManager.cpp resolves the issue on our end. Another suggestion we’ve seen (in the EPS thread above) is to set

Options.bReplaceInternalReferenceUponRead = true;globally for every object it processes. (Move it above the if).

Do you have an official fix for it, or would any of the above solutions be considered safe to implement as a hotfix in the short term?

2

Steps to Reproduce

3

Hey there,

Would you happen to have an isolated repro project that we could look at? This would help in tracking down the issue.

Kind regards,

Julian

4

I also happen to have a similar issue. Here’s my case: There is an ActorComponent in an Actor blueprint, and this ActorComponent contains an Instanced TMap<FName, UDamageData>. Every time I restart PIE, there’s a high probability that the data inside the TMap fails to be properly serialized. My temporary workaround was to change the creation of the ActorComponent from being created in the blueprint to being created in the C++ constructor, which seems to have resolved the issue. I can’t upload our project’s engineering files, but when I tried to reproduce the problem with a minimal Unreal project, I failed because it’s an intermittent issue.

5

I would be happy to debug this, but to debug it I really need a repro for it. If you guys could give me a small sample project that would be awesome.

6

We are working on a band aid fix at the moment to unblock our content creators, but once that is in place we will try to reproduce this and create a sample project. The places it currently breaks in can’t easily be ripped out unfortunately.

7

Ok thank you and please provide an example as soon as you can :slight_smile:

8

Hello Maxime!

After applying the band-aid fix, we investigated the issue further and it looks like we’ve found the root cause. I’m leaving the details here in case someone else runs into this, as it might provide a helpful hint.

The issue originated from our custom tool that serializes nodes in a graph editor. We weren’t setting the correct reference flags (RF_Public) on the nodes, and while this worked up until 5.4, it started causing problems after the upgrade.

From what I gathered, when compiling a Blueprint that contained these nodes in a nested field, the process in 5.4 happened roughly in three steps:

1. Process the Blueprint itself – missing references at this point, as the nodes without RF_Public weren’t found.

2. Process the field that contains the nodes.

3. Process the leaves (the nodes themselves).

We were fixing the missing references during the leaves step (CopyPropertiesForUnrelatedObjects), so even though the BP step didn’t have the correct references, it worked since we resolved them later.

This behavior changed in 5.5 with CL32291623 - “Fix ordering of copy when reinstantiating, going from the leaves to the root.”

Now, the order is:

1. Process the leaves (the nodes themselves) – references are present.

2. Process the field that contains the nodes.

3. Process the Blueprint itself – here, the nodes without RF_Public still aren’t found, and since the leaves step has already run, they remain missing.

This might not be exactly what happens under the hood (and please feel free to correct me if not), but it’s how I understood (and simplified) it with the time we had.

The solution on our side was to update the nodes to have the correct flags (RF_Public) and to ensure our tool sets these flags properly going forward. After doing this, the Blueprint step was able to find the references correctly, and everything is now working as expected.

9

Ok thanks, we will take a look at this and try to see what can be done. But if the problem was missing RF_Public, seems that is the root of the problem.