CreateDefaultSubobject order in Parent class impacting Blueprint Child Class attachment hierarchy

Hi!

I’m currently trying to attach a camera to a spring arm, which will be attached to the RootComponent (in my case, the RootComponent is a capsule). The attachment is done in C++ in the constructor with SetupAttachment.

I created a Blueprint from this Parent class, and the result is a bit strange…

I don’t know if it’s a bug within Unreal, but when I create the camera before the spring arm in C++ :

AParentClass::AParentClass()
{
	// Create components
	Camera = CreateDefaultSubobject<UCameraComponent>(TEXT("Camera"));
	SpringArm = CreateDefaultSubobject<USpringArmComponent>(TEXT("Spring Arm"));

	// Setup Attachements
	SpringArm->SetupAttachment(RootComponent);
	Camera->SetupAttachment(SpringArm);
}

The Blueprint child class component hierarchy is looking like this :

image

I would have thought that there would be one sprint arm that I could expand to reveal a camera, regardless of the order in which I create the two components! But I get a camera within a camera, with a spring arm at the same level as the first camera…

But when I swap the first two lines in the constructor to create the spring arm before the camera :

// Create components
	SpringArm = CreateDefaultSubobject<USpringArmComponent>(TEXT("Spring Arm"));
	Camera = CreateDefaultSubobject<UCameraComponent>(TEXT("Camera"));

	// Setup Attachements
	SpringArm->SetupAttachment(RootComponent);
	Camera->SetupAttachment(SpringArm);

And then re-parent the blueprint to see the changes done in the constructor, it’s behaving as intended :
image

I was wondering if anyone else encountered this issue, and if there was a known reason why it happens?

Thank you,
Knorax

If you’re compiling in the engine, the hierarchy breaks quite often.
After changing the hierarchy or adding new components, I usually restart the project and it gets fixed.

I also usually close the editor and compile the project from Visual Studio when I modify the constructor to avoid these kind of issues!

But it didn’t work in this particular case, which is quite strange…