Download

StaticLoad problems - failing to find file

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.

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.

-Camille

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!

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.

-Camille

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