Inside UWorldPartition::ApplyRuntimeCellsTransformerStack when LevelActor->RerunConstructionScripts() is called it can result in Blueprint actors that are attached to a parent in the editor to lose their world transform

Development World Creation
, ,
1

We have been working through some issues trying to use the WorldPartitionCellTransformers. We are on 5.5.4 and have integrated these CLs to fix some issues with Blueprints working correctly during the transform process:

`Bring back CL38157186 with fix from Ben Ziegler: change actor ExecuteConstruction to correctly register blueprint-added components on actors that have been fully registered, even if world has not been initialized.

#rb ben.zeigler, dan.oconnor
#preflight 673cb63ca34c8e9288b6c246
#okforgithub public

#submittool SubmitTool-Development-5.3.0.CL-38118620`And hacked integrated this without its previous revisions

[Cell Transformer] Replace references to objects that could be recreated during RerunConstructionScripts triggered from ApplyRuntimeCellsTransformerStack ApplyRuntimeCellsTransformerStack is executed before components are registered, which means that for actors that have actors attached to them, AttachChildren array won't be populated yet. That information is not serialized (unlike AttachParent property) and is constructed during component registration based on AttachParent information. Because of that, when recreating objects during RerunConstructionScripts triggered from ApplyRuntimeCellsTransformerStack, we could recreate a parent object without updating AttachParent property on its children. This can lead to "Reachable garbage object" GC Warning - AttachParent pointing at garbage objects. Under normal flow that's handled by RerunConstructionScripts, using AttachChildren array. Since that is not available yet in this case, we have to handle that on our side. #preflight 6876a3fb317b2cba4b747252 #rb Richard.Malo #okforgithub public #submittool SubmitTool-Development-6.1.2.CL-43493068and:

Don't add root component if the blueprint doesn't support a construction script but currently has one #preflight 66f44263387f45e004445fd7 #rb ben.hoffman #jira UE-225440 #okforgithub public [RN] The blueprint compiler no longer attempts to add a sceneand

Fix references being cleared upon archetype reinstantiation UDN case number 12529527 Regression introduced in cl 28083808 and was probably a cut&paste error, the bClearReference was false previously and was turned on in that cl. #preflight 66d8d4944d3fefb970d661f8 #rb Cody.Albert, dan.oconnor #okforgithub public [RN] Fix Archetypes self reference being reset bug during reinstantiation code. #submittool SubmitTool-Development-5.0.0.124120492and

Bring back CL38157186 with fix from Ben Ziegler: change actor ExecuteConstruction to correctly register blueprint-added components on actors that have been fully registered, even if world has not been initialized. #rb ben.zeigler, dan.oconnor #preflight 673cb63ca34c8e9288b6c246 #okforgithub public #submittool SubmitTool-Development-5.3.0.CL-38118620

Here is the last issue we are facing. If you have a BP actor in the editor attached to an parent actor, for example a target point actor. Inside UWorldPartition::ApplyRuntimeCellsTransformerStack when LevelActor->RerunConstructionScripts() is called it can result in these attached Blueprint actors to lose their world transform during the detach and re-attach step of the construction script. The result is that the BP Actor will be put at its relative position in the world after its re-attached instead of back at its world transform.

Is this a bug you guys have tracked down and fixed? I am looking through submits and can’t seem to find anything directly related to it…

Thanks for any help

2

We have verified this is still an issue for us on 5.6

I have not tested this on vanilla yet, but I am pretty sure you could get it to repo if you did this:

  1. Create a new open world template map
  2. Add a transformer into the stack, any will do since that will trigger the construction scripts to run.
  3. Add a TargetPoint actor to the world
  4. Make a Blueprint with a ISM component as the root (this seems to trigger it more often for us), Add a mesh a few instances.
  5. Place Blueprint in world, set to moveable, attach to TargetPoint actor in the editor
  6. Run, and hopefully observe the BP Actor have its transforms changed.

Another little bit of info is that this seems to be happening on Blueprints that do not have a default scene component root but have had their root manually set to another type in the BP editor.

3

Ok I have narrowed it down even further.

It appears that Blueprints that do not have a default scene root component have their root ComponentToWorld=0,0,0 during this code in ActorConstruction.cpp

`if (RootComponent != nullptr)
{
// Do not need to detach if root component is not going away
if (RootComponent->GetAttachParent() != nullptr && RootComponent->IsCreatedByConstructionScript())
{
Parent = RootComponent->GetAttachParent()->GetOwner();
// Root component should never be attached to another component in the same actor!
if (Parent == this)
{
UE_LOG(LogActor, Warning, TEXT(“RerunConstructionScripts: RootComponent (%s) attached to another component in this Actor (%s).”), *RootComponent->GetPathName(), *Parent->GetPathName());
Parent = nullptr;
}
AttachParentComponent = RootComponent->GetAttachParent();
SocketName = RootComponent->GetAttachSocketName();
//detach it to remove any scaling
RootComponent->DetachFromComponent(FDetachmentTransformRules::KeepWorldTransform);
}

// Update component transform and remember it so it can be reapplied to any new root component which exists after construction.
// (Component transform may be stale if we are here following an Undo)
RootComponent->UpdateComponentToWorld();
OldTransform = RootComponent->GetComponentTransform();
OldTransformRotationCache = RootComponent->GetRelativeRotationCache();
}`So when RootComponent->DetachFromComponent() is called it goes to zero

4

I have verified locally that calling RootComponent->UpdateComponentToWorld() before the detach ‘fixes’ the issue, but not sure if that is the best or correct place to apply that code. Feels like something else is going wrong along the construction process.

Hopefully this helps you identify the problem

5

Just to follow up on the reproduction of the issue. Can you confirm that this behaviour is still present when all dirty actors are saved?

In reproducing the issue, I found that the issue appears to fix itself until the hierarchy of actors is modified again. Saving all actors appears to remedy the issue in 5.6, though.

Best regards,

Chris

6

Hello there,

I’ve replicated the issue, and I will report this as a bug.

Best regards,

Chris

7

Thank you,

If you submit a changelist to main can you respond here with it so we can integrate it?