I'm currently working on the networked character controller.
The steps for processing the character controller are the following:
Client gets user inputs
Client send inputs to server
Client process inputs
Server process inputs
So, I noticed that even with small movements, client and server get out of sync very quickly.
Then I realized that NetworkTransport systems are currently updating at no fixed rate. I did a test by moving both client and server transports to the ApplyPhysicsGroup, and updating them after NetworkClientSystem
In the next videos, there are 2 spheres showing the position of the character in the server and client. White sphere is for server position while green one is the client.
As can be seen in the videos, the client position is always ahead, that's because the client updates the position before the server does. But in the "Not fixed rate" version, spheres always end up in different positions while in the "Fixed rate" version the characters end up at exactly the same position. The difference in positions on the "Not fixed rate" are apparently small, but that small error was caused in a couple of seconds, after a few minutes, the error will be huge.
Conclusion
Without a fixed rate update, seems to be impossible to have client prediction in character controllers. So TransportSystems should be working at a fixed rate step.
As already stated in the code comments probably the best would be [UpdateInGroup(ApplyPhysicsGroup), OrderLast=true]
Description
I'm currently working on the networked character controller.
The steps for processing the character controller are the following:
So, I noticed that even with small movements, client and server get out of sync very quickly.
Then I realized that NetworkTransport systems are currently updating at no fixed rate. I did a test by moving both client and server transports to the ApplyPhysicsGroup, and updating them after NetworkClientSystem
Results
In the next videos, there are 2 spheres showing the position of the character in the server and client. White sphere is for server position while green one is the client.
Not fixed rate
https://user-images.githubusercontent.com/30969828/122949451-49d59080-d341-11eb-86c9-42cc078a25bb.mov
Fixed rate
https://user-images.githubusercontent.com/30969828/122949530-58bc4300-d341-11eb-9b6e-1f64e4fa0622.mov
As can be seen in the videos, the client position is always ahead, that's because the client updates the position before the server does. But in the "Not fixed rate" version, spheres always end up in different positions while in the "Fixed rate" version the characters end up at exactly the same position. The difference in positions on the "Not fixed rate" are apparently small, but that small error was caused in a couple of seconds, after a few minutes, the error will be huge.
Conclusion
[UpdateInGroup(ApplyPhysicsGroup), OrderLast=true]