Macrodox and you: Linus, the ban and unban.

Macrodox and you: Linus, the ban and unban.

Last week, Linus was banned automatically by Macrodox for having a ‘perf rate’ of 90%+. The community was shocked and the global team scrambled to figure out what we should do.

After a few days, we determined that the likelihood that Linus was cheating was very low, and that a bug was the likely culprit. With the help of the community, the bug was discovered and documented (Thank you Sach, Haru, Carrier, Squared, Potts, GameChaos, Kohze, Zpamm). This post is the explanation of that bug, and how we believe Linus ended up getting 90%+ perf rate.

Macrodox: a primer

Macrodox is a plugin that has been around since 1.6 that is designed to catch obvious cheaters. It does this using two methods: analyzing jump counts (scroll patterns) and tracking a player’s bhop success rate.

Jump counts
The jump counts are established by counting the number of times a player issues a jump command and releases that jump command between when macrodox updates its calculations. If you tap space bar every time you land, your jump counts will be all 1s. A normal scroll number is around 5-12, although this can vary greatly between players. There are 30 total jump counts saved by macrodox, although only 26 are shown using !bhopcheck.

Bhop success rate
Bhop success rate, or perf rate, is calculated using a formula that gets executed every time macrodox updates its calculations. Here is the calculation that occurs:

When a player joins the server, their bhop success rate is set to 0.33, or 33%

When a macrodox calculation occurs, the bhop success rate is set to:
If bhop is a perf:
( current bhop success rate * 9.0 + 1 ) / 10.0

If bhop is not a perf:
( current bhop success rate * 9.0 ) / 10.0

For example, if a player has 20% perf rate:
If they get a perf, their new bhop success rate will be
( .2 * 9 + 1) / 10 = .28 = 28%

If a player misses the perf, their new rate will be:
( .2 * 9 ) / 10 = .18 =18%

Or, if a player has a 85% perf rate:
If they get a perf, their new bhop success rate will be
( .85 * 9 + 1) / 10 = .865 = 86.5%

If a player misses the perf, their new rate will be:
( .85 * 9 ) / 10 = .765 = 76.5%

You can see that this isn’t a true average and punishes players more as they approach 90%. (Missing a perf at 85% gives you 85% -> 76.5% whereas missing a perf at 20% gives you 20% -> 18%)

When it updates
Macrodox updates its calculations of jump counts and bhop success rates every time a player starts a jump and is on the ground. That means that the jump counts are not incremented until this calculation happens. This condition turns out to be the cause of the bug that may have caused linus’ ban.

Here’s a diagram to illustrate (credit to Zach47)

http://i.imgur.com/M9bGqK9.png

Macrodox: the bug

There are three flavors of the bug all caused by the same issue: macrodox only updates its calculations when a player starts a jump and is on the ground. So if a player never meets this condition but effectively fails a bhop, that failure is not counted. As a result, a player can miss many jumps in a row but their bhop success rate will not go down. The three conditions where this happens naturally are:
1: Bhopping into teleport triggers
2: Bhopping up a surf ramp
3: Grinding WJs.

Grinding WJs
Let’s take the third option - grinding WJs - as an example. Here’s the behavior of a played grinding WJ’s that would trigger the bug:

(Diagram credit to Zach47)

http://i.imgur.com/Lqm2yrf.png

1: Player runs off of a block (Note, because the player didn’t jump off of the block, no macrodox calculation occurs)

2: Player jumps in the air using the bind or spacebar, but too early, missing the perf. This jump increments the jump counter silently.
-Because the player isn’t on the ground, no macrodox calculation occurs

3: Player lands on the ground

4: Player teleports back to block and repeats the process N times (let’s say 4 times)

Then, the cycle ends when a player gets a perf:

1: Player runs off of a block
-Because the player didn’t jump off of the block, no macrodox calculation occurs

2: Player lands on the ground and jumps in the same tick
-Because the player is on the ground and the player started jumping, the macrodox calculation is triggered!
-The jump count is set to the total number of jumps that have occurred since the last calculation, in this case N or 4.
-The bhop success rate goes up using the formula.

As long as a player follows these events, their perf rate would only go up, and their jump counts would show the number of attempts the player made to try to get a perf.

Here’s a video of Sachburger using this method to have his bhop success rate only increase:


Now let’s look at linus’ macrodox ban record:
Scroll pattern: 1 3 6 3 6 7 1 1 2 2 1 1 7 1 1 3 1 4 7 6 1 4 3 13 1 1 1 3 1 2, Avg. scroll pattern: 8.257684, Avg. speed: 288.185729, Perfect jump ratio: 90.57%

If we assume that the described method was used, then we can see that the numbers above 1 are actually the number of attempts it took for linus to hit a perf using only the space bar, or the number of attempts before he hit space bar after he landed, thus triggering a macrodox calculation and decreasing his bhop success rate. Not all of the jumps in this scroll pattern have to have used the bug, but in order to reach 90%+ there would have to be around 15 perfs in a row.

This WJ method only works with the bind or with jump bound to space bar, because if a player scrolls when they hit the ground, they’re very likely to jump after they’ve landed, this triggering the macrodox calculation.

So, that’s it?

Well, not really. In order for this bug to continue to raise a player’s bhop success rate, that player must only jump before hitting the ground, not after. If the player hits the jump after they have landed, the macrodox calculation is triggered and the player’s perf rate decreases. This is difficult to do, but we don’t have a lot of data to show how difficult this really is. Many of the players who think Linus did cheat point to the fact that jumping only before you land is very difficult, and doing it consistently may be roughly as hard as timing the jump on the perf itself. However, we have had several players try this bug and come very close to 90%.

We have created a non-global test server for you to try this WJ technique and try to get autobanned for 90%+ bhop success rate. Please join the server by typing “connect kztimerglobal.com” into the console and giving it a try.

We look forward to your feedback and are happy to answer any question you might have on macrodox.

Thank you,
Chuckles

P.S. While I’ve called this a bug, it is only a bug in so far as it leads to these three edge cases. The code is working as written.

 

So that b-hop check would still requires timing 15 jumps in a row to not be even 1 tick late? That's insane. It's almost wrong to even call that a bug. Sounds like you haven't seen anyone able to hit that many even when trying to do it intentionally.

Like, so you have to fall off a weird jump block consistently (not exactly the most controlled thing versus, say, jumping) then getting that 1 tick timing, even if you are allowed to be early, 15 times in a row. Put this in your list of KZ achievements, @linus. Keep it up.

 

https://www.dropbox.com/s/vg17hqdakw2u150/wjs.dem?dl=0
Here is the demo of it....

 

We don't have a lot of data so we can't say how difficult this is with any certainty. That's why we're suggesting that every try it! It looks like linus is able to do this pretty consistently.

 

So far, there has never been a player who we have unbanned for a false positive ban without first finding the specific bug or edge case that led to the perf rate going above 90%.