This issue happens in 5.6 Launcher version. If we have a structure like this:
[Image Removed]
A WP-on Main Level
A WP-on level instance (with Is Spatially Loaded On)
A Parent BP, with Is Spatially Loaded Off
A Child Actor, with Is Spatially Loaded Off
Sometimes it will trigger a bug which only happens in the cooked (packaged) build, makes the child actor loses the attachment parent info, and uses its relative transform as the world transform. By debugging, it seems like the Child Actor’s root component’s ‘AttachParent’ component is missing after cooked.
We cannot find a stable repro steps for how to trigger this bug, but we successfully found a project that triggered this bug.
We tried to directly reproduce this level structure, but found that the bug did not occur. Therefore, we believe that a specific step in the operation may be very important.
We are still investigating this bug, try to provide more info.
We found another UDN issue which looks like our case but not the same:
[Content removed]
We also uploaded the built version to avoid this is a random cook problem.
But we also want Epic Devs’ help based on this project
Why the child actor loses its attachment info after cooked?
Sorry for the wait on this case. We have been able to reproduce the problem in the Main stream. At this point, the recommendation would be to avoid using a BP as parent to other actors in a hierarchy at the outliner level.
We are not sure of why this problem is not happening deterministically. There might be code paths that register the components of the Child Actors before the Parent has its construction script rerun. In this case, the rerun code will update the Child’s AttachParent.
While investigating the issue further, I ran into an old case where the licensee has resolved the problem by registering all actors as a first step to MoveExternalActorsToLevel so that the references can be updated by the usual code. The licensee found that Renaming the actors does forget the components registered so it could be related to the order the Actors are being treated. [Content removed]
Both solution are currently being considered by the engine team so we have an official solution in version 5.8. The workaround I shared is safe and proven to work in the RCT code.
> the recommendation would be to avoid using a BP as parent to other actors in a hierarchy at the outliner level.
It is a little hard to tell our team that we should totally avoid doing things like this and fixing all the level instances contains this case
If you can provide more info related to this problem, it will help us to discuss. For example, from our end, it seems like a random bug. But I think since it can be reproduced, Epic must find a set of step to reproduce this, can we just avoid these steps?
I was able to find where the parent is lost. The source is the call to AActor::RerunConstructionScripts in FWorldPartitionLevelHelper::MoveExternalActorsToLevel. The construction script destroys the BPs component and recreates them. This is the Parent in the current scenario. The Child is referencing its Parent’s RootComponent as its AttachParent. That reference becomes invalid because of the CS and the usual code that fixes those reference relies on the AttachChildren of the Parent. Filling the AttachChildren relies on the Actor\Component being Registered which does not happen when cooking. The invalid reference is discarded by the validation code at the end MoveExternalActorsToLevel.
We already had to fix a similar issue that was happening when using RuntimeCellTransformers. The solution to this new problem will likely involve extracting the solution from the RCT code and make it general so that is can also be used in MoveExternalActorsToLevel.
The CLs involved in the RCT fix are CL#44081791 and CL#45834203.
I created a temp solution from the RCT fixes and am attaching it to this post. The Cube was a the expected location after that change.
If you are using the RuntimeCellTransformers, I strongly recommend that you integrate the 2 change lists I shared .
Really thanks for all your work. Applying your fix solved our problem. So this issue is 99% solved.
I just have an additional question: why this problem randomly happens instead of consistently happening?
I believe your explanation is correct. However, I need to explain the following phenomenon to my team:
Simply using Level Instance + Parent BP + Child BP does not always trigger this bug, even though this meets the conditions of your explanation.
Once the bug is triggered, repeated Cooking will still reliably trigger it.
I guess the secret is between step 2 and 3. Some BPs always trigger 2 -> 3, some are not
The source is the call to AActor::RerunConstructionScripts in FWorldPartitionLevelHelper::MoveExternalActorsToLevel.
The construction script destroys the BPs component and recreates them. This is the Parent in the current scenario.
The Child is referencing its Parent’s RootComponent as its AttachParent. That reference becomes invalid because of the CS and the usual code that fixes those reference relies on the AttachChildren of the Parent.
Filling the AttachChildren relies on the Actor\Component being Registered which does not happen when cooking.
The invalid reference is discarded by the validation code at the end MoveExternalActorsToLevel.