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?
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?
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.
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)
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?
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
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
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.
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.
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.