0002491: Screenshot exploit

(0013677)
Torr Samaho (administrator)
2015-10-18 19:26

Has the server turned on the tic buffer?

(0013739)
FTW395 (reporter)
2015-11-02 15:15

Yeah the server had tic buffer on.

(0013753)
Torr Samaho (administrator)
2015-11-08 11:16

Strange, the tic buffer should prevent this. Can you post a client side demo of the effect?

(0013757)
Dusk (developer)
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 (reporter)
2015-11-14 21:43
edited on: 2015-11-14 21:45

'http://www.mediafire.com/download/49a7ynbg6o2tau0/2015.11.14_22.38.11_doom2.zandrotdm-v-1gpk3.cld [^]' -> Demo of the bug
Server owner states that sv_useticbuffer is on.
If you want to get a demo from another person's perspective, feel free to ask

(0013794)
Torr Samaho (administrator)
2015-11-15 09: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 (reporter)
2015-11-22 20:05

Here's the demo from my perspective:'http://www.mediafire.com/download/pofh76446ebvu29/2015.11.22_20.53.03_doom2.duel40apk3.cld [^]'
And here's the demo from someone else's perspective:
'http://www.mediafire.com/download/zot8hz1ptnzvgue/2015.11.22_21.51.52_duel40apk3.cld [^]'

I'm the person who's repeatedly pressing the screenshot button as you can see by the teleporting I do.

(0013893)
capodecima (viewer)
2015-11-28 10:56

Was akways wondering why every1 jitter on this port, may be this case i guess?

(0013898)
Torr Samaho (administrator)
2015-11-29 11:37

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 (reporter)
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 (reporter)
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 (reporter)
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 (developer)
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.

(0013928)
capodecima (viewer)
2015-12-01 12:47

"@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...

(0013929)
Torr Samaho (administrator)
2015-12-01 20:49

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.

(0013930)
capodecima (viewer)
2015-12-01 23:02

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 (developer)
2017-11-08 21:42

Since the tic buffer has undergone significant changes recently, this one needs to be re-evaluated.

(0019178)
Leonard (developer)
2018-04-30 15:48

The movement "regulator" was implemented and on top of that, the command buffer's emptying speed was reduced.

Only registered users can voice their support. Click here to register, or here to log in.
Supporters:	Combinebobnt Ch0wW JC capodecima
Opponents:	No one explicitly opposes this issue yet.

Notes
(0013677) Torr Samaho (administrator) 2015-10-18 19:26	Has the server turned on the tic buffer?

(0013739) FTW395 (reporter) 2015-11-02 15:15	Yeah the server had tic buffer on.

(0013753) Torr Samaho (administrator) 2015-11-08 11:16	Strange, the tic buffer should prevent this. Can you post a client side demo of the effect?

(0013757) Dusk (developer) 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 (reporter) 2015-11-14 21:43 edited on: 2015-11-14 21:45	'http://www.mediafire.com/download/49a7ynbg6o2tau0/2015.11.14_22.38.11_doom2.zandrotdm-v-1gpk3.cld [^]' -> Demo of the bug Server owner states that sv_useticbuffer is on. If you want to get a demo from another person's perspective, feel free to ask

(0013794) Torr Samaho (administrator) 2015-11-15 09: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 (reporter) 2015-11-22 20:05	Here's the demo from my perspective:'http://www.mediafire.com/download/pofh76446ebvu29/2015.11.22_20.53.03_doom2.duel40apk3.cld [^]' And here's the demo from someone else's perspective: 'http://www.mediafire.com/download/zot8hz1ptnzvgue/2015.11.22_21.51.52_duel40apk3.cld [^]' I'm the person who's repeatedly pressing the screenshot button as you can see by the teleporting I do.

(0013893) capodecima (viewer) 2015-11-28 10:56	Was akways wondering why every1 jitter on this port, may be this case i guess?

(0013898) Torr Samaho (administrator) 2015-11-29 11:37	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 (reporter) 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 (reporter) 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 (reporter) 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 (developer) 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.

(0013928) capodecima (viewer) 2015-12-01 12:47	"@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...

(0013929) Torr Samaho (administrator) 2015-12-01 20:49	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.

(0013930) capodecima (viewer) 2015-12-01 23:02	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 (developer) 2017-11-08 21:42	Since the tic buffer has undergone significant changes recently, this one needs to be re-evaluated.

(0019178) Leonard (developer) 2018-04-30 15:48	The movement "regulator" was implemented and on top of that, the command buffer's emptying speed was reduced.

Issue History
Date Modified	Username	Field	Change
2015-10-14 15:52	FTW395	New Issue
2015-10-18 19:26	Torr Samaho	Note Added: 0013677
2015-10-18 19:37	Dusk	Status	new => feedback
2015-11-02 15:15	FTW395	Note Added: 0013739
2015-11-02 15:15	FTW395	Status	feedback => new
2015-11-08 11:16	Torr Samaho	Note Added: 0013753
2015-11-08 11:16	Torr Samaho	Status	new => feedback
2015-11-08 12:46	Dusk	Note Added: 0013757
2015-11-14 21:43	FTW395	Note Added: 0013790
2015-11-14 21:43	FTW395	Status	feedback => new
2015-11-14 21:45	FTW395	Note Edited: 0013790	View Revisions
2015-11-15 09:45	Torr Samaho	Note Added: 0013794
2015-11-15 09:45	Torr Samaho	Status	new => feedback
2015-11-22 20:05	FTW395	Note Added: 0013874
2015-11-22 20:05	FTW395	Status	feedback => new
2015-11-28 10:56	capodecima	Note Added: 0013893
2015-11-29 11:37	Torr Samaho	Note Added: 0013898
2015-11-29 11:37	Torr Samaho	Status	new => feedback
2015-11-29 23:53	Ch0wW	Note Added: 0013921
2015-11-30 01:22	Ch0wW	Note Edited: 0013921	View Revisions
2015-11-30 14:43	Konar6	Note Added: 0013922
2015-11-30 17:39	Ch0wW	Note Added: 0013923
2015-11-30 17:40	Ch0wW	Note Edited: 0013923	View Revisions
2015-11-30 20:07	Dusk	Note Added: 0013924
2015-12-01 12:47	capodecima	Note Added: 0013928
2015-12-01 20:49	Torr Samaho	Note Added: 0013929
2015-12-01 23:02	capodecima	Note Added: 0013930
2017-11-08 21:42	Dusk	Note Added: 0018827
2017-11-08 21:42	Dusk	Status	feedback => needs testing
2017-11-08 21:42	Dusk	Target Version	=> 3.1
2018-02-11 19:49	Leonard	Assigned To	=> Leonard
2018-02-11 19:49	Leonard	Status	needs testing => assigned
2018-03-25 15:17	Leonard	Status	assigned => needs review
2018-03-25 15:22	Leonard	Relationship added	related to 0003334
2018-04-30 15:48	Leonard	Note Added: 0019178
2018-04-30 15:48	Leonard	Status	needs review => needs testing