I’m trying to AttachTo() multiple physics simulating objects in multiplayer. I’ve run into an issue. If SimulatePhysics is false, and then you attach objects together, that attachment will replicate. If you then enable physics on the root attachment, they should behave as 1 physics simulating welded object.
The issue is that only works correctly in singleplayer or on the server. Clients however have 2 replicated variables with OnRep calls that break the attachment as soon as SetSimulatePhysics(true) is called on the parent attachment. OnRep_AttachmentReplication() and OnRep_ReplicatedMovement(), found in Actor.cpp and SceneComponent.cpp, are called for any child objects that have an attachment. In these replicated variables are values and function calls that tell the client that the AttachParent is now null and should DetachFrom() anything.
The inconsistency in behavior between the server and the client leads me to believe it’s a bug. Here’s an album of images in how you can replicate this behavior using blueprints: http://imgur.com/a/HE0MZ
I think I narrowed down what’s going on. In Actor.cpp in PreReplication the server sets AttachmentReplication.AttachParent = nullptr, which is a replicated value. The client then detaches based on that new information in OnRep_AttachmentReplication found in Actor.cpp, a function the server does not run.
After the server sets that value to nullptr it runs a function called GatherCurrentMovement(), which sets AttachmentReplication.AttachParent = nullptr again, and then updates another replicated variable called ReplicatedMovement, which tells the client that the “child” object is simulating physics. But at this point on the client it’s no longer a child. So on the client 2 objects will start simulating physics independent of each other. The objects on the server will remain attached to each other however, as no DetachFrom() call is ever made.
Apologies for the delay. I was working through your screenshots and came across the Parent Actor variable in your last screenshot for your pawn logic.
Where is the variable coming from, what is its type and what is its default value? It’s possible I’m overlooking something but I just wanted to double-check.
The type is StaticMeshComponent. The default value is nullptr, it’s populated from the static mesh component called “cube” in BP_Cube when the trace after the ‘R’ event hits one of the BP_Cubes I spawn in the level. Thanks for looking into this!
Thanks for the information. After some further investigation, I’m seeing a similar issue to what you’re experiencing. However, mine is a bit more erratic, meaning that I’m seeing the meshes be placed in varied locations around the map rather than just remaining suspended in the air.
However, in terms of the main issue that you’re having, it’s important to keep in mind that once you SetSimulatePhysics() to true on an object, it immediately detaches from its parent because physics simulation takes place in world space.
Have you given this a shot in 4.14 just to see if the behavior is the same? On my end, I’m seeing the objects stay welded, but the physics are a bit out of whack. Replicating physics is a challenging task, and is typically handled through other means such as updating the transform of the actors on the client on tick, just as an example.
If you’re getting objects jumping around make sure your AttachTo rules are set to ‘Keep World’, as that’s not the default. I ended up having to override OnRep_AttachmentReplication and OnRep_ReplicatedMovement to make my own replicated attachment implementation. I will try it on 4.14 though, thanks!
Did you get it working like you wanted to? If so, it would be great if you could provide your method for other users to reference if they run into the same issue.
I am marking this topic as resolved for tracking purposes, as we have not heard from you in a few days. If this issue persists, feel free to respond to this thread. For any new issues, please create a new Answerhub topic.