Asset reference in Child Blueprint is not loaded properly in Editor in 5.5.4

Hi there,

I found out an issue that under certain situation assets in Child Blueprint (Inherit from another blueprint) is not loaded properly.

I have uploaded a repro project, so I’ll describe the problem based on that repro project.

Preparation / Description of Repro Project:

  • Have two StaticMesh assets with the SAME name but under different folder:
    • Content/Asset_1/TestCube
    • Content/Asset_2/TestCube
  • Assign a different material to one of the Asset_2/TestCube

[Image Removed]

  • Create a blueprint inherited from Actor, name it BP_Parent.
    • Add StaticMeshComponent, and assign StaticMesh as /Asset_1/TestCube
  • Create a blueprint inherited from BP_Parent, name it BP_Child.
    • Assign the StaticMesh property as /Asset_2/TestCube.
  • Save everything and close the Project.

Repro Steps:

  • Open the project, open BP_Child and click Open Full Blueprint Editor.
  • You can see the static mesh reference becomes /Asset_1/TestCube instead of /Asset_2/TestCube.

[Image Removed]

  • Now if you close the project and open it again.
  • This time open either /Asset_1/TestCube or /Asset_2/TestCube, to make sure one of them is loaded
  • Then open BP_Child and you can see the Static mesh is properly loaded as /Asset_2/TestCube

[Image Removed]

Investigation

In UInheritableComponentHandler::ValidateTemplates(), it is checking IsRecordNecessary for each component.

And when it is checking StaticMesh property for StaticMeshComponent against the template (BP_Parent), because both StaticMesh assets have the same name, it needs to check Deep Comparison in FObjectPropertyBase::StaticIdentical.

However, either /Asset_1/TestCube or /Asset_2/TestCube is fully loaded at this point. StaticMaterials which should be the only difference, is empty for both of them. Deep comparison will return true, and eventually IsRecordNecessary returns false and cause the problem.

We also see this issue in cooking process as well, but this is the easiest repro case we found.

Thank you!

Hello [mention removed]​

Thank you for reaching out and bringing this issue to our attention.

I was able to replicate the described issue.

I’ll investigate some more and let you know.

All the best,

[mention removed]​

Hello [mention removed]​

I have good news: While testing the issue against other engine versions besides 5.5, I’ve noticed that it does not reproduce on 5.6 and 5.7.

Let me know how you are going to proceed: you can either update to 5.6 once it’s out, or I can fetch you a CL that fixes this issue, and you can incorporate it into a local, source build.

All the best,

[mention removed]​

Hi [mention removed]​,

Great to hear it is fixed in 5.6 and above!

Since we do not plan to update to new version in short term, it would be great if you can point me to the CL that resolves this issue.

Thank you for the help!

Hi [mention removed]​

In that case we will change our data to avoid this issue until we are able to update to 5.6.

Since this only happens for assets with the same name but under different directory, renaming the asset will get us through.

Thank you for all the help!

I think we can close this issue.

Hello [mention removed]​

Sorry for the late reply.

I’ve been searching for the particular CL that fixed this issue, but as I could not find an issue report on the issue tracker site, this was likely fixed indirectly, as a byproduct of another change.

The best way to find the exact CL would be to bisect between 5.5 and 5.6 until reaching the actual change that fixed it.

I don’t have the capacity, but I can escalate the case to Epic, as they might be able to help you with that.

5.6 is already out, so you might also consider updating to the latest version.

Let me know how you want me to proceed.

All the best,

[mention removed]​

Hello [mention removed]​

Thank you.

I’ll close the case.

All the best,

[mention removed]​