We are getting a lot of these type of warning spam during cooks.
LogCook: Display: [CookWorker 2]: Unsolicited package /Game/SeventhCurseBP/ProcGen/MapData2/RoomL_1door_A was loaded by package /Game/SeventhCurseBP/ProcGen/MapData2/VLI/RoomL_1door_A_V_2_V. This is a hidden dependency, causes poor cook performance, and it might be a bug to add it to the cook. Declare this package in the AssetRegistry dependencies of the loading package, or mark up its load with FCookLoadScope to specify whether it is runtime or editoronly.
I know these log entries are Display logs, and not warnings, but the message they are conveying certainly comes across more in the spirit of a warning
This spam comes from assets that haven’t changed the way they are cooked in several years now.
- These assets are part of a procedural level instance based dungeon generation system.
- These assets(levels) are referenced by data tables, by TSoftObjectPtr<UWorld>
- These data tables, are included by a ModifyCook overriden asset manager
So while the references to this world are hidden in the sense that those assets are indirectly referenced by the cooked data tables, I don’t understand why this warrants these messages that suggests something bad/unexpected is occurring. I was under the impression that the inclusion of asset reference chains is a normal function of the cooking process. I am explicitly including a data table package from the ModifyCook function, therefore, any downstream references from that link in the chain, are in fact solicited.
Judging by the part
Declare this package in the AssetRegistry dependencies of the loading package, or mark up its load with FCookLoadScope to specify whether it is runtime or editoronly.
- Declare this package…
- How? And why isn’t the fact that the data table references all these levels with soft references already providing that?
- or mark up its load with
- ModifyCook doesn’t actually load packages, it just returns a list of them, so FCookLoadScope doesn’t seem appropriate here either
Here is how my ModifyCook function works
void UGameAssetManager::ModifyCook(TConstArrayView<const ITargetPlatform*> TargetPlatforms, TArray<FName>& PackagesToCook, TArray<FName>& PackagesToNeverCook)
{
Super::ModifyCook(TargetPlatforms, PackagesToCook, PackagesToNeverCook);
IAssetRegistry& LocalAssetRegistry = GetAssetRegistry();
const TArray<FName> TagsToCook {
FName(TEXT("ForceCook")),
FName(TEXT("LobbyMap"))
};
TMap<FString, int32> ForceCookCountsByAssetPaths;
for (auto Tag : TagsToCook)
{
// make sure we cook all potential procedural prop data
FARFilter Filter;
Filter.bRecursiveClasses = false;
Filter.bIncludeOnlyOnDiskAssets = true;
Filter.TagsAndValues.Add(Tag);
TArray<FAssetData> AssetDatas;
if (LocalAssetRegistry.GetAssets(Filter, AssetDatas))
{
for (const FAssetData& Asset : AssetDatas)
{
PackagesToCook.Add(Asset.PackageName);
FString PreviewPath;
if(Asset.GetTagValue(TEXT("LobbyMapPreview"), PreviewPath))
{
PackagesToCook.Add(FName(PreviewPath));
ForceCookCountsByAssetPaths.FindOrAdd(TEXT("Opaque"))++;
}
}
}
UE_LOG(LogGameAssetManager, Display, TEXT("UGameAssetManager::ModifyCook Added %d assets with tag %s"), AssetDatas.Num(), *Tag.ToString());
}
}
I conditionally apply the “ForceCook” asset tag in OnGetExtraObjectTagsWithContext delegate functions.
Did something change with the ModifyCook process to make it play nice with more recent changes to the engine and avoid this spam?
:FPackageTracker::OnCreatePackage(FName) PackageTracker.cpp:208