StaticLoad problems - failing to find file

[minderaser]

So I am doing some dynamic loading and assignment of meshes and materials.

ObjectMesh->SetStaticMesh(Cast<UStaticMesh>(StaticLoadObject(UStaticMesh::StaticClass(), NULL, TEXT("StaticMesh'/Game/Meshes/Park/Mesh_Bench.Mesh_Bench'"))));
ObjectMesh->SetMaterial(0, Cast<UMaterialInstance>(StaticLoadObject(UMaterialInstance::StaticClass(), NULL, TEXT("MaterialInstanceConstant'/Game/Materials/Park/MI_Park.MI_Park'"))));

This works fine in play mode and in mobile preview, but in HTML5 and deploying to Android device, some meshes are invisible (like the one above). The HTML5 console gives the error listed below for instance:

[2015.03.03-18.35.43:977]  0]LogLinker:Warning: Can't find file '/Game/Meshes/Park/Mesh_Bench'
[2015.03.03-18.35.43:980]  0]LogUObjectGlobals:Warning: Failed to load '/Game/Meshes/Park/Mesh_Bench': Can't find file '/Game/Meshes/Park/Mesh_Bench'
[2015.03.03-18.35.43:982]  0]LogUObjectGlobals:Warning: Failed to find object 'StaticMesh /Game/Meshes/Park/Mesh_Bench.Mesh_Bench'

I know for a fact that mesh exists in that folder. Capitalization is the same. I have other meshes in the folder that sometimes load no problem, sometimes don’t. I’ve tried removing the “StaticMesh’’” portion to no effect.

[anonymous_user_4fe9f58b1 (anonymous_user_4fe9f58b)]

This comes up time and time again, so I’ll just repost what I wrote the last time if you don’t mind. Don’t use hardcoded path references.

@cmartel;215140

Which brings me to the actual reason why this approach is Bad Practice: Do not use hardcoded asset references outside of object/class finders. I see people doing it all the time and I wish I could magically impose this knowledge on everyone, but it’s a bad thing to do.

The reason is that once you start cooking your game, asset references defined in this way are completely invisible to the cooker. Cooking only cares about assets you’re actually using, otherwise you’d end up shipping cooked games with piles of data that isn’t actually used anywhere. The cooker determines what assets are being used by loading the maps you’re cooking as well as the native classes you’re using and looking for any asset properties in the loaded results.

What’s going to happen here is the cooker will load your HUD class, get its default object, look at the HUDWidgetClass property and find that it is empty. This is because the path to your widget blueprint class only exists in PostInitializeComponents. So unless the class is somehow referred to elsewhere, the cooker will determine this widget blueprint is unused and omit it from your cooked game, obviously leading to HUD construction issues.

There are two ways to ensure a reference exists to be gathered for the cooker:

1. Create a blueprint for your type (here, AInventoryHUD) and use it to assign an asset to your class property.
2. If you don’t need a blueprint and would just rather specify the asset path in native code, use FObjectFinder/FClassFinder to assign the results to your class property.

In both cases, this will result in your class default object for AInventoryHUD (or AInventoryHUDBlueprint, in the blueprint case) containing a reference to your widget blueprint, thus allowing it to be proprely cooked.

FObjectFinder/FClassFinder is just a wrapper around StaticLoadObject that does a few sanity checks like making sure it is being used from the constructor. Because if not used from the constructor, you end up with asset referencing issues. As a rule of thumb, you should avoid calling StaticLoadObject directly unless you’re certain of what you’re doing.

[minderaser]

Thank you for the well thought out reply, and I don’t blame you for copy-pasting. For some reason I have it in my mind using FConstructorStatics and storing references is a lot of overhead, given I have 36 objects will all be storing those references. Is the best option really to have the logic for preloading and deciding the meshes and materials in a manager class?

So I suppose that part is still in question. That code for instance would be

struct FConstructorStatics
	{
		ConstructorHelpers::FObjectFinderOptional<UStaticMesh> BenchMesh;
		ConstructorHelpers::FObjectFinderOptional<UStaticMesh> GrassMesh;
		ConstructorHelpers::FObjectFinderOptional<UStaticMesh> RockMesh;
		ConstructorHelpers::FObjectFinderOptional<UMaterialInstance> ObjectMaterial;
		FConstructorStatics()
			: BenchMesh(TEXT("/Game/Meshes/Park/Mesh_Bench.Mesh_Bench"))
			, GrassMesh(TEXT("/Game/Meshes/Park/Mesh_Grass1.Mesh_Grass1"))
			, RockMesh(TEXT("/Game/Meshes/Park/Mesh_Rock1.Mesh_Rock1"))
			, ObjectMaterial(TEXT("/Game/Materials/Park/MI_Park.MI_Park"))
		{
		}
	};
	static FConstructorStatics ConstructorStatics;
	BenchMesh = ConstructorStatics.BenchMesh.Get();
	GrassMesh = ConstructorStatics.GrassMesh.Get();
	RockMesh = ConstructorStatics.RockMesh.Get();
	int objectId = FMath::RandRange(0, 2);
	switch (objectId)
	{
	case 0:
		ObjectMesh->SetStaticMesh(BenchMesh);
		break;
	// ETC
	}

But then I end up with lots of cruft references (from the header file)

	UPROPERTY()
	class UStaticMeshComponent* ObjectMesh;

	UPROPERTY()
	class UStaticMesh* BenchMesh;

	UPROPERTY()
	class UStaticMesh* GrassMesh;

	UPROPERTY()
	class UStaticMesh* RockMesh;

	UPROPERTY()
	class UMaterialInstance* ObjectMaterial;

But yes doing it this way did resolve my issue!

[anonymous_user_4fe9f58b1 (anonymous_user_4fe9f58b)]

If managing a lot of resources in native code is bothersome, then you might want to consider using a blueprint base. You don’t have to use blueprint for anything beyond exposing some properties to edit and use those in C++ as normal. Then you can create a blueprint in the editor and just assign asset references through the content browser. This is a “Data-only Blueprint”.

Don’t worry about the performance from loading from a blueprint either, in cooked builds, both native and blueprinted classes are serialized from the Class Default Object in the same way.

Edit: Oh, I just noticed you do randomization in the constructor. This probably won’t do what you want, because the CDO gets randomized once, then every other object created will copy itself from it. A good middle ground would be to load the asset references in the constructor, and randomize and apply as usual where you first had it.

[ANLevant]

@anonymous_user_4fe9f58b1

This comes up time and time again, so I’ll just repost what I wrote the last time if you don’t mind. Don’t use hardcoded path references.

If UE4 Wasn’t so ■■■■■■ in it’s design, we developers wouldn’t haveto come up with ■■■■■■ ways to cover up that poor design