Announcement

Collapse
No announcement yet.

Quick move pawn/delay question

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Quick move pawn/delay question

    So its a dedicated server with 2 clients. Client 1 presses a button to enter a vehicle. I was having a nightmare with collision issues moving the pawn into the vehicle, so instead I move him out the way into the distance, make him invisible and spawn a proxy driver in the vehicle. This all works ok on client 1. When client 2 attempts to enter, the "real pawn" never moves out the way on the client, but the server seems to know its been moved. Why doesn't the client get the updated position of the pawn?

    I've noticed that if I use a slight delay Client 2 will realise the pawn has moved. The problem with this is there's a slight jerkiness/flicker in the camera as it tries to follow the pawn moving to its new location then snaps back to the vehicle camera when it gets possessed. Any suggestions what I can do here please?
    Click image for larger version

Name:	Untitled1.jpg
Views:	68
Size:	119.6 KB
ID:	1600500


    #2
    Is this logic being run directly on the server? If so, I think that's your issue. Upon interacting, have the client locally run the SetActorLocation logic before hitting the server's RPC, and keep this logic the exact same for the server. That should clear up jerkiness and the character being out of sync with the server. The problem with the camera may be a bit tricky, and is not an area I'm super familiar with. I'd recommend playing with a few different solutions until you get the right one. For example, for the client only, do a Set View Target With Blend to the vehicle's camera (before moving the pawn). Then, once the server has reported back that the vehicle is possessed, you're good to go. I have a feeling that will resolve your issue there, but again I haven't had this issue so I may be way off.

    Also, be careful with how you handle that pawn. While it's hidden in game, collision is still present. This pawn can still be shot in a shooter, for example, and will still block movement of other players. EDIT: I just saw your other post, so I'm assuming you've already handled the collision as well, and it just isn't part of this screenshot
    Last edited by One Mode Only; 03-29-2019, 09:16 AM.

    Comment


      #3
      Thank you for replying. I did originally have the logic running on both the server and client but as I'm changing the skeletal mesh on the proxy driver to the incoming character I was getting 2 different characters sitting in the drivers seat (the servers and the clients), and I wasn't sure how to fix this. This is how I have it at the moment:
      Click image for larger version

Name:	Untitled3.jpg
Views:	57
Size:	130.8 KB
ID:	1600617

      by adding a delay of 0.027 at the end of the logic I've managed to let the client catch up with the server and theres barely a noticeable jump.

      Another issue I've run into and I might have to post a separate thread for this, but I have Two bone IK setup on the proxy driver's wrists to link to the steering wheel. Works fine as a single player/listen server, but not on clients. In the proxy driver anim blueprint I set the location of the anchor points, but this logic never seems to run on clients. There doesn't appear to be a Switch Authority node on the anim blueprint, why is this?

      Comment


        #4
        Glad you got it working. I wouldn't recommend executing all logic on the client and server -- I would only execute logic which deals with visuals on the client. Movements, animations, anything the client needs to see instantly. Then, still execute all game-effecting logic like movement on the server. So, you would essentially be doing very similar things on the server and client, but the paradigm is that any logic done on the client is only for visual purposes and to keep the client in sync with the server. In this example, you would not run the possess logic on the client, but rather prepare the client as much as you possibly can, in order to keep visuals clean, smooth, and lag-free for the client.

        The animation blueprint will be executed on the clients as well. You don't want to do different logic based on authority inside of the animation blueprint. Rather, it is best practice to setup replicated variables inside of the character itself, retrieve those variables from the character inside of the anim bp, and then set your behavior based on those variables. The server will handle the replicated variables with server specific logic. Like, are we driving a vehicle? Set this variable here. Then, in the animation blueprint, retrieve that variable for reference, and handle accordingly. Make sure the anchor points and everything else you rely upon within the anim bp are replicated and set by the server. Not replicated inside of the animation blueprint itself, but the variables your retrieve from the character.

        In a more "advanced" setup, you'd have owner-only variables, play animations for the owner based on those, and then have everyone else use the replicated variables from the server. This makes the client see things instantaneously, and gives a buttery smooth (and lag free) experience for players. In this example, you'd have two variables, we'll say they're booleans, isDrivingVehicleServer (replicated) and isDrivingVehicleOwner (not replicated). The server always sets isDrivingVehicleServer, and the owner always sets isDrivingVehicleOwner. In the animation blueprint, to check if we should be doing IK logic for the hands on the steering wheel, we would essentially say "am I a non-owner and isDrivingVehicleServer = true?" OR "am I the owner and isDrivingVehicleOwner = true?".

        Oh, also, just thought I'd mention since you're working with a dedicated server. Test your setup on the client with the net pktlag=150 console command, where 150 is any number you'd like to simulate for ping. If you don't set things up to be done by the client and server, while testing with simulated lag, you'll notice very quickly why a person would do things on both the client and server. In a server-authoritative setup, there will be very noticeable delays for everything. This is the exact problem we alleviate by doing visuals locally, and logic on the server.
        Last edited by One Mode Only; 03-29-2019, 11:07 AM.

        Comment


          #5


          Thank you very much for your help One Mode Only. Really appreciated. I moved the hand logic over to the character blueprint and they now work. However, I've noticed when the vehicle goes over a certain speed the hands seem to shake/vibrate. Not sure whats happening there, maybe the client thinks the hand position was so far away on the last frame it needs to apply motion blur?

          I've also tried bringing the head rotation logic from the vehicle into the proxy driver blueprint. The head also seems to shake a little/snap within the first 3 seconds of rotating the camera, then it seems fine on the owning client. Despite making the spring arm replicated, other clients don't see the other clients heads rotating. Any ideas why please?

          EDIT- So I've just realised that its the rotation of the spring arm that isn't getting replicated on the server or other clients. I've marked the springarm component for replication and the Relative Rotation of the spring arm is also set for replication. I'm guessing I somehow have to replicate the Input Axis Value to the server and client so they know where the spring arm is rotating?

          Click image for larger version  Name:	head-rotation.jpg Views:	1 Size:	185.2 KB ID:	1601477
          Last edited by FrankyFurter; 04-01-2019, 03:46 AM.

          Comment


            #6
            To combat the "vibrating" effect, I'd suggest only applying the IK logic once. It sounds like it's running every frame which can definitely lead to some jittering.

            For the rotating, you could try applying the logic locally and then hitting an RPC on the server with an input of the axis value. That should always replicate the end-result, which of course would be the rotation of the head. The order does matter here, as if you hit the RPC and then do the client logic you're likely to experience jittering.

            Comment

            Working...
            X