Add client owned transform sync to server.

[Jambax]

@agentx64;728921

Hello,

I’m willing to bet this has been asked before, but now that we have motion controllers for vr, we really will need this feature for multiplayer support. The idea is to have a tick box, just like the “replicated” tickbox - maybe called “owner sync transform to server” that will send from the client the transform of a scene component or actor belonging to the client owned unreliably and also the possibility for the server to have a callback event when the transform has been recieved by the client to either reject or accept the new transform (validation). by default, the default implementation accepts the new transform, but the blueprint or c++ code can override this callback event/method and decide if the new transform should be accepted or rejected from the owning client.

This is already what Character Movement Component does. Client simulates and tells server it’s transform. Server accepts or rejects it withing a tolerance and sends the transform back. It also does a lot of other stuff like timestamp verification etc, since no two computers have the same clock speed. ANY kind of server-authority (even if lax), will have the same problem you described - at some point it will have to tell the client the transform. Also unless you want the Server and other clients to jitter, you will have to predict the clients movement on the server using dead reckoning, which makes validating a transform all the more difficult because the Server is always simulating with old data. It’s not an easy issue.

@agentx64;728921

This way we can not use slow and poor performance rpc calls for these complex scenarios where no movement component matches our requirements. I’m well aware this opens up cheating, but if you write a good server side validation method, you could prevent it. or at least use it as last resort. (use character movement component where possible)

A checkbox would use an RPC call. Character Movement sends out RPC’s on tick, there’s no other way to do it.

@agentx64;728921

Unity has the ability to sync transform from owning client to server… why not unreal have this feature for complex scenarios. Basically, we need a “control rotation” for the motion controller component.

Because Unreals’ heritage is competitive shooters, where Server Authority is the only viable answer. You can add this functionality yourself very easily (see below).

---

If you’re doing Multiplayer VR, then my suggestion is that you let the client cheat and be authoritative of their position. If you’re making a competitive VR shooter where server authority matters, I suggest having a word with your game designer.

I wouldn’t even bother validating transforms, since at some point you’ll have to send an update back and you’ll be right back in the position. You will be surprised at how many times you have to do this and how quickly players will go out of sync. Corrections happen all the time.

This is really easy to achieve yourself. Requires C++ however, and you’ll have to implement smoothing for other players so that they don’t jitter. You still need to replicate movement, so that other clients can see updates and so that the client can see the Server. I would suggest creating a custom movement component for this since modifying character movement will be a ballache.

In the Pawn, override PostNetReceiveLocationAndRotation():

void AMyPawn::PostNetReceiveLocationAndRotation()
{
    if (Role == ROLE_SimulatedProxy && IsLocallyControlled())
    {
        // Do Nothing. Client is in control of position
    }

    Super::PostNetReceiveLocationAndRotation();
}

Then in your movement component, use an Unreliable RPC to send the required FRepMovement struct to the Server every tick (transform isn’t enough data). You will need to set velocities etc. on the Server as well (and on remote clients when they get the data from the Server), or they will jitter.

You have one other problem - since the Server is always simulating behind Client, other objects won’t have proper positional authority either (like weapons etc.) So you’ll also need to implement client-side hit-detection as well.