MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001222Zandronum[All Projects] Bugpublic2012-12-22 05:332018-09-30 22:42
ReporterWatermelon 
Assigned ToTorr Samaho 
PrioritynormalSeveritytweakReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version1.2 
Target Version1.3Fixed in Version 
Summary0001222: Players who jitter due to a bad connection can void collision detection
DescriptionI noticed when playing CTF that players who have a jitter to their play have occasionally gone through the flag even though they should have connected. I don't know how this actually works, though it appears that Zandronum I guess waits for the incoming packets, and if it gets lets say 6-7 tic commands worth of +forward, it processes them all at once (which in turn causes that jitter effect since the middle is not interpolated too much). I tried using cl_ticsperupdate >1 to see if that'd help, but this appears to be a server side issue or something since players shouldn't go through flags. I've also had on weird occasions when I lag where I run through players even though it should be impossible. It's quite rare since the timing has to be more or less perfect, but I've seen Cyber go through the flag with his lag, and others teleport right through me.

On odamex this doesn't happen since players who lag are interpolated really quickly to their location. This also may be the cause of that speedhack that KGSWS created.

Could this issue be existent or maybe could it be an illusion on my end?
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0001079closed Torr Samaho Client greatly mispredicts its z position if pushed over a ledge by something else 
related to 0000839closed Torr Samaho Some players end up skipping a lot online even though cl_ticsperupdate is 1 
Attached Files? Zandronum_07.04.2013_06.10.04_doom2.wad_cupctf.wad.cld (136,115) 2013-04-07 10:20
https://zandronum.com/tracker/file_download.php?file_id=961&type=bug
? Zandronum_10.06.2013_23.34.43_doom2.wad_idl2012i.wad_idl2012ttamusmb2.wad.cld (169,338) 2013-06-11 03:44
https://zandronum.com/tracker/file_download.php?file_id=979&type=bug
? Zandronum_29.06.2013_23.23.33_doom2.wad_skulltag__actors.pk3_skulltag__data__126.pk3_idl2012i.wad.cld (145,018) 2013-06-30 03:29
https://zandronum.com/tracker/file_download.php?file_id=990&type=bug
? Zandronum_30.07.2013_14.20.13_doom2.wad.cld (162,250) 2013-07-30 18:30
https://zandronum.com/tracker/file_download.php?file_id=1034&type=bug
diff ticbuffer.diff (10,145) 2013-08-05 19:45
https://zandronum.com/tracker/file_download.php?file_id=1040&type=bug
? Zandronum_05.08.2013_19.34.07_doom2.wad.cld (80,159) 2013-08-05 23:45
https://zandronum.com/tracker/file_download.php?file_id=1041&type=bug
Issue History
Date ModifiedUsernameFieldChange
2012-12-22 05:33WatermelonNew Issue
2012-12-22 08:15ZzZomboNote Added: 0005544
2012-12-23 12:05Torr SamahoNote Added: 0005550
2012-12-23 12:26DuskStatusnew => needs testing
2012-12-23 16:53WatermelonNote Added: 0005551
2012-12-23 16:53WatermelonNote Edited: 0005551bug_revision_view_page.php?bugnote_id=5551#r3042
2012-12-24 03:10Edward-sanNote Added: 0005556
2012-12-29 04:41WatermelonNote Added: 0005607
2013-01-09 23:16DuskTarget Version => 1.1
2013-01-13 09:45Torr SamahoNote Added: 0005748
2013-01-21 16:32WatermelonNote Added: 0005808
2013-01-21 16:33WatermelonNote Edited: 0005808bug_revision_view_page.php?bugnote_id=5808#r3178
2013-04-07 10:20ArcoFile Added: Zandronum_07.04.2013_06.10.04_doom2.wad_cupctf.wad.cld
2013-04-07 10:22ArcoNote Added: 0006266
2013-04-07 10:30ArcoNote Edited: 0006266bug_revision_view_page.php?bugnote_id=6266#r3462
2013-04-07 11:50DuskStatusneeds testing => new
2013-04-07 14:57ZzZomboNote Added: 0006269
2013-04-07 20:19DuskRelationship addedrelated to 0001079
2013-04-15 17:54WatermelonNote Added: 0006286
2013-06-08 04:37WatermelonNote Added: 0006371
2013-06-11 03:44ArcoFile Added: Zandronum_10.06.2013_23.34.43_doom2.wad_idl2012i.wad_idl2012ttamusmb2.wad.cld
2013-06-11 03:47ArcoNote Added: 0006419
2013-06-16 08:58Torr SamahoNote Added: 0006449
2013-06-23 20:14DuskTarget Version1.1 =>
2013-06-29 18:46Torr SamahoNote Added: 0006523
2013-06-29 18:46Torr SamahoAssigned To => Torr Samaho
2013-06-29 18:46Torr SamahoStatusnew => needs testing
2013-06-30 03:29ArcoFile Added: Zandronum_29.06.2013_23.23.33_doom2.wad_skulltag__actors.pk3_skulltag__data__126.pk3_idl2012i.wad.cld
2013-07-30 17:09ArcoNote Added: 0006845
2013-07-30 18:04Torr SamahoNote Added: 0006848
2013-07-30 18:29ArcoNote Added: 0006849
2013-07-30 18:30ArcoFile Added: Zandronum_30.07.2013_14.20.13_doom2.wad.cld
2013-07-30 18:30ArcoNote Edited: 0006849bug_revision_view_page.php?bugnote_id=6849#r3825
2013-07-30 18:40Torr SamahoNote Added: 0006851
2013-08-03 00:49ArcoNote Added: 0006900
2013-08-03 00:55ArcoNote Edited: 0006900bug_revision_view_page.php?bugnote_id=6900#r3872
2013-08-05 19:45Torr SamahoFile Added: ticbuffer.diff
2013-08-05 23:45ArcoNote Edited: 0006900bug_revision_view_page.php?bugnote_id=6900#r3889
2013-08-05 23:45ArcoFile Added: Zandronum_05.08.2013_19.34.07_doom2.wad.cld
2013-08-06 19:24Torr SamahoNote Added: 0006918
2013-08-07 14:13ArcoNote Added: 0006922
2013-08-12 19:29DuskRelationship addedrelated to 0000839
2013-08-26 17:00WatermelonNote Added: 0007067
2013-08-27 18:27Torr SamahoNote Added: 0007073
2014-01-12 09:23Torr SamahoNote Added: 0007971
2014-01-12 09:23Torr SamahoProduct Version => 1.2
2014-01-12 09:23Torr SamahoTarget Version => 1.3
2014-01-12 11:19Edward-sanNote Added: 0007975
2014-01-12 11:20Torr SamahoNote Added: 0007976
2014-01-12 11:22Edward-sanNote Edited: 0007975bug_revision_view_page.php?bugnote_id=7975#r4400
2014-01-12 11:23Edward-sanNote Edited: 0007975bug_revision_view_page.php?bugnote_id=7975#r4401
2014-01-12 11:25Torr SamahoNote Added: 0007977
2014-06-06 02:28ArcoNote Added: 0008856
2014-06-06 02:28ArcoStatusneeds testing => resolved
2014-06-06 02:28ArcoResolutionopen => fixed
2018-09-30 22:42Blzut3Statusresolved => closed

