This is frustrating though. I actually went through a lot of my code to remove ObjectInitializer.
I didn’t think this would be a problem but if you have an inheritance hierarchy like this:
AMySecondCharacter(const FObjectInitializer& ObjectInitializer)
AMySecondCharacter can’t call Super(ObjectInitializer) since AMyCharacter’s constructor doesn’t take it. I kinda assumed there was some magic going on that allowed both constructors. Seems like if it’s an epic class, calling either super method works, but on subclasses, if you stop using FObjectInitializer, a subclass can’t use it any more. They actually write their constructor like this, so either one works:
ACharacter(const FObjectInitializer& ObjectInitializer = FObjectInitializer::Get())
const FObjectInitializer& ObjectInitializer = FObjectInitializer::Get()
So if you need to override a default subobject class in some subclass, all classes along the way have to use FObjectInitializer.
It seems like it could be a good practice to always do this for actors in case you need to override a component class.
I did some digging into the source. The closest thing I found is somehow calling:
But this has to run before the super constructor is called, and the only way I found to do that is to pass up the ObjectInitializer in the constructor.
Internally, when you call CreateDefaultSubobject, this calls FObjectInitializer::Get() and gets the current overrides.
If you call SetDefaultSubobjectClass in the constructor of a subclass it fails saying this can only happen in the base class, which makes sense. It would work this way if you continued to pass ObjectInitializer to the constructor like it used to.
In fact it seems like there are other functions like DoNotCreateDefaultSubobject that require ObjectInitializer. I’m not even sure it’s possible to do these things without ObjectInitializer due to how C++ works, so why they removed it, I’m not sure. It kinda breaks things if any classes along the way don’t take ObjectInitializer in their constructor.