Zandronum Chat on our Discord Server Get the latest version: 3.0
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002491Zandronum[All Projects] Bugpublic2015-10-14 15:522018-04-30 15:48
Assigned ToLeonard 
Statusneeds testingResolutionopen 
PlatformOSOS Version
Product Version 
Target Version3.1Fixed in Version 
Summary0002491: Screenshot exploit
Descriptionpressing the screenshot button repeatedly will make a person lag in multiplayer. Which can be abused to score flags in game modes like ctf, because of the lag the defense won't be able to kill the person.
Attached Files

- Relationships
related to 0003334needs testingLeonard Tickrate discrepancies between clients/servers 

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

Has the server turned on the tic buffer?
User avatar (0013739)
FTW395 (reporter)
2015-11-02 15:15

Yeah the server had tic buffer on.
User avatar (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?
User avatar (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.
User avatar (0013790)
FTW395 (reporter)
2015-11-14 21:43
edited on: 2015-11-14 21:45 [^] -> 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

User avatar (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.
User avatar (0013874)
FTW395 (reporter)
2015-11-22 20:05

Here's the demo from my perspective: [^]
And here's the demo from someone else's perspective: [^]

I'm the person who's repeatedly pressing the screenshot button as you can see by the teleporting I do.
capodecima (viewer)
2015-11-28 10:56

Was akways wondering why every1 jitter on this port, may be this case i guess?
User avatar (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?
User avatar (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: [^]

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

User avatar (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...
User avatar (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.

User avatar (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.
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...
User avatar (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.
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.
User avatar (0018827)
Dusk (developer)
2017-11-08 21:42

Since the tic buffer has undergone significant changes recently, this one needs to be re-evaluated.
User avatar (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 Community Support
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.

- 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

Questions or other issues? Contact Us.


Copyright © 2000 - 2021 MantisBT Team
Powered by Mantis Bugtracker