Notes
(0005544)
ZzZombo   
2012-12-22 08:15   
Possibly related to'http://zandronum.com/tracker/view.php?id=844. [^]'
(0005550)
Torr Samaho   
2012-12-23 12:05   
Does the testing binary I posted in 0000844 behave differently?
(0005551)
Watermelon   
2012-12-23 16:53   
Do I compile 0000844 and run it on the server?
Or is it a client build?
(0005556)
Edward-san   
2012-12-24 03:10   
It contains both windows client and server binaries, no need to compile.
(0005607)
Watermelon   
2012-12-29 04:41   
I put the build code in and on a 2+ hour test of CTF tonight there were still people who at times avoided collision detection and went through the players in a thin alley that you can't go through. It's rare though. Could it be a lag issue or something else? Possibly illusion?
(0005748)
Torr Samaho   
2013-01-13 09:45   
I can't say for sure whether it's just illusion. Can you reproduce the effect deliberately and make a demo of it?
(0005808)
Watermelon   
2013-01-21 16:32   
(edited on: 2013-01-21 16:33)
I will try over the next few days to get a demo to rule out possible illusions or lag.
(0006266)
Arco   
2013-04-07 10:22   
(edited on: 2013-04-07 10:30)
Tested. Using ping emulation, I was able to reproduce this and observe the behavior. It appears that it also affects items as well, along with what has been already stated. I was able to make contact with the flag only a few tics later. The demo that I have uploaded validates this.

