Note that I am posting this as an answer because of the comment-character-limitation.
I just had another compiler error on this line:
StaticMeshComp->SetStaticMesh(ULib::CreateObject<UStaticMesh>("/Game/Assets/AmmoSet/Models/cal9mm/cal9mm_PaperBoxOpen"));
error C2664: ‘void
ConstructorHelpers::ValidateObject(UObject
*,const FString &,const TCHAR *)’: cannot convert argument 1 from
‘UStaticMesh *’ to ‘UObject *’
So I pressed F12 on UStaticMesh and ended up in EngineType.h on line 2522:
UPROPERTY(EditAnywhere, Category=BuildSettings)
class UStaticMesh* DistanceFieldReplacementMesh;
Erm… Yeah… That kinda explains… First of all this is a forward declaration (which causes the compiler error) and secondly that is not the one from Engine/MeshComponent.h that I was expecting.
Now here comes the interesting part. This class compiles and uses the proper UStaticMesh (inherits from the same base class as the other one):
#include "PU9mm.h"
#include "Lib.h"
APU9mm::APU9mm()
{
StaticMeshComp->SetStaticMesh(ULib::CreateObject<UStaticMesh>("/Game/Assets/AmmoSet/Models/cal9mm/cal9mm_PaperBoxOpen"));
PickupText = NSLOCTEXT("Default", "9mm Ammo", "9mm Ammo");
AmmoType = EItemType::Ammo9mm; // TODO: is the AmmoType variable really required?
ItemCategory = EItemCategory::Default;
ItemStackInfo.ItemType = AmmoType;
LoadIcon("/Game/UI/Textures/InventoryIcons/Ammo_9mm");
ItemName = NSLOCTEXT("Default", "9mm Ammo", "9mm Ammo");
}
And this one does not and uses the one from EngineType.h:
#include "Stone.h"
#include "Lib.h"
AStone::AStone()
{
StaticMeshComp->SetStaticMesh(ULib::CreateObject<UStaticMesh>("/Game/Assets/AmmoSet/Models/cal9mm/cal9mm_PaperBoxOpen"));
//PickupText = NSLOCTEXT("Default", "Stone", "Stone");
//ItemCategory = EItemCategory::Default;
//ItemStackInfo.ItemType = EItemType::Stone;
//LoadIcon("/Game/UI/Textures/InventoryIcons/Ammo_9mm");
//ItemName = NSLOCTEXT("Default", "Stone", "Stone");
}
So 2 classes that aside from their name are exactly identical (okay I outcommented some unrelated lines for testing purposes in the second one but it made no difference). One compiles and one does not.
But it get’s even worse. After adding the include include “Engine/StaticMesh.h” manually to the one that didn’t compile and then removing that include again still caused the second one to magically compile (yes without the include this time). Yes my code is EXACTLY the same as before when it did not compile but now it uses the proper UStaticMesh include… Erm… There has got to be some kind of caching bug somewhere… I mean, sometimes I just have files that pseudo-randomly give compiler errors (without being changed) completely out of the blue and they ask for includes that they never required before (and now apparently) vice versa as well. And on top of that other classes that are nearly identical don’t require those include (but may do so at a later time for unknown reasons).
The workaround is obviously to use the specific includes and force the UHT/compiler to use the proper ones (which might be considered better code anyway). But why it sometimes uses the one from include A and sometimes the one from include B for the exact same class… No idea… It could be intended behavior but its’ weird. And it also (a bit) beats the purpose of including