DKR - Brake Exploit

// Prior material on DKR Velocity: https://pastebin.com/fig64sXz

// In my initial reversing of DKR's velocity functions for the kart, I never
// looked into how brake was calculated when compared to throttle. I believe the
// intended behavior was to have brakes be a floating point from 0.0 to 1.0 much
// like throttle, however the way they calculated it was causing the brakes to
// be more powerful rising up to 1.2 and as far down as -0.05.

// Here is some rough code showing what is actually going on.

if (HOLDING_B && player->brake < 1.0f) {
    player->brake += 0.2f;
}

if (!HOLDING_B && player->brake >= 0.05f) {
    player->brake -= 0.1f;
}

// Here are some examples of situations that brake the intended algorithm

// player->brake is 0.99 when holding B
// 0.99 + 0.2 = 1.19

// player->brake is 0.05 when not holding B
// 0.05 - 0.1 = -0.05

// Numbers like these can happen because of the use of floating point values,
// repeated braking will cause the value to slowly stray away from the 0.1
// increments into these unintended ranges.

// In my previous pastebin, listed at the top of this document, I included a
// line which showed the acceleration that was being calculated from the brakes
// Here it is again: -0.32 * 1.7 * stats * brakes
// Notice the negative sign in this case, that means the velocity will decrease
// However, we can get a negative value for the brakes... the lowest of which
// is -0.05. This gives us a positive acceleration and thus a speed increase.

// Now to get the top speed similar to the examples I gave last time I will
// assume 0 bananas, not boosting, not drifting, normal road, and using Diddy.
// (1.7 * stats * throttle + -0.32 * 1.7 * stats * brakes) / traction
// (1.7 * 0.34 * 1.0 + -0.32 * 1.7 * 0.34 * -0.05) / 0.004
// (0.578 + 0.009248) / 0.004
// 0.587248 / 0.004
// 146.812 ... and finally the square root of this is 12.117
// Pulling from the last paste, the value was 12.021 without this exploit.
// That is an increase of roughly 0.8% top speed. Or in terms of acceleration
// it is a (0.32 * 0.05) = 0.016, 1.6% acceleration increase. Which you can see
// correlates to that 0.8% top speed if you took the squareroot of 1.016. This
// means the speed you gain from the exploit is the same regardless of bananas,
// character, road, etc.

// Here is a sample program to kind of show how many cycles of braking would
// need to occur for you to reach the theoretical 0.8% top speed gain.

int cnt = 0;
float brakes = 0.0f;
float previous = brakes;

while (1) {
    while (brakes < 1.0f) {
        brakes += 0.2f;
    }

    while (brakes >= 0.05f) {
        brakes -= 0.1f;
    }

    cnt += 1;

    if (previous < brakes) {
        break;
    }

    previous = brakes;
}

// After running this, the value of previous becomes -0.05f which, as expected,
// is the theoretical best. And cnt is 419431, which is how many cycles of
// holding the b button and letting go was required to reach that value.

// Main takeaway is.. this isn't useful at all unless perhaps for flaps if you
// were crazy enough to waste that much time. Also for those wondering why the
// character moves when you don't press buttons on a flat surface, this exploit
// is the culprit.