///////////////////////////////////////////////////////// // // Real Fake bHop // by thaCURSEDpie // // 2010-09-15 // // Documentation // // // Contact: // thacursedpie AT gmail DOT com // ///////////////////////////////////////////////////////// ****TABLE OF CONTENTS 1. Preface 2. How does this mod work? 3. Description of cvars <-- Read this if you want to configure the mod ****PREFACE Because I do not have a lot of experience with bunnyhopping, it is very hard for me to replicate it. That is the reason why I wrote this document; to give you a bit of knowledge about how the mod works, so you will be able to adjust the settings to your liking. ****HOW DOES THE MOD WORK? You could have a look at the sourcefile, but that might be scary! So here's an explaination: First of all, to know how the mod works, one must know how bunnyhopping works. To my understanding, it works as follows: By turning in the air ("airstrafing"), a player can gain momentum. Normally, he would lose this 'extra' speed when he touched the ground (because of friction). BUT, if a player were to JUMP quickly after landing, the effect of friction would be negligable. In his next jump, he could once again gain momentum, et cetera. Valve has (tried*) to block bunnyhop in TF2. They did this by upping the friction way up. Now, if you touch the ground in TF2, your speed is reset in just a few frames. Thus, this is the point I focused on when making this mod: While the player is in the air, I store his velocity every frame. When the player lands, a counter starts. If the player does not jump within a certain amount of frames ("rfbhop_tolerance"), nothing happens when he jumps again. But when the player DOES jump within the timelimit, the following happens: The mod gets the saved speed. The direction of the saved speed is adjusted to match (or 'partially match' -> "rfbhop_angleratio") the current player's direction. A multiplier is applied to the old speed ("rfbhop_multiplier"). The players current velocity is changed to the 'old' velocity. Another way to make bunnyhopping possible again would be to change the ground-friction. I have decided against this method, because it would probably be more CPU intensive than my current method. *: "tried", because I've seen someone bunnyhop in a vanilla server. Could've been hacks, of course. ****DESCRIPTION OF CVARS rfbhop_enabled: 1: mod is enabled 0: mod is disabled rfbhop_multiplier: multiplier to use for the bhop boost. A value of 1 would imply no artificial boost; the player would have to use 'skill' to increase his momentum. A value > 1 would imply a boost. Even low boost values increase the player's speed significantly try 1.07 for example. a good value to use if you want to make bhopping a tad easier, but not rediculously fast: 1.001. A value < 1, > 0 would imply a loss in speed. (< 0 doesnt make sense) rfbhop_tolerance: the max amount of frames the player is allowed on the ground, before the bhop streak stops Note: high values will make bhopping 'laggy', or result in strange behaviour. Imagine this: Player1 jumps, increases his momentum in his jump, lands. If he were to jump again 5 frames later, he wouldn't be able to have changed his speed(direction) much. Thus, the 'old' speed does not differ much from his current speed. Neither does the direction of the 'old' velocity vector, compared to his current velocity vector. Now compare the first situation, to the following: Player2 jumps, increases his momentum in his jump, lands. He proceeds to walk around the map for about 1/2 a minute, before jumping again. It is clear, that his speed and speeddirection have changed quite a bit! Of course, this is a very unreal situation, but it helps to picture what it would be if the tolerance is set high(er) In short: Low tolerance (< 7): very hard bhopping, very smooth (not laggy) High tolerance (> 9): easy bhopping, very glitchy (laggy) rfbhop_angleratio: this changes the ratio between the current player's speed direction, and the 'old' player's speed direction. Used because of differences between the 'old' playerspeeddirection and the new playerspeeddirection -1: this code is not executed (saves CPU) calculation: angle_to_use = (old_angle + new_angle * angleratio) / (1 + angleratio) Thus, the higher the angleratio, the higher the account of the new angle, compared to the old one. This translates to gameplay in the following way: The higher the angleratio, the more 'curvy' bhopping becomes. This makes bhopping harder. The lower the angleratio, the more 'straight' bhopping becomes. This makes bhopping easier. Note: This setting is strongly linked to rfbhop_tolerance. At low tolerance levels, this setting can be set very low, or disabled altogether. At high tolerance levels, this setting must be used, else the bunnyhopping will feel very laggy.