We have recently been experiencing frequent cook errors. These error don’t always occur but we are seeing >50% of our cooks fail. This is happening in both 5.5.4 and 5.6.0.
There are several related reported issues:
- [Content removed]
- [Content removed]
- [Content removed]
- [Content removed]
Could be possibly related to an earlier issue we reported back with UE 5.1:
[Content removed] With this issue we identified we had duplicate external actors.
The number of errors can vary widely. We’ve seen as many as over 1k of these errors in a single cook.
LogCook: Error: Content is missing from cook. Source package referenced an object in target package but the target package was marked NeverCook or is not cookable for the target platform. Source package: <path_to_source_package> Target package: <path_to_target_package> Referenced object: <path_to_referenced_object>The source packages are the /_Generated_/ levels referencing Static Meshes. The referenced objects end in `_GEN_VARIABLE`.
We also see a similar errors with sequences, with a different error message:
LogCook: Error: Content is missing from cook. Source package referenced an object in target package but the target package was marked NeverCook or is not cookable for the target platform.These errors all seem to have the same Target package: `/MetaHuman/IdentityTemplate/Face_ControlBoard_CtrlRig`
We’ve found that using a build machine with more RAM, 256GB instead of 128GB, reduces the frequency of these issues. We theorize that reducing Garbage Collection helps, however we still see this failure even with a build machines with 256GB of RAM.
Steps to Reproduce
We are issuing a pretty standard Cook command.
X:\Game\Engine\Binaries\ThirdParty\DotNet\8.0.300\win-x64\dotnet.exe "X:\Game\Engine\Binaries\DotNET\AutomationTool\AutomationTool.dll" -config=Development+Test -licensee -nosign -nosubmit -noxge -project=Game.uproject -promoted=0 -target=Game -targetplatform=Win64 -unattended -utf8output -crashreporter -cook -nopackage -prereqs -skippackage
We have received other reports of _GEN_VARIABLE missing from cook errors in 5.6; sending to the Blueprint team who has been looking at them.
Hey Michael,
Which version of the engine were you using before this error began to show up? It might help us narrow down where things went wrong. Also, do control rig assets only seem to have this issue, or were there others?
Thanks,
Dave
I guess I’m not too sure where we’re at now. It sounds like the original issue was a missing plugin and some tinkering with child actor components.
Do the remaining errors still reference _generated_? What asset types? Did these specific errors occur in the previous engine version?
And the engine version you were using prior to 5.5.4 before the issue came up?
> We have an actor that is automating merging all components to ISMs
Could you elaborate on what this is doing exactly? Are you saying that this only affects your custom actors that merge components?
Oooh, I had a copy paste issue with my original report. There were two different messages, we were seeing this message with some static meshes, not the NeverCook message I indicated in my original report:
LogCook: Error: Content is missing from cook. Source package referenced an object in target package but the object was stripped out of the target package when saved.I have an update from our regarding the Control Rig NeverCook issues, turns out we recently added content using `Face_ControlBoard_CtrlRig` but not all our platforms had the MetaHuman plugin enabled. Enabling the plugin fixed those errors.
We were also able to reduce the frequency of the issues we were having with stripped out objects. We were accidentally mutating child actor BPs when merging meshes by stealing their SCS nodes. Child actor components didn’t have stable names which resulted in missing component references. Leftover templates orphaned in the BPGC conflicted with names used by the merged SCS causing random component names. However, we are still getting this intermittently, just a lot less frequently now.
The remaining errors do reference _generated_. The referenced objects end in `_GEN_VARIABLE`. These errors were happening first, the control rig content was added while we were encountering them so I didn’t realize they were platform related. I apologize for confusion.
We are seeing the stripped errors in both 5.5.4 and 5.6.0. We have an actor that is automating merging all components to ISMs. The assets being stripped are static meshes.
We’ve been using 5.5.4 for a while without seeing this issue. Prior to 5.5.4 we were using 5.4.4.
Currently the only assets that I’ve seen failing in this way have been our “static mesh prefabs”, and there have only been a couple of assets failing out of the few thousand that we have.
Update: We found one more issue with our prefab ISM merging that was non-deterministic due to collision. The long note in UStaticMeshComponent::Serialize explains how we were running afoul.
// NOTE: Must come after NotifyIfStaticMeshChanged to avoid an ensure in GetStaticMesh during cook. // If the component has bUseDefaultCollision set to true and we are a Blueprint component, then our BodyInstance will // be saved with the CollisionProfile data copied from our StaticMesh, but the CollisionProfileName will be unchanged // and can be anything. But! UPrimitiveComponent::Serialize calls BodyInstance.FixupData which will replace the loaded // profile data with the named profile data. This would get replaced again (with the correct values) in OnRegister, // but we need the profile to be set up correctly immediately after load because, if the component is a blueprint // component, the blueprint may attempt to write into the CollisionProfile's ResponsesArray at an index that no longer // exists (e.g., the StaticMesh is BlockAll which has 8 elements by default, but the Component is NoCollision which has 2). // See FORT-506503 for more context if (Ar.IsLoading() && IsTemplate() && bUseDefaultCollision) { UpdateCollisionFromStaticMesh(); BodyInstance.FixupData(this); }We omit the collision settings from the FISMComponentDescriptor if bUseDefaultCollision since both it and the mesh asset ref are part of the hash already. This prevents us from hashing stale data.
It seems the errors were on our end, and 5.6.0 was more reliably failing, which helped us to track down our issues. Hopefully this information is helpful to others encountering these cook errors.