We discovered an odd issue with Mutable in UE5.7 first and then I could reproduce it in 5.8 now as well.
When creating a Mutable setup with nested Child COs, COIs can result with Editor-Only references, which will cause the COI not appear in the build manifest and the appearance to now spawn in game.
Example Setup:
CO_Main -- Adds a Cube SK; Adds a ‘Children’ Object Group
CO_Child -- Adds another SK to the Cube SK Component and attaches itself to CO_Main
When creating a COI from CO_Main the reference to CO_Main for Game and Editor exist -- all good.
When creating a COI from CO_Child the reference to CO_Child is Editor-Only -- it will not appear in the build.
When updating CO_Child to not attach it to CO_Main, existing COIs do not update. They still remain with Editor-Only references.
In UE5.7 I could create new COIs and those new ones would have Game references. In UE5.8 even new Instances would only have Editor-Only references.
Not knowing which COs would create proper COIs that would build and which COs and COIs would have to be re-created because they are missing Game References causes us some trouble. I included a test project with the setup and a demo video to hopefully reproduce the issue on your side too.
Could Mutable either not allow creating COIs from Child COs, or could the references get fixed to mark any CO references as game references for the build?
By design, Instances built from ChildCustomizableObjects are meant to be engine-only, but I can understand the workflow issues you’ve run into. I’ve logged an issue you can follow here: https://issues.unrealengine.com/issue/UE-391214
InUE5.7I could create new COIs and those new ones would have Game references. InUE5.8even new Instances would only have Editor-Only references.
To address this, you need to resave all of the instances related to the CO and then recompile and save the CO. This should rebuild the game reference.
If you hover over a CustomizableObject, there is a property “IsRoot” that denotes if it is a child or not. 0=a child customizable object, 1=a parent CustomizableObject. Theoretically, you can hook into that to add a badge or colour change to denote that a customizable instance is a child or not; this could prevent people from building new COIs from that, but if a customizable object’s status changes, instances built from that will be tougher to update. We’re discussing this as part of that bug above, and hopefully we can make it better, but you might want to consider writing some asset validation tools for this issue.