Jumping techniques. Deeper explanation.

Recently I was searching of cs movement code on pastebin and I found this text you can see below. (IT IS NOT MINE!) I don't know the author of it, I wanted to post something simillar but this unknown author has saved my time :D
Although I'm going to update this thread with my explanations on other techniques.
This text explains how techniques such as EdgeBug, JumpBug and HighJump edgefriction(slow down) actually work.
Happy reading!



EdgeBug:

This is wrong:

There are 4 units for every edge that you can hit the edgebug from. Strafing into the edge is the key. The more (falling)speed you have collected when jumping "into" the edge, the more likely it will allow you to do an edgebug.

This is right:

Probability of you performing a successful edgebug mostly depends on your horizontal speed and FPS. At the end of each frame (inside of which player movement happens) engine checks your fall velocity and if it finds you to be on ground, than engine calculates how much damage you should take according to your fall speed. Strafing into the edge is the key - you must touch the edge and fly out of it within a single frame, so when ground check is executed you are in air. The more horizontal speed you have collected during your fall, the more likely you will succeed performing an edgebug.


Proof: http://pastebin.com/0W4RZv8X

void PM_CheckFalling( void )

is located at the very end of the movement code. It has nothing to do with so called "4 units of the edge" nor how your fall velocity effects probability of edgebug.

----

JumpBug:

Everything what goes after

"In an attempt to discover how the jumpbug functions, we must first break down the CS engine."

is wrong up to the point where spr1n's tip starts.


This is right:

In an attempt to discover how the jumpbug functions, we must first break down the CS engine. Just like in case of edgebug we are tricking the engine, so at both, start and the end of the frame we aren't touching the ground. There are two important reasons why jumpbug is even possible. First one is that unduck code goes before the jump code, meaning that if we execute both commands at the same time, unduck still will be executed first. Second and not any bit less important reason is the teleport-to-ground-check. Allow me to explain what this is. Have you ever tried to get up a ladder while being ducked and touching the ground? If so, you must have found that engine just keeps teleporting you back to the ground. Reason for that is slow velocity. For you see, during the frame (where movement is executed), engine may check several times is there a ground 2 units below your feet, and if so - just teleports you down. Good news is, that this check is also performed each time you unduck. Meaning that when you unduck and become stretched out, you will also be teleported on ground (if there is one 2 units below). So lets pretend that we were falling at incredible speed, unducked, and got ourselves teleported on the ground... Now if we jump, our velocity will become positive, sending you up, and removing our 'bond' with the ground.

Conclusion of this is simple. We weren't touching the ground when frame started, and we still aren't touching it when frame ended. Plus now we are send upwards, resetting the fall speed whatever it may be. However unlike in a bhop, our horizontal speed will be significantly smaller. This is cause engine doesn't allow us to reach speed beyond "weapon_max_speed*1.2" when jumping (x, y, and Z dimension included). If we exceed that value, our speed of all 3 dimensions will be scaled down to "((weapon_max_speed*1.2)/current_3d_speed)*0.8" fraction of current speed. However jump is just as high as with normal jump(including velocity modifier called fuser2), cause after that calculation, the jump-stamina kicks in and overwrites all previous results of vertical speed.

So in short terms, you just have to unduck and jump at the same time while being from 18 to 20 units above the ground. Not 0 to 2 as many people like to think, cause when you stretch out in air, you extend 18 both upwards and downwards.

Many of you may also think that jumpbug is quite hard to do. That is true, cause it requires perfect timing, and a certain aspect of 'luck'. Though it's more like technical probability for successful jumpbug. It can be calculated this way "(2*100)/(frame_time*fall_speed)" - this is how much % you have of making a successful jumpbug at given speed and FPS. Oh, and also you may want to know what your "frame_time" is, cause it's not FPS value as you may think. Actually it's "frame_time = 1/FPS".



Proof : http://pastebin.com/0W4RZv8X

void PM_UnDuck( void )

You can see that at the end there is:

PM_CatagorizePosition();

This function checks is there a ground 2 units below and teleports you there.

You may also find that

void PM_PreventMegaBunnyJumping( void )

what is located inside

void PM_Jump (void)

is scalling and checking all 3 dimensions XYZ.

You may also see that inside

void PM_PlayerMove ( qboolean server )

PM_Duck();

goes before

PM_Jump ();

And that inside

PM_Duck();

you can find

PM_UnDuck();

inside of what at the very end you'll notice that it is

PM_CatagorizePosition();

what is responsible for 2 unit down teleport.

---

Inside HighJump about edgefriction:

This is wrong (doesn't explain the actual why in the way what's actually happening):

"If you're running straight ahead towards the edge of a highjump you are going to lose 17% of your velocity!" and ending at "Distance from edge without getting slower = sin(Angle when starting to run) x 13.6 units"

How it actually works:


While moving in any direction remaining on the ground at the same time, engine performs a simple check. Check basically tells the engine, if you'd continue moving in current direction, would 16 units afterwards you should be standing on ground or no. In case if would be on ground - nothing changes - that's why running parallel to the edge has no effect. But if you would be in air, than it checks distance to the ground at that point. If distance is above or equal to 70 in case if you'r currently standing (or 52 if ducked), than edgefriction kicks in replacing the normal friction.

Why normal friction is even needed... Well, that's simple. If you aren't pressing no movement keys while moving on the ground (just released your movement keys after a run), then eventually you slow down to a hold. Well, this friction code is always present and always used (even if you'r holding any movement keys). However acceleration attempt overpowers the friction code. But not in case of edgefriction. Edgefriction does the same thing as normal friction, except it amplifies the effect by amount of times cvar is set. That's why when it's 2 (default value), you start to slowdown at the edge. When it's 1, than it's the same as normal friction. When it's 0... well in this case you'll just slide off the edge whether you want it or no (well, unless you'll press the opposed direction movement key in time).

So if you want to avoid effects of edgefriction where it's present, you should jump 16 before running of the the edge. However edgefriction is present before the code what actually changes your position. Meaning you can get an extra "speed*frame_time" units out of those 16. So if you'd have 100 fps (0.01 frame_time [1/FPS]) and are running with knife (250 speed) towards the edge, edgefriction would start slowing you somewhere from 13.5 to 16 units from the edge (depends from where your last frame ended).


Proof : http://pastebin.com/0W4RZv8X

You can see that

PM_Friction();

goes before the the part where player origin changes. Also inside the

void PM_Friction (void)

You can clearly see that all what it does is amplifies the effect of friction by "edgefriction" amount of times. Also there you can see that it scans 70 units below player's feet and 16 units towards direction where player's moving.

[edit#1] Thread updated. Added explanation on how CJ is done and some facts about Bunnyjumping.
[edit#2] Changed info about highjump edgefriction. The engine actually scans 70 units below player's feet and 16 units towards direction where player's moving. Added info about ladder movement(needs to be redone). Also reupdated links to movement code.

Originally posted by juleeeh

Interesting read!

I would happily read more technical information about other techniques or CS quirks if you would go into it.

I'm sure others are interested aswell.

Thumbs up :)

what techniques for example?

Originally posted by Juice ._.

Originally posted by juleeeh

Interesting read!

I would happily read more technical information about other techniques or CS quirks if you would go into it.

I'm sure others are interested aswell.

Thumbs up :)

what techniques for example?

how cj pre works =D

btw this is the best topic on xj for years!

Originally posted by juleeeh

How does standup-bhops work and why do we jump higher with it compared to regular bhops?

You don't actually jump higher, what happens when you duck is that the center of the player collision model remains where it was, but it's suppressed a few units up and down so you can jump on higher surfaces without colliding.

Originally posted by juleeeh

How does standup-bhops work and why do we jump higher with it compared to regular bhops?

I'll try to explain some facts about Bunnyhopping. A bit messy, but I hope that you guys will get a point:
1. Bunnyjump speed limit.
2. Standup bhop and slowdown factor.
3. Perfect bunnyhopping?! How do it o.O?

So, let's begin with

Bunnyjump speed limit

The engine doesn't allow us to reach speed beyond weapon_max_speed*1.2 when jumping (x, y, and Z dimension included). If we exceed that value, our speed of all 3 dimensions will be scaled down to ((weapon_max_speed*1.2)/current_3d_speed)*0.8 fraction of current speed.

This is why our prestrafe is forced to approx. (maxspeed*1.2)*0.8 in total.

For example if our maxspeed is 250,
then prestrafe limit is 250*1.2 = 300
so if we jump with speed more than that limit of 300, it shall be forced to: 300*0.8 = 240


Standup bhop and slowdown factor.
This guy

Originally posted by byob

You don't actually jump higher, what happens when you duck is that the center of the player collision model remains where it was, but it's suppressed a few units up and down so you can jump on higher surfaces without colliding.

Is WRONG.

If we look up the code, we will see a parameter that affects our vertical velocity, called fuser2.

fuser2 is set to 1315.78942.. on each successful jump we make and is reducing by FPS value on each frame.

Jump velocity is calculated this way:
velocity[Z] = square_root( 2 * 800 * 45.0 ), where 45.0 is jump height

and if fuser2 is more than zero, then you vertical velocity is multiplied by calculated factor:
factor = ( 100.0 - fuser2 * 0.001 * 19.0 ) * 0.01;
velocity[2] = velocity[2] * factor

When performing standup bhop, we extend our time in air. That means fuser2 is getting lower than bhopping without ducking, factor goes higher and affects our vertical velocity less, making our jump higher.


Perfect bunnyhopping?! How do it o.O?
No matter how fast you scroll, timing is the key to bunnyjumping. You always need to jump with pre lower than max value (pretty obvious, huh?) :P

If you haven't investigated the whole code yet, then you won't notice that fuser2 also affects horizontal velocity same way. See PM_Walkmove :D

If we jump on the 2nd frame after landing, then PM_Friction is applied, and then velocity multiplies by fuser2 factor(see the formula above) these two come from the 1st frame. I made a simple plugin to calculate the total slowdown factor, and the result is:
speed_on_land*0.827 (approx.)

So my point is - Try to control your onground speed and you will be bunnyhop pro! :)