UStaticMesh DDC Key differs between regular Editor launch and Commandlets

Hello,

After upgrading to 5.6 we’re now having an issue where the UStaticMesh CachedVersionString value differs between a regular editor boot and a Commandlet. This is due to the order in which certain modules are loaded at startup.

FEngineLoop::PreInitPostStartupScreen() calls ProcessNewlyLoadedUObjects() which handles default construction of UClass objects. The order of this list appears to be the root cause of the issue. Below is a simplified outline of events when running the editor normally vs via Commandlet. The result of this is that MapCheck will potentially emit hundreds of warnings when running a validation Commandlet as the DDC Key mismatch makes it appear as if UStaticMesh referencing objects require re-saving.

While did not experience this in 5.5, it looks to be out of luck since both paths appear to construct DefaultPawn prior to MeshSimplicationSettings. We have applied a fix locally to forcibly load “MeshUtilities” in PreInitPostStartupScreen(), though this may not be the most appropriate fix.

Load Engine Normally:
/Script/Engine CameraActor
	-> UStaticMesh /Engine/EditorMeshes/MatineeCam_SM
		-> GetStaticMeshDerivedDataVersion()
			-> LoadModule "MeshUtilities" -> FMeshUtilities::StartupModule()
				-> LoadModule "MeshReductionInterface" -> FMeshReductionManagerModule::StartupModule()
					-> FSkeletalMeshReduction::GetSkeletalMeshReductionInterface() calls LoadModule("MeshUtilities")
						-> Module exists, returns
					-> StaticMeshReduction is assigned
				-> Module.GetStaticMeshReductionInterface() returns valid value
				-> VersionString includes mesh reduction version
		-> DDC Key is cached with mesh reduction version
 
Load via Commandlet:
/Script/Engine MeshSimplicationSettings
	-> UMeshSimplificationSettings::PostInitProperties()
		-> LoadModule "MeshReductionInterface" -> FMeshReductionManagerModule::StartupModule()
			-> FSkeletalMeshReduction::GetSkeletalMeshReductionInterface() calls LoadModule("MeshUtilities")
				-> Module is not loaded, so FMeshUtilities->StartupModule()
					-> LoadModule "MeshReductionInterface"
						-> Module exists, but since it's currently in StartupModule and not fully initialized
						-> Module.GetStaticMeshReductionInterface() returns null
						-> VersionString does not include mesh reduction version
/Script/Engine DefaultPawn
	-> UStaticMesh /Engine/EngineMeshes/Sphere
		-> GetStaticMeshDerivedDataVersion()
			-> LoadModule "MeshUtilities"
			-> Already loaded
			-> GetVersionString returns cached string without mesh reduction version

Thanks,

Jared

Hey Jared, thank you for the report! I confirmed we see the same behavior on the latest engine version. We will figure out how we want to fix this and get back to you.

We submitted a change to force a working module load order in UE5/Main CL 47464275.