So I have a player network object and camera that get spawned independently and linked inside my start function after spawning. on update ( I also tried Fixed update) the client gets all inputs and sends them through an RPC call. Originally In the RPC call, the server finds out which client sent the call, grabs the network objects related to that call, and assigns them to method variables of the types rigidbody(player), animator, and transforms (a virtual camera location, and the actual camera). I tried to use network object references and pass them through to the RPC call. This worked the exact same way, but was smoother but this is bad for network security. The virtual camera is a location the container of the camera is offset from for different viewing perspectives. An offset is calculated based upon which perspective is selected, and offsets the actual camera from the virtual location, so that when you toggle between the perspectives, the virtual location is used in the calculations for the new offset. It works perfectly in every regard to the host. But, when I try to add the client (without client prediction at this point) some weird stuff happens: 1) There is a really fast rubberbanding effect that happens, that actually keeps the player's location from updating like it should? It's almost as if the player is sending updates too soon, but when I moved into the fixed update method, the issue got even worse and the player couldn't move barely at all. 2) when I remove the add force step that limits the velocity vector on the rigidbody, the movement is basically equal to what the server does (albeit still kinda rubber bandy), but obviously, this is terrible considering the movement force just increases like a bat outa hell. I was at one point trying to not act upon the rigid bodies via the network and just send back the positions, but am 100% just utilizing the network transform, network rigidbody, and network animator field. One thing that might be going on is that the serverRPC is being called at a rate such that the player's position in the network doesn't update fast enough, and does the same calculation over and over again. Another concern is that I don't like having to grab the references of the rigidbodies, etc from the networkmanager. I did try to pass the positions of the player through, have the server run the code on the positions and pass the changes back and then move. (obviously didn't work authoritative, duh) Still the same issue with player movement via physics. I know the concept is mostly correct, because I do the same sort of operations with the camera object with it's transform, so that leads me to believe that there is something going on under the hood with the physics that I am not accounting for properly. Also, my code could use with some refactoring as the code is really complex, but because the mixing of different perspectives in the same area of code is really different. I could refactor it, but I don't plan on doing so until the movement issue is fixed. Just to clarify: the issue isn't tied to visual jitteriness , it's with actual movement on both the server and client side. If I don't account for visual perception, the player simply jitters from where they should be back and then forward again incredibly fast, with an extremely small positive displacement no matter the direction. Any suggestions on what I should do, look at, or try?