MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001442Zandronum[All Projects] Suggestionpublic2013-08-01 05:502014-05-05 22:23
ReporterWatermelon 
Assigned To 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionduplicate 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0001442: Unlagged to tick based
DescriptionAs discussed elsewhere, with a ticbuffer being worked on, now would be the time to roll out unlagged based on ticks rather than the fickle ping, which works overall pretty good but is extremely unstable on wireless or devices prone to lag spikes and such. Tic based is a much stronger method of unlagged because you will be essentially responding with the tic that you fired in, rather than basing it off of ping.


First, the client will need a way of ensuring it gets the right gametic from the server. After that it will just send the gametic with each CLC_CLIENTUPDATE (I forget the header name) or w/e contains the ticcmd.

Second, the server will need to verify that it only gets one instruction per tic, or else it drops any/kicks them from the server. It must also ensure integrity (ex: if packet 800 is dropped, it should not get 800 when it's in the 1000's for example) and anything else that is exploitable.

Third, it should be linked ideally with the ticbuffer system.


In addition, maybe our cl_unlagged can turn into a bitmask rather than a bit?
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0001705closed Watermelon Gametic-based unlagged 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2013-08-01 05:50WatermelonNew Issue
2013-08-01 05:50WatermelonStatusnew => assigned
2013-08-01 05:50WatermelonAssigned To => Watermelon
2013-08-01 05:53WatermelonNote Added: 0006872
2013-08-02 17:13DuskNote Added: 0006895
2013-08-07 18:55Torr SamahoNote Added: 0006929
2013-08-08 20:22WatermelonNote Added: 0006948
2013-08-08 20:23WatermelonNote Edited: 0006948bug_revision_view_page.php?bugnote_id=6948#r3906
2013-08-08 20:26WatermelonNote Edited: 0006948bug_revision_view_page.php?bugnote_id=6948#r3907
2013-08-10 15:29WatermelonNote Added: 0006976
2013-08-28 21:19Torr SamahoTarget Version1.2 =>
2013-09-18 17:14WatermelonNote Added: 0007220
2014-05-05 22:22WatermelonAssigned ToWatermelon =>
2014-05-05 22:23WatermelonAssigned To => Watermelon
2014-05-05 22:23WatermelonAssigned ToWatermelon =>
2014-05-05 22:23WatermelonStatusassigned => new
2014-05-05 22:23WatermelonRelationship addedrelated to 0001705
2014-05-05 22:23WatermelonNote Added: 0008705
2014-05-05 22:23WatermelonStatusnew => closed
2014-05-05 22:23WatermelonResolutionopen => duplicate

Notes
(0006872)
Watermelon   
2013-08-01 05:53   
Note: I do not propose removing the ping unlagged because it's stood the test of time, but this would be another option.
(0006895)
Dusk   
2013-08-02 17:13   
If the tic-based unlagged is overall better than the ping-based one then it should replace the ping-based one or at least be made default.
(0006929)
Torr Samaho   
2013-08-07 18:55   
As I stated already via PM: The server should put as little trust as possible on anything it receives from a client. So it's very important that the checks you already mentioned are very thorough.

BTW: The clients already sent their gametic with CLC_CLIENTMOVE, so clients already sends enough information, but you still have to figure out how to sync gametic between client and server. I bet many other games already use such a kind of unlagged method. Did you already search for documentation of existing implementations?
(0006948)
Watermelon   
2013-08-08 20:22   
(edited on: 2013-08-08 20:26)
Well, the tracker just ate my 1000 word response, so that sucks.


Quick summary since I really don't feel like typing it all out again:

QUESTIONS:
- What happens if the server becomes bogged down? Does it try to do multiple gametics quickly? Or will the clients now desync completely because the server will be 10-20 tics behind in such a case? Care could be taken to write a safety net for the client around this.
- Do we need to send the clients tic? It seems like we could just have the client instead send back the servers last known gametic (or maybe 0xFFFFFFFF if unknown/no updates)
- Any reliable way of syncing them up? I spent a lot of time trying to think of a viable solution, but in the end it always came back to trusting the client, or making assumptions that nothing gets skewed or desynced. Any kind of desync is lethal in doom due to small bodies with fast speed

RESEARCH:
- Valve sends snapshots of the server time to the client, and the client responds with that
- ZDaemon claims to use the above
- Odamex trusts the client sending tic updates that it gets from the server
- Other netcode developers said that "worrying about someone hacking game ticks from the server with proper safety checking on the server is much more difficult for them and usually not worth it compared to making an aimbot or wallhack if your game is open source"

NOTES:
- Can put ticcmds in proper order since it will have the gametic. Of course right now it uses probably the ulClientTic field, but this could be replaced.
- Could we possibly detach from using the clients tics at all?
- Other engines claim that unlagged takes constant refinement to make it perfect, and does not come along in one go
- We need to consider putting a cap on our unlagged, but I can make a whole other ticket on why this should be considered


In addition, if we want to have the option to trust the client or not, then we could easily implement a sv_safeunlagged true/false which would switch to ping-based rather than tic based.
(0006976)
Watermelon   
2013-08-10 15:29   
Committed some basic stuff that is operational, but I plan on changing stuff up.
(0007220)
Watermelon   
2013-09-18 17:14   
When the ticbuffer is commited I will proceed on integrating this into it.
(0008705)
Watermelon   
2014-05-05 22:23   
Being handled in another ticket