Zandronum Chat on our Discord Server Get the latest version: 3.2.1
Source Code
My View | View Issues | Change Log | Roadmap | All Projects Issue Support Ranking | Rules | My Account
  

View Revisions: Issue #1705 [ All Revisions ] [ Back to Issue ]
Summary 0001705: Gametic-based unlagged
Revision 2015-01-17 13:14 by cobalt
Description I have implemented a very rough form of gametic-based unlagged.

- The server's gametic is sent to the client, either in a truncated form (at the same time player positions are sent), or the whole thing (during a full update).
- The client gets this message concerning the gametic and saves said gametic, as well as the "local" gametic it got the message on.
- When sending out player movement commands, the client also sends the 'predicted' server gametic that it thinks it is looking at. This is the last server gametic it received from the server plus any difference between the current "local" gametic and the local gametic it got the last server gametic on.
- When the server gets the client's move command, it takes the predicted gametic it was sent and puts it in the player struct for future reference.
- Finally, the unlagged function that determines how far back to do backwards-reconciliation uses the player's predicted server gametic instead of ping.

Note that I did run into an assertion crash yesterday when I first this patch out that only manifested itself when players disconnected (not quit), but I have not been able to replicate it since then and I might have even stomped out the problem (as I had made a few tiny changes since I first got it working until the final commit c1c8539), but please do a quick double-check over the patch to make sure I'm not forgetting about something.

Potential improvements:
- Better clientside prediction of serverside gametic?
- Is always accepting the server's gametic a good idea? Perhaps it would be a better idea to ignore the server's gametic in cases where the server -> client gametic is less than the client's stored server gametic, but is not big enough to warrant a wraparound...that way out of order packets don't have an effect on the client.
- Perhaps the client's predicted gametic sent to the server could be packed into a byte or short in much the same way that the server sends the client its gametic.
- Could the client's predicted gametic also be used as a replacement for the sequence number or other instances where gametics are passed around?
Revision 2014-02-13 02:34 by AlexMax
Description I have implemented a very rough form of gametic-based unlagged.

- The server's gametic is sent to the client, either in a truncated form (at the same time player positions are sent), or the whole thing (during a full update).
- The client gets this message concerning the gametic and saves said gametic, as well as the "local" gametic it got the message on.
- When sending out player movement commands, the client also sends the 'predicted' server gametic that it thinks it is looking at. This is the last server gametic it received from the server plus any difference between the current "local" gametic and the local gametic it got the last server gametic on.
- When the server gets the client's move command, it takes the predicted gametic it was sent and puts it in the player struct for future reference.
- Finally, the unlagged function that determines how far back to do backwards-reconciliation uses the player's predicted server gametic instead of ping.

Note that I did run into an assertion crash yesterday when I first this patch out that only manifested itself when players disconnected (not quit), but I have not been able to replicate it since then and I might have even stomped out the problem (as I had made a few tiny changes since I first got it working until the final commit c1c8539), but please do a quick double-check over the patch to make sure I'm not forgetting about something.

Potential improvements:
- Better clientside prediction of serverside gametic?
- Is always accepting the server's gametic a good idea? Perhaps it would be a better idea to ignore the server's gametic in cases where the server -> client gametic is less than the client's stored server gametic, but is not big enough to warrant a wraparound...that way out of order packets don't have an effect on the client.
- Perhaps the client's predicted gametic sent to the server could be packed into a byte or short in much the same way that the server sends the client its gametic.
- Could the client's predicted gametic also be used as a replacement for the sequence number or other instances where gametics are passed around?




Questions or other issues? Contact Us.

Links

Copyright © 2000 - 2025 MantisBT Team
Powered by Mantis Bugtracker