We found a bug with the compilation of the CO which references Customizable Object Macro Libraries. The CO once compiled doesn’t automatically pick up subsequent changes to the Macro Library assets that it references, specifically the FCustomizableObjectEditorModule::IsCompilationOutOfDate() returns false.
The root cause of this is the fact that FCustomizableObjectEditorModule::GetParticipatingObjects() doesn’t pick up the reference to the Macro Library asset.
I believe handling of the UCustomizableObjectNodeMacroInstance node is missing from this function. Adding the following code to FCustomizableObjectEditorModule::GetParticipatingObjects() fixes the issue.
Steps to Reproduce
Create a UCustomizableObject which has a UCustomizableObjectNodeMacroInstance node in its graph, which points at a UCustomizableObjectMacroLibrary asset .
Modify the Macro Library asset and save it and notice that the CO does not automatically pick up that modification ( it’s compilation thinks it is up to date ).
There are a couple of idiosyncrasies that happen with macro libraries (you need to refresh the node for pin updates, a minor update of the node doesn’t indicate that the CO needs to be recompiled with the star asterix), but if something internal in the macro is updated, it is picked up during compilation. Those other issues should get addressed by the team as Macro Instances mature.
Do you have a more complete repro example that you’re seeing, and what you would expect to happen exactly? It is possible this has been addressed in 5.7, which saw a significant number of updates around Dataless Mutable tools like this.
> but if something internal in the macro is updated, it is picked up during compilation
That is the use case I was describing. Without opening the CO, change something internal in the customizable object macro library asset (COML) and save it. Then open up the CO in the editor and the compilation which gets triggered automatically for preview doesn’t pick up that change, it thinks the previous compilation is still up-to-date because COML is not in the list of dependencies. Manually clicking the Compile button forces a rebuild so that will properly pick up the COML changes, but the automatic compilation should be savvy to pick up this change also.
We are currently on UE 5.6 so it is possible that 5.7 has some other fixes for this that I haven’t found yet, but seem like the root cause of the problem is the function which gathers the dependencies of the CO, because it thinks that COML is not a dependency. We fixed that issue on our end but I just wanted you to know as it seems like it would be a bug in mainline UE as well.
Well, there was some clarity on what was needed for the repro, and I was able to catch it more appropriately. It hasn’t been addressed yet. It’s something I can integrate mainline, but if you would prefer, you can submit a PR.