Setting variables in Child Actor Components, from parent, in 5.6

[psychoblizzard9]

Has something changed about the way that 5.6 handles setting variables in child actor components?

In 5.5 and earlier versions, in the construction script of the parent, after using “Add child actor component” I would then get child actor, cast to child actor class and then be able to set variables in the child actor. In 5.6 the variables on the child actors seem to reset to none on begin play.

I added an image below to show what I’m referring to

[MaxNerazim]

Hey! I upgraded from 5.5 → 5.6 last week and we use a lot of Child Actor Components. I think I found the reasons for the issue and a couple of solutions.

Disclaimer: I didn’t investigate deeply — I’m not an engine expert — but these fixes worked for us and might help others — refer to that for more technical details

Problem:

Variables set from the parent into the child actor are lost.

When does it happen?

In PIE (Play In Editor)
Not after cooking / packaged builds

Why:

Parent actor CS (construction script) is not executed

CAC (child actor component) are now respawning their child actor (more details), any setup done before is lost

Solution 1 (using CAC template):

Pros:

• Minimal changes required

Cons:

• Can’t set actor references from world placement (illegal references)

• Can only set instance editable variables (can’t edit BP added components) (I’m not sure on what exactly you can edit)

• For the second case, probably not the intended workflow

if the CAC is not added in the CS and variable can be set in the BP, edit the CAC template in the details panel

otherwise, edit the CAC template in the CS

UFUNCTION(BlueprintPure, Category=ChildActorComponent)
static AActor* GetChildActorTemplate(const UChildActorComponent* ChildActorComponent);

AActor* UBlueprintFunctionLibrary::GetChildActorTemplate(const UChildActorComponent* ChildActorComponent)
{
	if (ChildActorComponent)
		return ChildActorComponent->GetChildActorTemplate();
	return nullptr;
}

Solution 2 (Child CS):

Pros:

• No C++
• Probably the intended workflow
• More robust IMO

Cons:

• Different flow → more work in my case
• Makes child dependent on parent
• Child may always load the parent (I’m not sure about that after cooking, since the cast to the parent is in the CS)

Child actor reads required values from its parent in its Construction Script: