Ideal bhop explained

Recently I got asked some questions about bhopping so I decided to post this to forum, hopefully more people will find it useful.

Before starting, here are a few things you need to know:

1. When you perform a jump using mouse wheel it executes both +jump and -jump commands within one frame.
2. When client sends +jump command, engine sets IN_JUMP bit to cmd->buttons variable and when client sends -jump engine removes IN_JUMP bit.
3. FOG is abbreviation for 'frames on ground'.
4. Velocity.z is a player's vertical speed.

Unlike HL1 and KZmod where you can roll mouse wheel like a crazy without any consequences, in order to achieve decent bunnyhop in CS 1.6 you need to do it with a certain speed. When you scroll jump being on the ground, engine checks if you already had IN_JUMP button in previous frame and if so, it won't allow you to jump as long as your previous frame has IN_JUMP button. That's the reason why we can't autobhop just by holding spacebar.

Here's an example to understand it better:

Groundflag        Command(s)
                    ...
        0                  +jump;-jump - jump could be done if player were on the ground
        0
        0                  +jump;-jump - jump could be done if player were on the ground
        1                  +jump;-jump - player just hit the ground but at this point engine does not allow him to jump because he had IN_JUMP in previous frame
        1
        1                  +jump;-jump - everything is ok, executing jump code...
        0
        0                  +jump;-jump - jump could be done if player were on the ground
                    ...

Only because player scrolled too fast, it led him to bhop with 3 FOG which in most cases will ruin your run.

Meanwhile, ideal scroll distribution looks like that:

Groundflag        Command(s)
                    ...
        0                  +jump;-jump - jump could be done if player were on the ground
        0
        0                  +jump;-jump - jump could be done if player were on the ground
        0
        1                  +jump;-jump - everything is ok, executing jump code...
        0
        0                  +jump;-jump - jump could be done if player were on the ground
        0
        0                  +jump;-jump - jump could be done if player were on the ground
                ...

But even with scroll distribution like that we are not safe from failing bhop because of:

a) PM_PreventMegaBunnyJumping() engine function ( https://github.com/SDLash3D/cs16-client/blob/06684811463fc0079f4b65720158665e79646fb7/pm_shared/pm_shared.c#L2038 ). After passing all of PM_Jump() checks there remains only PM_PreventMegaBunnyJumping(). This function decides whether to reduce your XYZ velocity or not.

First it calculates maximum speed cap for equipped weapon:

maxscaledspeed = BUNNYJUMP_MAX_SPEED_FACTOR * pmove->maxspeed;

If you have knife or USP in hands, it can be translated to:

maxscaledspeed = 1.2 * 250;

Then it checks if our XYZ speed (variable spd) is more than maxscaledspeed and if so, it multiplies our velocity vector by maxscaledspeed / spd * 0.8.

Some examples:

1. We have USP in hands, velocity.x = 286.132, veloicty.y = -11.622, veloicty.z = 0.0.

maxscaledspeed = 1.2 * 250 = 300.0
spd = squareroot(velocity.x^2 + velocity.y^2 + velocity.z^2) = 286.367

Since spd < maxscaledspeed, speed remains the same.

2. We have scout in hands, velocity.x = -54.337, veloicty.y = 311.328, veloicty.z = 0.0.

maxscaledspeed = 1.2 * 260 = 312.0
spd = squareroot(velocity.x^2 + velocity.y^2 + velocity.z^2) = 316.034

We have spd > maxscaledspeed therefore the whole velocity vector will be multiplied by maxscaledspeed / spd * 0.8:

velocity.x = -54.337 * 0.789 = -42.914
velocity.y = 311.328 * 0.789 = 245.883
velocity.z = 0.0 * 0.789 = 0.0

speed = squareroot(-42.914^2 + 245.883^2 + 0.0^2) = 249.599

So, our speed went from 316.034 to 249.599 after PM_PreventMegaBunnyJumping() function call.

Most of you have experienced situation when speed was cropped even though it was less than 300.0, there's an explanation for this. At the point of PM_PreventMegaBunnyJumping() call engine doesn't know yet that we are on the ground and there's no need to reduce our velocity.z as if we were in the air, so it reduces velocity.z on 4.0 (ent_gravity * pmove->movevars->gravity * 0.5 * pmove->frametime). It adds 4.0 back to velocity.z later though.

So although your XY speed was less than 300.0, your XYZ speed wasn't. This means that in examples above our velocity.z should have been -4.0 instead of 0.0 if we want to get accurate results.

b) PM_Friction() and PM_WalkMove() engine functions ( https://github.com/SDLash3D/cs16-client/blob/06684811463fc0079f4b65720158665e79646fb7/pm_shared/pm_shared.c#L1057 & https://github.com/SDLash3D/cs16-client/blob/06684811463fc0079f4b65720158665e79646fb7/pm_shared/pm_shared.c#L926 ). As you already could understand, we still can get 2 FOG bhops even with ideal scroll distribution. On such occasions, both PM_Friction() and PM_WalkMove() will strike.

fuser2 is a jump modificator that slows us down after performing a jump. After this, engine sets its value to 1315.789428 and each frame afterwards decreases it by current 'msec' value. If your FPS is 100 then your msec is 10, this means that to completely get rid of slowdown effect you need to wait 1.315 seconds.

Fame htf did you even understand all of that. Gj for the explanation and hard work.
#adminofthedecade

gj for this theory lesson mate

I really appreciate what you did here fame, about time that someone dedicate him self into something as complex as this and try explain it to the community, we may not understand it now but more importantly its a start to something will heavily help us in the future as it will be clear along the time.

THanks for explanation...is there any way to explain how 'stairs' work?

Wow, awesome reading!

Math is really damn beautiful!

In CS realities ideal scrolling rate is 1 scroll each 0.02 seconds. Even though it's possible to train yourself to scroll slower or faster, the easiest decision would be to find a suitable mouse for you.

By the way, you can try infamous "+jump;wait" script to see whether you need to scroll faster or slower. If you feel like your bhops became better with it — you need to scroll slower, otherwise — faster.

Here you go: https://drive.google.com/file/d/1nW-o4DxUooqvgjp9vf7M0aWjqoWgnCWc/view?usp=sharing

OMG!you're really good at mathematics.BTW I didn't understand a single word