ChildActor Replication in 4.5 broken?

Development Programming & Scripting
1

We’re seeing a really nasty bug in 4.5 with child actors & replication… (works fine in 4.4)

When a ChildActor within a blueprint, is set to replicate… The spawned child actor is replicated as being at location 0,0,0 relative to the parent blueprint… (instead of the relative location of the ChildActorComponent… The location is correct on the server, but is incorrect on all clients)

Setup:

1) Create a blueprint "BP_Inner"

  • add a simple static mesh component at 0,0,0
  • set the blueprint as “Replicates” and “Replicate Movement”

2) Create another blueprint "BP_Outer"

  • add a ChildActorComponent, set to the BP_Inner blueprint
  • move the child actor Up Z +100

3) Create a Default Empty World

  • place the BP_Outer blueprint in the world, notice that the inner blueprint mesh is visible, and up Z+100

  • Set the Play options to “1 client & Dedicated Server Enabled”

  • hit “Play”… notice that the inner mesh is now back down to Z=0

if you turn off dedicated server (listen server)… the position is correct.

Is this a bug? unexpected ‘fix’? and is there any way around this problem?

2

Seeing the same issue here. Any update from Epic?

3

Ouch. This is a pretty serious bug. Can you link to the patch so we can apply it locally?

4

Hey Helius-

I have confirmed this behaviour in 4.5.1. However this has been addressed internally and will be included in a future update to the engine.

Cheers

5

Hey , Glad to know its not just us!!

This bug is currently blocking most of our designers & multiplayer gameplay. Is there any chance we can get a patch link or even details on where to fix it in the code?

6

Did you mark this answered ? Could we get a little more information than “a future update”?

7

Looking into this bug further, it would appear that BP_Inner is forcing it’s position on BP_Outer when the replication options are checked. If you uncheck the replicate options on BP_Inner, then the BP_Outer placed in the level will have the correct orientation.

8

Although that does work… that just falls back to the components using the positions/attachments defined in the level as it is loaded on the client… But as soon as you need to replicate any state (as lots of our Blueprints do), things break.

I posted a temporary fix on UDN (by re-enabling construction scripts to always run in PIE, which forces the bNetReplicates field to be set to 1 on all components)

9

Along with Helius, the “disable the feature you want to use” solution doesn’t work for us.
, could you link us to the patch you referenced previously?
Helius, could you link to your patch on UDN?

10

Sure! Here’s the temp workaround/fix we’re using…

When running in PIE instance, a copy is made of the World object for each client/server instance.
In 4.4, these world instances would re-run all the construction scripts for every actor in the world, which in turn, would set the bNetAddressable flag to true for all actor components assigned via blueprints. This is what enabled replication to work for all components (such as the child actor component)

In 4.5, a change was made to World.cpp that stops the construction scripts from being re-run on the client world copies, thusly the actor components dont have the bNetAdressable flag set, and can no longer replicate :frowning:

We have a temp fix which rolls back to the 4.4 method for determining if CTor scripts should run. No clue if this is the appropriate fix, but it works for now. We look forward to a real fix from the Epic folks :smiley:

Fix: In World.cpp (line 2780) change

const bool bRerunConstructionScript = !(FPlatformProperties::RequiresCookedData() (IsPlayInEditor() && PersistentLevel->bWasDuplicatedForPIE));

to

const bool bRerunConstructionScript = !FPlatformProperties::RequiresCookedData() && (!IsPlayInEditor() || HasAnyFlags(RF_WasLoaded));
11

Hmm… unfortunately, this temp fix breaks Nested Child Actors …

When the construction scripts are re-run, the nested child of a child will be completely recreated, losing all of it’s original settings.

We really need a good fix for the original bug :expressionless:

12

Hi Helius,

I haven’t tried this locally yet, but can you try adding:

AActor::PostRegisterComponents() 
{
    for (UActorComponent* Component : OwnedComponents)
    { 	
        UpdateReplicatedComponent( Component );
    } 
}

And see if that fixes your issue?

13

Hey , sorry for the delayed response… We didnt try your suggestion, as there is no UpdateReplicatedComponent() method in Actors.

We have been working around the bug as best we can, but the problem is starting to block us more and more… Any word from Epic on a fix for this?!

14

Hey Helius-

I apologize for the wait. This is still being investigated by our engineers. It is difficult to give an exact time frame for the fix but we are working to fix this bug as quickly as possible.

Thanks

15

Hey / Epic Staff

Any progress on this bug? We still have transforms getting zero’d out, and ghost “un-replicated” actors showing up on the clients.

We had some workarounds to force transforms to re-replicate or for clients to store/restore original transforms after replication, but these hacks only get us around half the problem. We are direly in need of information from Epic on this one.

16

Hey Helius-

I tested this on the 4.7 version of the engine available on GitHub and found that it is working there. I would check again with Preview 2 for 4.7, however it should be included with the final 4.7 release.