|
Notes |
|
|
|
|
Has the server turned on the tic buffer? |
|
|
|
(0013739)
|
|
FTW395
|
|
2015-11-02 15:15
|
|
|
Yeah the server had tic buffer on. |
|
|
|
|
|
Strange, the tic buffer should prevent this. Can you post a client side demo of the effect? |
|
|
|
(0013757)
|
|
Dusk
|
|
2015-11-08 12:46
|
|
Quote from "FTW395"
Yeah the server had tic buffer on.
How do you know this? Note that the sv_useticbuffer value on the client does not necessarily match the value on the server. |
|
|
|
(0013790)
|
|
FTW395
|
2015-11-14 21:43
(edited on: 2015-11-14 21:45) |
|
|
|
|
|
|
Thanks for the demo! Please also send a demo from another person's perspective, i.e. from a perspective where you see the exploiting player jumping around. Sorry for not being clear about which perspective I need earlier. |
|
|
|
(0013874)
|
|
FTW395
|
|
2015-11-22 20:05
|
|
|
|
|
|
|
Was akways wondering why every1 jitter on this port, may be this case i guess? |
|
|
|
|
|
2015.11.22_21.51.52_duel40apk3.cld shows a slight jittering on one or two short occasions, no teleporting. Can you check the demo to confirm that this is the effect you are talking about? |
|
|
|
(0013921)
|
|
Ch0wW
|
2015-11-29 23:53
(edited on: 2015-11-30 01:22) |
|
I'll explain it simply.
Whenever someone is abusing this thing is having a short jittering (about 0000003:0000001 second), and a sudden and speedy teleport. It also features a huge lag amount to the player who's abusing it. I've spotted already a few users that are using it, with all the elements above (And I could post the names, at -any- time).
Video showing my POV/JCD's POV:'https://www.youtube.com/watch?v=WJNCsMsDLpg [^]'
@Capo : It's a different thing. It's about the server's FPS, who are locked to 35 (DooM normal ticrate). Hence the clientside jittery movements of every player when using uncapped FPS.
Possible workarounds:
Serverside: Check any kind of "Connection interrupted" behaviour from the client. If the player has this too many times (max: 3), instantly kick from the server, because of possible cheating. (Related note: players who play with an unstable connection are suffering the same fate. When someone plays competitively, they have to get at least a stable connection. Else you're giving them an advantage "legit" players won't have.)
Clientside: make a 10-seconds screenshot cooldown on competitive games. One screenshot is already enough to make someone exploit this glitch, by the way.
Also, it happens too on G/Zdoom.
|
|
|
|
(0013922)
|
|
Konar6
|
|
2015-11-30 14:43
|
|
Kicking players with unstable connection is not an option, I think this was being practiced back in early versions like 96f and it was amended.
Also if this works the way I think it does (CPU load), it could be done in other ways too. Or one can always start uploading porn... |
|
|
|
(0013923)
|
|
Ch0wW
|
2015-11-30 17:39
(edited on: 2015-11-30 17:40) |
|
Except we could still reenable 96f's behaviour through a CVAR (off by default). Shouldn't be that hard, and it could be enable a bit more protection about those abuses. So that option will still be valid, amended or not. Time has changed, and those measures can be fixed. And to me, that's a real reason to bring it back, but through a limited purpose.
I'm formerly against people who are playing competitively only while having a bad connection, or too much ping. That way, you give to those players an unfair advantage to legit players. Is that what players want?
Also, I was able to reproduce it too by disabling the sending of packets for a very few frames, in a repetitive way.
------------
Second idea:
- Add sv_allowscreenshot_ingame CVAR, so that clients can only take screenshots at the end of the game (or spectators at any time). Harsh way, but could also work well.
|
|
|
|
(0013924)
|
|
Dusk
|
|
2015-11-30 20:07
|
|
|
Throttling screenshots most certainly won't solve the problem. Stop suggesting ways to limit them. We need a different solution here. |
|
|
|
|
"@Capo : It's a different thing. It's about the server's FPS, who are locked to 35 (DooM normal ticrate). Hence the clientside jittery movements of every player when using uncapped FPS."
uhm and everyone use uncapped, gg this is really shame? fix plox... |
|
|
|
|
I fully agree with Dusk: throttling screenshots is not a solution. Players will always find ways to lag at will. Automatically kicking / banning lagging players is also not a solution. The danger of affecting innocent players is much too high.
Also keep in mind that it's irrelevant how the lagging player perceives his own movement. The only thing that matters is how the other players perceive the movement of the lagging player.
So far the tic buffer is the only thing we have that solves (part of) the problem. One thing we could test is to tighten what the tic buffer does to resolve bursts of movement packets. Currently it processes up to two movement commands per tic. We could easily reduce this to only process two movement commands every N tics and could even make that a server variable so that you can experiment with the effect this rate has on the gameplay. |
|
|
|
|
|
Kicking/banning for lag is sure bad solution. But maybe there could be some cvar like where you control which ppl can join your server, like "sv_maxping" where you set value of the ping you want ppl have in the server, above this value they got to have bad luck and have to find different server. This is pretty much for competitive purposes only. I am long time server hoster on odamex (shit i talk p much like Decay now). And i easy could use feature like this. I think its really interesting idea. Its like not ultimate solution ban all laggers and have only low pingers on server. I could easy host servers like "for low pingers only, sv_maxping 75" and i could host normal server open for everyone. I also know i am not fully on topic probably. But i dont understand why you disagree with chowww about ban the screen exploit. Its p much the problem nowadays. And there are only certain ppl. Saying "ppl will still find way to lag and shit" is i think exaggerated. |
|
|
|
(0018827)
|
|
Dusk
|
|
2017-11-08 21:42
|
|
|
Since the tic buffer has undergone significant changes recently, this one needs to be re-evaluated. |
|
|
|
|
|
The movement "regulator" was implemented and on top of that, the command buffer's emptying speed was reduced. |
|