Time stamps mate. Tried watching both and I can't see anything.
deez2 - crashes my game at 1:17 and I'm not the only one with this problem. Prior to the game crash I can't see anything suspicious.
deeznuts - 7 minutes long demo that doesn't show anything. He jumps like what, three or four times total through the demo? Can't see anything in terms of aim assist either, normal few shots.
I've read your messages on discord and the way you approach this situation is beyond me. I won't even attempt to understand it.
However, if you really believe that he's cheating, then you need to show us a valid proof. You claim to have more demos, you can upload them here but this time give us timestamps and explain what's wrong according to you.
Since I'm the backend guy, I am not so pro in explaining things but I'll try my best. Also since my English is not so good, I'll explain everything using Translator and Copilot.
Sorry about the trouble, I’ve just realized that all the demos I recorded under my Linux setup either freeze the game or crash it completely, so I won't be able to provide working versions after all. I didn’t notice this on my end since they play fine here, but I get that it’s not helpful if they don’t work for anyone else. That said, you can still observe him live in-game at any time, the macro usage becomes obvious pretty quickly, especially through his movement patterns and timing. I understand if the current evidence isn’t usable, but I still strongly believe he’s using some form of script or macro, so I’d appreciate if someone could keep an eye on him during regular play. Again, sorry for the inconvenience.
Im gonna point out things i myself saw on the demo:
In the first one, you can repeatedly see jump inputs spammed, lets just say 10. What is suspicious in that, is that its literally just 1 jump he wants to do, wanting to jump over a soda, not even trying for a bhop after as it seems through the jump inputs, and yet he still spams like 10 even though the very first is enough.
At tick ~16k he takes on around 3 bhops, all of them spams in the same way, throughout his entire bhopping, not a pause that would show another scrollwhel stroke, suggesting he is scrolling the wheel for 3 secs straight, with 10 jump inputs per hop
Same can be seen on the 2nd demo, sadly corrupted at 1:16 or sum, but at like 30 secs when he jumps down the bridge, you can see him spam the jumps again fir 2 seconds, while literally mid air for no reason, and then does 2 hops again while scrolling or 4 secs straight again.
It doesnt make sense, is irregular af, plus he got mr wideproductioned
Min 4:20
Thank you Woozu for helping me out <3.
for the sake of sanity let's just move on please. we got the timestamps, we got the drama, let the next messages be strictly related to the ban request and no further third party interactions.
This part is for you Niko:
The way the plugin (
TogsJumpStats) detects jump-related cheats is based on how many times a player presses the jump key before landing. Specifically, in the
OnPlayerRunCmd function, the plugin increments
ga_iJumps[client]++ every time a player presses +jump while airborne. This means if a player spams their jump key (e.g., by using mouse wheel or a macro) and presses it 5 times before landing,
ga_iJumps[client] will store the value 5 for that jump cycle even though only the first jump input actually resulted in a jump. This is critical to understand because legitimate players usually press jump only once per landing, while players using scroll to bunnyhop may generate 2–8 jump inputs per landing due to how mouse wheel binds work. These extra inputs are typically harmless spam, with only one triggering the actual jump. However, users with hyperscroll or macros often send
far more jump inputs sometimes 20 or more before even touching the ground, which goes far beyond what is humanly possible and strongly suggests automation.
This count (
ga_iJumps[client]) is then used for multiple checks in the plugin. For example, in
Event_PlayerJump, if the average jump inputs (
ga_fAvgJumps[client]) goes above 14 or 15 over time, and a significant number of the last 30 jumps exceed a configured threshold (
tjs_hyp_numjumps), the player may be flagged for hyperscrolling. There’s also pattern detection logic that compares the current jump count to previous values (
gaa_iLastJumps[client]) to look for consistency, if a player repeatedly sends the same number of jump inputs (e.g., exactly 18 each time), the plugin considers it a potential macro.
However, this system has limitations. A macro that is well-written and simulates more natural variability in jump timing. For example, by sending only one or two jump inputs per jump which can easily bypass detection. The plugin doesn’t analyze how “early” or “precise” the jump input is in relation to landing, only how often the jump button is pressed before the player touches the ground. Additionally, because SourceMod doesn’t give access to the actual hardware input or exact input timing (only server-side movement data), the plugin relies on patterns, averages, and thresholds which are easy to evade with subtle macros or scroll rate tuning.
In short, while the plugin does a solid job flagging obvious cheaters (like
hyperscrollers or those using poorly written
macros), it’s not foolproof. Scripted players who manage their inputs carefully can go undetected, especially if their jump inputs fall below the flagging thresholds. This is why live observation, behavioral analysis, and context (like watching a demo or clip) are still essential parts of catching more subtle movement cheats.
Examples:
Code:
Flagged: 0 || Perf: 0.6% || Avg: 1.3 / 214.0 || PLAYER_NAME_HERE<CLIENT_INDEX_HERE><STEAM_ID_HERE><> || Map: MAP_NAME_HERE || Last: 3 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 1
Flagged: 0 || Perf: 11.6% || Avg: 1.2 / 231.7 || PLAYER_NAME_HERE<CLIENT_INDEX_HERE><STEAM_ID_HERE><> || Map: MAP_NAME_HERE || Last: 1 0 1 1 1 1 1 1 1 1 2 1 1 1 1 1 1 1 1 1 1 1 2 2 1 1 1 1 1 1
- The first part will be either 0 (if unflagged), or 1 (if flagged).
- The next number ranges from 0 to 100%. It is the ratio of jumps that are perfect (jump command sent to server exactly when the player touches the ground). A stat of 65% would mean 65% of the time they have "perfect jumps" (which is pretty good). Most players using their spacebar (the above examples) wont have perfect ratios much higher than 20%...but dont assume hacks if they somehow have a good day and are at 50% or something that is normal for mouse wheel jumpers.
- The next two numbers are the 'average number of jump commands sent to the server between jumps', and the 'average speed'. Low numbers (0-3) for 'average jump commands sent' typically indicate that the player is using a keyboard. Mid-ranged numbers (3-13 ish) typically indicate the player is using a mouse wheel. High numbers typically indicate hyperscroll, or can be auto-hotkeys (if repeating numbers).
- Next section is all the player info, followed by the map name.
- The final section is the 'number of jump commands sent to the server between jumps' for the last 30 jumps. This provides a more in-depth look into what is going on. Do not be surprised by random, outlying numbers that are large, as that is typically from jumping off some high place in a map, giving the player time to send a lot more jump commands while in air. Pay attention to the patterns and trends, and what they indicate.
Code:
Flagged: 0 || Perf: 22.4% || Avg: 3.6 / 329.6 || PLAYER_NAME_HERE<CLIENT_INDEX_HERE><STEAM_ID_HERE><> || Map: MAP_NAME_HERE || Last: 5 4 4 6 4 4 2 5 4 4 6 4 4 6 3 4 3 2 2 2 2 5 4 5 5 3 5 3 6 4
Flagged: 0 || Perf: 49.8% || Avg: 8.0 / 332.2 || PLAYER_NAME_HERE<CLIENT_INDEX_HERE><STEAM_ID_HERE><> || Map: MAP_NAME_HERE || Last: 10 4 11 8 7 8 6 10 6 6 6 8 6 7 7 9 5 5 11 6 10 6 12 12 9 5 8 9 6 8
This is Legimate player's stats.
Code:
Flagged: 0 || Perf: 4.0% || Avg: 21.6 / 325.3 || PLAYER_NAME_HERE<CLIENT_INDEX_HERE><STEAM_ID_HERE><> || Map: MAP_NAME_HERE || Last: 23 21 21 33 18 20 22 21 10 3 19 24 21 22 21 20 20 20 21 22 21 22 22 21 22 20 20 23 22 21
And this is a macro user's stats.
Code:
Flagged: 0 || Perf: 5.8 || Avg: 10.8 / 196.1 || DeezNuts<836><[U:1:1105362879]><> || Map: zm_desertprodigy_b5 || Last:
19 15 22 19 21 14 10 4 46 39 3 4 4 4 4 4 5 >5< 22 20 3 21 12 4 4 22 20 18 22 20
22.6 20.3 28.3 25.4 22.9 20.6 18.5 16.7 15.0 13.5 12.1 10.9 9.8 8.8 8.0 7.2 6.4 > 5.8< 31.0 27.9 25.1 32.6 29.3 26.4 23.7 21.3 19.2 17.3 15.5 14.0
Code:
Flagged: 0 || Perf: 30.0 || Avg: 21.8 / 252.7 || DeezNuts<836><[U:1:1105362879]><> || Map: zm_desertprodigy_b5 || Last:
49 42 22 19 20 20 20 >21< 46 39 3 4 4 4 4 4 5 5 5 23 8 37 6 27 28 28 22 17 22 20
5.3 14.8 23.3 21.0 28.9 26.0 33.4 >30.0< 15.0 13.5 12.1 10.9 9.8 8.8 8.0 7.2 6.4 5.8 5.2 4.7 4.2 13.8 12.4 11.2 10.0 9.0 8.1 7.3 6.6 5.9
The reason
DeezNuts was not flagged by the
TogsJumpStats plugin is due to how the detection system fundamentally works. The plugin monitors a player's
"performance" based on whether their jump command is issued
at the exact moment they land on the ground (i.e., "perfect jumps"). It also records the
average number of jump commands sent per jump cycle and logs the
last 30 jumps to check for repeating patterns or excessive scroll-like spam. However, the plugin only increases the jump count when a player presses +jump while already in the air but it does
not discriminate between manual scroll input,
hyperscroll, or
macros that spam jump continuously while airborne.
In
DeezNuts’ case, the jump stats show very
high jump counts per cycle (20+ jump commands), which is typical of macro or hyperscroll users, but
his "perfect jump" performance ratio is low (5-30%), and
his patterns are not consistent enough to trigger the pattern detection thresholds (
tjs_pat_count) or hyperscroll logic which requires repeated detection across multiple rounds (
tjs_hyp_mult_rounds). This means while his movement is suspicious, especially with extreme averages (e.g., Avg: 21.8 / Speed: 252.7), he avoids flagging due to having a low perf ratio and no consistent pattern hits. In short, he's flooding jump inputs, but not landing them with perfect timing or predictable patterns, which is exactly how the plugin avoids false positives but also how some macro users can slip through undetected.
Therefore, the plugin is working as designed, it's cautious to avoid false flags, but that also means some players like
DeezNuts, who use more "humanized" or randomized macros, can stay under the radar unless directly observed or demo-reviewed.
To Be Noted:
How Jump Input Works in the Game Engine
To better understand how macros or scroll abuse can affect jumping behavior and why certain input patterns appear suspicious, it helps to first explain
how jumping works mechanically in the Source engine.
In Source games (like CS:S, CS:GO, etc.), jumping is handled through two core commands:
- +jump – this triggers the jump action (initiating a jump)
- -jump – this releases the jump action
When you manually execute +jump in the console, your character will jump
once, but then you won't be able to jump again until you manually enter -jump. This is because
the game requires -jump to be received before it will accept another +jump. In other words, holding +jump indefinitely will not let you continuously jump.
However, when you
bind +jump to a key or mouse button (e.g.,
bind space +jump), the game handles this differently. Every time you press the bound button:
- It triggers +jump, initiating a jump.
- It automatically sends -jump after the key is released silently and instantly.
This automatic -jump handling allows the player to simply
tap the jump key once per jump, and the game handles the required +jump/-jump cycle internally.
This same principle applies when players use the
mouse wheel to scroll jump (e.g., bind mwheelup +jump). Each scroll notch sends a +jump, followed by a quick -jump. The faster the scroll, the more jump commands are sent in a short period.
This is crucial for understanding how macros and hyperscrolls operate. A macro or hyperscroll setup doesn't just send clean, spaced-out jump inputs. Instead, it spams a burst of +jump/-jump pairs rapidly while the player is still in the air.
Since the game doesn't allow a jump to be executed while the player is airborne, most of these inputs are ignored by the game engine but they are still logged by the TogsJumpStats plugin. That’s why you might see stats like:
Code:
Last: 23 21 21 33 18 20 22 21 10 3
Conclusion:
The video (
YouTube) showcases my strafing technique used to gain speed, comparing it to other players’ movements and jump durations. It breaks down how I time my jumps and strafes to maximize acceleration and efficiency in bunny hopping. However, the key point relevant here is the duration mentioned in the video hitting over 20 jump inputs within just 0.8 seconds. Achieving that many jumps in such a short time frame is virtually impossible for a human player, strongly suggesting the use of a macro. While the video itself doesn’t show
DeezNuts or his gameplay, the timing it presents highlights how abnormal rapid jump inputs are. This supports the plugin’s statistical data and helps explain why, despite the plugin not flagging
DeezNuts, the speed and frequency of his jumps strongly indicate automated input.
Made this new plugin to get jump duration:
GitHub
It’s important to understand that
TogsJumpStats is not foolproof. While it's very good at catching players who use extremely obvious hyperscroll or repetitive macros,
it will sometimes produce false positives (e.g., flagging legitimate players who are just having a good day with mousewheel timing), or
fail to flag players who are
clever with their macros or who maintain
low perf ratios and irregular patterns.
This means:
- Legitimate players can sometimes be flagged if they show consistently high perfect jump ratios and predictable inputs (especially with scrollwheel use).
- Cheaters using advanced macros can avoid detection by introducing randomness, lowering perfect perf ratio, or breaking up patterns to confuse the plugin.
For Sour and Slowian:
Sour made this video with you in
here, pretty sure Sour still has that clip.
Video from Woozu:
Credits:
@Woozu
ThatOneGuy (
TogsJumpStats dev)
