0001839: Reduce/eliminate player "skipping": sv_maxpacketspertic

Notes
(0009505) Watermelon (developer) 2014-06-16 03:29 edited on: 2014-06-16 23:23	I need other developer input for a few things: 1) I added this in my custom servers, everyone liked it a lot because it leveled the playing field in competitive games. Now with the IDL coming to Zan and the ZDDL possibly opening up, there's a lot of people affected by this. 2) No words describe how infuriating teleporting players are. Just play against them on a small map, they ruin games. 3) The ticbuffer is nice, but it needs to be adjusted. The ticbuffer processes 2 ticcmd's at once, and sends the last one processed. It jitters weirdly because you're seeing only one of the momx/y. The server should really combine the momx_prev + momx_recent with momy_prev + momy_recent (and the same for Z) to make it realistic. This was a major complaint in my servers on how jittery the ticbuffer looks in practice. 4) This instruction should drop the packets. We have no choice really. I know you're thinking "we want to be fair", but people's shitty connection is being used to make it unfair for the regular players. - I do not propose that this be on by default - I propose bounds so that people who are dumb can't accidentally set the threshold to one packet and tank everyone (I recommend a lower bound of 7, or zero for infinite (as if it was off)) - I am not opposed however to seeing 1 packet per tic being a valid option 5) This would also cut down on a potential speed exploit too, since I'm pretty sure Shadowfox in another ticket uses this 'speed burst' to cheat his way past people. The key thing here: While I believe we should strive for making it as nice as possible for everyone... there is nothing that we can really do to remedy the 'speed boost' issue other than this. I've dealt with it for years and many others have as well. This literally costs people games. People loved this when I added the fix on my custom servers. I've tested it myself, and I never got one complaint (ok I lied, I got one... from the notorious lagger who was unbeatable when his net was crap). Please think heavily about this. I recall cold reception when I brought it up, and I really feel this should be addressed by keeping the offended group (legitimate players with stable internet) in mind.

(0009541) Torr Samaho (administrator) 2014-06-17 06:20	Dropping a movement command may completely mess up the corresponding player's movement prediction leading to teleportation effects locally for that player. If you regularly drop movement commands of a player I suspect that this would completely ruin the playing experience and make the game unplayable for that player. In that case, IMO it would be more honest to simply ban the player. You don't want a player with a bad connection on your server, that's your decision. But you shouldn't make the player believe that the game is broken (and come to us to complain about it), which would be a typical conclusion from the experienced behavior. I didn't test this myself, so I can't say for sure how the affected players will really perceive the dropping of the movement commands. So take my prediction with a grain of salt. For me the tic buffer was intended to be a compromise for the problems you describe. Can you make a demo that shows the effects that remain when the tic buffer is used? Quote from Watermelon People loved this when I added the fix on my custom servers. I never had access to the source code of your server, so I can't comment on this.

(0009681) Watermelon (developer) 2014-06-22 21:02 edited on: 2014-06-22 21:04	Expansion of IRC discussion: - Must be VERY clear it's a server feature, not how zan normally works Questions to answer: - Inform client when they connect that it drops packets in big bold messages? - Inform them if packets are discarded? Through a log Printf style, or through a big message at the center? Or elsewhere? - Is there a cap on how low it should be allowed in ticks? Ex: 0 means no cap, 1 means should only get one per second, or should the cap be [0], [7 - MAXINT]?

(0009685) Soul (reporter) 2014-06-22 22:18	Yes, it would be a good idea to inform clients when a server is capable of dropping packets (and the exact amount), but probably as simple print lines. The reason why I suggest it that way is that a big issue I had in the past was when Software rendering could not render 3D Floors, and you would be forced to see the big "SOFTWARE CANNOT RENDER 3D FLOORS" blocking your vision for precious seconds until it went away. If the client is going to warn the user about alterations in the game's behavior, they should all be printed out in simple logs as most warnings already are, so experienced players are not annoyed by big messages affecting their vision. The same goes for when players' packets are discarded during the game. This brings up another point of interest: unlagged. Servers can also disable unlagged completely. If the server is going to warn players about the packet handling divergence, should it also warn them beforehand if unlagged is disabled? I think so.

(0009751) JKist3 (reporter) 2014-06-26 08:21	How does sv_maxpacketspertic fix what ticbuffer only partially solves? skipping players do suck, but neither of these methods are likely the best way to mitigate this problem. A much better solution would to be to apply the principles of the quake3 unlagged netcode: 'http://www.ra.is/unlagged/ [^]' This counters skipping players by having the server move the player it hasn't received packets for and then making further adjustments when his packets come in if need be. This eliminates the teleportation effects from the lagging player, and greatly reduces how skippy he is to everyone else. The netcode principles in the quake3 unlagged code extend beyond just reducing player skipping and I'd love to see them get added here. If a dev is willing to implement them I'm more than happy to help out through testing and going over how the stuff should work.