'http://sickedwick.net/wads/cupctf.zip [^]'
(0006269)
ZzZombo   
2013-04-07 14:57   
Now I remember a bug on Stronghold: there is a teleporter room where all late joiners are end up. If you lag you can get through the pushing lines after several attemps.
(0006286)
Watermelon   
2013-04-15 17:54   
Is the player ticked during the packets coming through? If we can't just quick patch it with ticking the player really fast then I have a solution but it won't make it into 1.1
(0006371)
Watermelon   
2013-06-08 04:37   
Interestingly this has also been reporting for possibly missing jump pads and such, though this may be linked to something that was fixed for 1.1.

It will be interesting to see if this is solved in 1.1
(0006419)
Arco   
2013-06-11 03:47   
I've used ping emulation with the latest version, and it does not conform the fix. Demo added.
(0006449)
Torr Samaho   
2013-06-16 08:58   
If multiple movement commands arrive at the server during the same tic, the server will execute all of them in this one tic. This will lead to position jumping problems, I'm not sure though whether this will allow the player to avoid collusion since the player is ticked with each movement command.

Watermelon, you mentioned that Odamex is using a tic buffer to prevent too many movement commands to be executed at once. We could handle this similarly in Zandronum and hopefully fix the problems this way.
(0006523)
Torr Samaho   
2013-06-29 18:46   
I implemented a tic buffer. It's still very experimental and most likely won't be included in 1.1, but it would be nice if somebody can do some testing with this binary to see how it works.
(0006845)
Arco   
2013-07-30 17:09   
I've thoroughly tested and played with the tic buffer and I can't say really say if it makes any difference regarding Zandronum's netstate. I used some memory consuming maps along with a high bot count and ping emulation and it seems that that the tic buffer behaves similarly as the current net system that's already used.
(0006848)
Torr Samaho   
2013-07-30 18:04   
The skipping / teleporting of players should be gone when the tic buffer is used. Did you still observe such effects? If so, can you record a client side demo of these effects?
(0006849)
Arco   
2013-07-30 18:29   
(edited on: 2013-07-30 18:30)
I've uploaded a demo using just doom2.wad to re-create these effects. While I couldn't get my client to teleport, skipping and other awkward movement was observed.
(0006851)
Torr Samaho   
2013-07-30 18:40   
Judging from the demo I think I didn't make clear what the tic buffer is supposed to do. It will mainly change how a player observes the movement of the other players. So if a player has a stable connection, other players with a bad connection shouldn't appear as teleporting around for the player with the stable connection. Can you test this?
(0006900)
Arco   
2013-08-03 00:49   
(edited on: 2013-08-05 23:45)
Quote from Torr Samaho
Judging from the demo I think I didn't make clear what the tic buffer is supposed to do. It will mainly change how a player observes the movement of the other players. So if a player has a stable connection, other players with a bad connection shouldn't appear as teleporting around for the player with the stable connection.


Sorry that that. I was confused as to whether the problem was correlated with one client.


EDIT: I've connected two of my own clients into the server while recording this. One has an average ping of 10 ms, while the other client has an emulated ping of +600 ms. The new demo that I have uploaded demonstates the teleporting problem as noted in your description. I apologize for my mistake I made earlier.
(0006918)
Torr Samaho   
2013-08-06 19:24   
Thanks for the new demo! Can you tell me how many tics I have to skip with demo_skiptics to jump to the teleporting part?
(0006922)
Arco   
2013-08-07 14:13   
That demo I uploaded a few days ago doesn't really reproduce the effect as much as this one does.
(0007067)
Watermelon   
2013-08-26 17:00   
Important videos of what happens on Odamex when someone has intense lag issues:
1)'http://www.youtube.com/watch?v=mADUCk5XQF4 [^]'
2)'http://www.youtube.com/watch?v=fOkgM20CKyk [^]'

