How would I go about attaching actors on all the connected clients, but without the server forcing an attach. Basically I’d like to completely manually attach an actor on all clients including the listen server. But right now whenever I call attach on the listenserver the attach is forced to all clients that see the replicated actor. This is a problem when playing with 100ms ping as the attach on the server forces the client to the location of the server which is delayed.
If the actor is replicated and replicates it’s movement, then the Server has the authority on what the object is attached to (and for good reason - replicated movement will stop functioning properly if this isn’t kept in sync). If you want to change the attachment or transform of something locally, you have to stop replicating movement because as soon as the server sends an update, clients will snap to it.
Otherwise - this is handled via AttachmentReplication, and as far as I know you can’t really stop it in Blueprint only. To be honest I’d be very wary about allowing clients to change it locally without the Server knowing about it, that’s a really quick way to end up with a desync’d game state. Changing replicated properties on clients rarely ends well. (I’d take a snapping artefact over desync anyday.)
If you want to look into it, places to look in C++ are OnRep_AttachmentReplication, OnRep_ReplicatedMovement and GatherCurrentMovement() in AActor.
Hey, thanks for the reply!
The problem is that this doesn’t just cause an artifact, it’s a major gameplay breaking issue as the relocation due to the snap can cause a player to fall of a platform. This is unacceptable gameplaywise. Therefor I’d rather like the client to attach themselves to a platform after which the server and the other clients attach the actor to the same platform. Location desync is normally not a problem as the locations are updated and refreshed almost constantly. The attachment on the client would also parse the exact point of attachment to the server so each client is attached at exactly the same relative location of the moving platform. After that locations are updated as relative location from the moving base platform so they should stay nicely in sync. Even with packet loss the relative locations are forced constantly and interploated to so there should never really be any desync as far as I see it.
I’ll look into creating a custom AttachToComponent node. Was just checking if there wasn’t an easier way of doing this before digging into c++
I do understand why this is replicated by default, but I’d like to at least see an option to disable it for more advanced usecases.