(0009754) Torr Samaho (administrator) 2014-06-26 18:41	Quote from Watermelon Questions to answer: Before we discuss this in more detail I'd like to have a look at your implementation. This will make it easier for me to estimate how to proceed. Quote from JKist3 How does sv_maxpacketspertic fix what ticbuffer only partially solves? As far as I understood (can't say for sure since I didn't see the implementation), it's the most simple way that will work perfectly for all other players and worst possible for the affected player: The server processes one movement command per player and tic at most. Excessive commands are simply dropped.

(0009765) JKist3 (reporter) 2014-06-27 21:22 edited on: 2014-06-27 21:23	Quote from Torr Samaho As far as I understood (can't say for sure since I didn't see the implementation), it's the most simple way that will work perfectly for all other players and worst possible for the affected player: The server processes one movement command per player and tic at most. Excessive commands are simply dropped. That was my understanding too. I dont know how watermelon's tic buffer works completely, but I was assuming it only allows a certain number of commands per tic and saves excess commands to be executed in following tics. If this is true, the only difference between the tic buffer and this sv_maxpacketspertic is that sv_maxpacketspertic forgets excess commands while tic buffer delays them. If that is indeed the case I don't see why sv_maxpacketspertic is any better for the opponents of the lagging player than tic buffer is

(0009773) Torr Samaho (administrator) 2014-06-28 09:25 edited on: 2014-06-28 09:27	Quote from JKist3 I dont know how watermelon's tic buffer works completely, but I was assuming it only allows a certain number of commands per tic and saves excess commands to be executed in following tics. AFAIK there is no such thing as Water's tic buffer. I created a tic buffer a while ago for 1.3 and Water ported my implementation to Zan++. My tic buffer works exactly as you described: It saves all incoming movement commands of a player and processes up to two movement commands per tic (it's necessary to process more than one, otherwise the buffer would never empty after a lag spike) Quote from JKist3 If that is indeed the case I don't see why sv_maxpacketspertic is any better for the opponents of the lagging player than tic buffer is The main difference is that you only process one command per tic at most if you drop excessive commands while my tic buffer processes up to two (which makes the player faster than it should be). EDIT: I'd still like to see a demo showing the problems that remain when the tic buffer is active.

Only registered users can voice their support. Click here to register, or here to log in.
Supporters:	WaTaKiD rosking Frits swordgrunt edd Soul Leonard Combinebobnt
Opponents:	unknownna

Issue History
Date Modified	Username	Field	Change
2014-06-16 02:19	Soul	New Issue
2014-06-16 03:08	Watermelon	Status	new => needs review
2014-06-16 03:08	Watermelon	Assigned To	=> Watermelon
2014-06-16 03:08	Watermelon	Status	needs review => assigned
2014-06-16 03:17	Watermelon	Status	assigned => needs review
2014-06-16 03:29	Watermelon	Note Added: 0009505
2014-06-16 03:30	Watermelon	Note Edited: 0009505	View Revisions
2014-06-16 03:30	Watermelon	Note Edited: 0009505	View Revisions
2014-06-16 03:32	Watermelon	Note Edited: 0009505	View Revisions
2014-06-16 23:21	Watermelon	Note Edited: 0009505	View Revisions
2014-06-16 23:22	Watermelon	Note Edited: 0009505	View Revisions
2014-06-16 23:23	Watermelon	Note Edited: 0009505	View Revisions
2014-06-17 06:20	Torr Samaho	Note Added: 0009541
2014-06-17 06:20	Torr Samaho	Status	needs review => feedback
2014-06-22 21:02	Watermelon	Note Added: 0009681
2014-06-22 21:03	Watermelon	Assigned To	Watermelon =>
2014-06-22 21:04	Watermelon	Note Edited: 0009681	View Revisions
2014-06-22 21:04	Watermelon	Note Edited: 0009681	View Revisions
2014-06-22 22:18	Soul	Note Added: 0009685
2014-06-22 22:18	Soul	Status	feedback => new
2014-06-22 22:21	Watermelon	Status	new => needs review
2014-06-26 08:21	JKist3	Note Added: 0009751
2014-06-26 18:41	Torr Samaho	Note Added: 0009754
2014-06-26 18:41	Torr Samaho	Status	needs review => feedback
2014-06-27 21:22	JKist3	Note Added: 0009765
2014-06-27 21:23	JKist3	Note Edited: 0009765	View Revisions
2014-06-27 21:23	JKist3	Note Edited: 0009765	View Revisions
2014-06-28 09:25	Torr Samaho	Note Added: 0009773
2014-06-28 09:27	Torr Samaho	Note Edited: 0009773	View Revisions

Relationships