The purpose of the ticbuffer should be to smooth out laggy players, but not leave them with the advantage of still being able to recklessly escape anyways (video 1) by providing a large enough ticbuffer that they can just speed out of the base, and should consider a cap to prevent any kind of abuse like rushes that people could simulate manually (video 2).

Since some servers will not want any kind of cap on their laggy players (ex: coop), I think the ticbuffer's cap should be a cvar that is set by default to MAXSAVETICS or whatever the definition is for the max unlagged tics saved.

Then, unlagged's MAXSAVETICS should be turned from a define into a cvar which can range from 1 - (35 or 70). While it's extremely harsh to only allow for one gametic, the problem with unlagged is that people with excessive ping spikes gain an unfair advantage and can shoot people extremely far behind walls. There's a few guys I know who purposely refuse to update their [horrible] internet for the literal sake of them getting away with ridiculous shots. They had enough balls to say it publicly, and some of those players are actually on Zandronum itself and encountered on a frequent basis. Therefore if we were allowed to cap it, the server could set it to something reasonable (6-7). There would have to be a warning for a map restart like when the server wants to enable sv_cheats. Interestingly QuakeLive or one of the quake ports has a built in unlagged cap at 80-90ms for this exact reason.

Any tics that are not caught within sv_maxunlaggedtics (or w/e it would be called) would essentially be dropped. I created a custom binary and hosted it with a proxy emulator to see how it is, and it's annoying for the person who drops packets; though one of the major complaints on odamex from the playerbase due to their unlagged being extremely perfect... is that "any lag disadvantages are pushed onto the non-laggy players as disadvantages to compensate for their bad internet."
We should ideally try and avoid this same pitfall, or at least add an option so that people can choose what they desire for their own server.



Lastly if anyone is worried about a server admin turning it off to confuse people, remember that they could easily just turn sv_nounlagged to true.
(0007073)
Torr Samaho   
2013-08-27 18:27   
I don't agree with this interpretation of unlagged. As far as I can tell you don't give any advantage to high ping players, you are just reducing some of the drawbacks of a high ping. People with high ping are not shooting through walls (although it may feel like this). IMHO the technically correct interpretation is that the attacked player was already hit before hiding behind the wall, the information about the hit is just delayed. High pingers always have the disadvantage of a delayed information about being hit, unlagged extends this disadvantage to low ping players attacked by high ping players, but this just levels the playing field and I don't see how this is an advantage for high pingers compared to low pingers.

The whole unlagged system was developed to allow people with a higher ping to enjoy the game. If you disable unlagged for high pingers IMHO you are defeating its whole purpose.

Also, if anybody thinks a high ping is an advantage, they are free to raise their ping.

Note that I'm only talking about ping spikes. Effects of those are bad, but that's what the tic buffer was intended to improve.
(0007971)
Torr Samaho   
2014-01-12 09:23   
Since my tic buffer patch seems to be already used successfully in kpatch, I finally added it to 1.3 and 2.0.
(0007975)
Edward-san   
2014-01-12 11:19   
(edited on: 2014-01-12 11:23)
I fail to compile:


src/sv_main.cpp: In function ‘void SERVER_Tick()’:
src/sv_main.cpp:569:68: error: ‘min’ was not declared in this scope
    for ( int i = 0; i < min ( g_aClients[ulIdx].MoveCMDs.Size(), 2 ); ++i )
                                                                    ^
src/sv_main.cpp:569:68: note: suggested alternative:
In file included from /usr/include/c++/4.8/bits/char_traits.h:39:0,
                 from /usr/include/c++/4.8/ios:40,
                 from /usr/include/c++/4.8/ostream:38,
                 from /usr/include/c++/4.8/iostream:39,
                 from src/networkheaders.h:97,
                 from src/sv_main.cpp:57:
/usr/include/c++/4.8/bits/stl_algobase.h:239:5: note: ‘std::min’
     min(const _Tp& __a, const _Tp& __b, _Compare __comp)
     ^
(0007976)
Torr Samaho   
2014-01-12 11:20   
Yeah, just noticed this too.
(0007977)
Torr Samaho   
2014-01-12 11:25   
Should be fixed now.
(0008856)
Arco   
2014-06-06 02:28   
I thoroughly tested this in v1.3 r140413-2324M with emulated ping and it appears to be working correctly.