Quantifying the KF2 recoil & rate of fire & reloads on FPS dependency

There’s a computer game available for rent in Steam and Epic game stores called “Killing Floor 2” (based on Unreal Engine 3), or KF2 for short. It’s a game in the “Killing Floor” franchise and it was developed by Alex Quick and John Gibson, with some help from “Tripwire Interactive LLC” or “Tripwire Interactive, Inc.” game development studio, which is no longer affiliated with these two founding fathers of the franchise. This post documents the findings of the research into the side effects that the “frames per second” metric, which typically measures the computer video subsystem performance, has on this game. The main finding of this research is FPS in KF2 does affect weapon recoil, rate of fire (RoF) and reload values. This has obvious implications for the fairness of the gameplay, as players who rely on these techniques put themselves at an advantage as compared to players who don’t. If you came here because you are concerned about the integrity of gameplay and just want to know the safe value and don’t have time to read the whole thing, this value is 120 FPS. Anything higher than that reduces the recoil. This research has been ongoing for about a year at this moment (6/28/2024 10:00 PM CDT). I intend to update this post periodically to reflect new developments.

A quick rundown of this long read:

• High FPS in KF2 reduces recoil, most likely all weapons/perks are affected. For example, at 700 FPS the real time M14 rifle recoil is more than twice less than at 62 FPS;
• The recoil is reduced down to 0 in zed time in 270-300 FPS range and stays zero with FPS higher than that as tested on an M14 rifle armed sharpshooter;
• Horizontal recoil in zed time falls down to zero (at around 270 FPS) sooner than the vertical recoil (at around 300 FPS);
• There are FPS values where recoil surprisingly actually increases, both in real time and zed time, sometimes above the “nominal” value of the 62 FPS, all these values are at <200 FPS range;
• Firing animations in zed time are sped up only after a certain FPS threshold, e.g. 400 FPS for M14 rifle armed sharpshooter;
• Reload animations in zed time are sped up only after a certain FPS threshold, e.g. 400 FPS for M14 rifle armed sharpshooter;
• Both firing and reload animations in zed time at ~800 FPS are sped up almost twice on M14 rifle armed sharpshooter, which means twice faster shooting and twice faster reloads;
• There could very well be other unintended dependencies of other game mechanics on FPS.

In general, as FPS go up, the recoil goes down, the RoF is faster, and the reloads take less time. The higher the FPS, the higher the advantage is. There are, however, some deviations from this general rule, as the functions aren’t linear, which is discussed at length below. Importantly, these things are calculated on the client side in online multiplayer games, which means that a player with high FPS can have huge advantages over other online players as it pertains to recoil, RoF and reloads in the same online multiplayer game. Main tables and graphs, which will be explained in detail later in this post:

 

Note, that if you don’t have time or don’t want to bother with following any of these numbers or videos, the simplest way for you to feel the difference is just review the vertical recoil climb on a wall, as well as feel how faster the weapon shoots between these 2 videos on the extreme ends of the spectrum, 62 FPS vs 700 FPS.

 

Or these two examples comparing side by side 2 total mag dump vertical climbs on the wall in pixels in zed time:

These side-by-side screenshots were taken from the videos supplied in the end of this article and show the comparison between the popular FPS choices of 144, 150 and 165 FPS on the left and the near standard 120 FPS where the recoil is almost the same to the standard 62 FPS. These values are chosen typically to match the monitor refresh rate or to rely on the “variable FPS” KF2 setting in the case of 150 FPS. These are relatively low FPS values that still provide very significant advantage. There isn’t much sense in providing side-by-side comparisons with higher values as there the recoil just drops to 0 in ZT and significantly decreases in RT.

Background on RoF

These paragraphs are mostly dry theory, skip it if you aren’t interested in how things may work under the hood and what could be the root cause of these observed phenomena.

From what information is publicly available, most of the UE3 code for these things was written by a former Tripwire Interactive Inc.’s president and CEO John Gibson. This shouldn’t be surprising, as John Gibson, despite being a CEO and a president, was still a very hands-on programmer and authored multiple important classes responsible for handling very important parts of the game. Here’s the header of the KFWeapon class:

KF2 is a game that relies on the UE3 game engine. On the screencap above, which shows the beginning of the KFWeapon class, written in UnrealScript language, one can see a typical approach the game developers take. They extend the classes that already were developed by the game engine vendor, Epic Games in this case, that address all the basics of the weapon handling, such as firing states, equipping, reloads and so on. They extend the classes to add new game-specific functionality that is absent in the base UE3 engine, but the core functionality of the most basic weapon behavior remains inherited from the base UE3. Individual weapons classes that determine particular weapon behaviors, such as M14 EBR rifle, extend the KFWeapon class and add functionality specific to them, such as a laser sight attachment, recoil values, damage values and other peculiarities.

For us this inheritance structure is important for answering the question, do the FPS side effects pertain to all weapons in KF2 or just some, as if the troublesome code pertains just to some weapons, it necessarily means it’s a result of John Gibson mistakes while developing appropriate classes. Further, if the FPS side effects pertain to all weapons in KF2, but not other UE3 games that rely on the Epic Games “weapon” class in a similar way, it means that the troublesome code is a result of John Gibson mistakes he made in the parent KFWeapon class. And, finally, if all similar UE3 games exhibit similar issues, it means that the troublesome code is located either in the Epic’s UnrealScript code in the “weapon” class or other classes it relies on, or in the native C++ code, or in the peculiarities of the UnrealScript virtual machine.

This research, naturally, just scratches the surface of this problem, especially if it’s as deep as the last option of the three. I believe the community’s end goal should be to find the root cause of these unintended side effects and patch the game such that they no longer break the level field and return the game to its fair state where no relatively easily manipulated things, such as FPS, can confer any advantage on any players. In the interim, I believe, the community is better off coming up with a standard FPS everyone in a consequential match should stick to in order to make the record and stats valid.

The rate of fire of almost all weapons is handled mostly by the Epic code. It makes sense to establish if the weapon is ready to fire by tracking down the “RefireCheckTimer” timer, which is displayed live in the game in response to issuing the “showdebug weapon” command in the in-game console:

• “RefireCheckTimer” is the name of a UE3 timer that, while it counts, prevents the weapon from being ready to shoot the next round;
• 0.0800 is a number of seconds passed since the previous round was shot;
• 0.1650 is a number of seconds of the default “FireInterval”, which is individual for all weapons in the game, which determines the minimum time that has to pass before the next round can be shot;
• 48% is the share of the time elapsed since the RefireCheckTimer began counting the last time before it meets the weapon’s FireInterval. In this case 48% is what 0.08 constitutes of 0.165. When it reaches 0.165 seconds or 100% the next round can be shot, if the “fire” in-game button is pressed.

In all our tests we weren’t able to identify a single case where the weapon was available for fire when this timer hadn’t expired yet. As far as our tests went, this timer works as intended and always expires before the weapon becomes available for firing.

However, the way this timer measures times is definitely incorrect. It doesn’t measure the real world time (or dilated time in the case of zed time being active which slows down the world 5 times) correctly and expires sooner than intended in at least 2 identified conditions:

• The very first FireInterval in zed time. For reasons unknown, this timer ticks non-uniformly and, for the first 2-3 frames (filmed with 60 FPS precision) after the first round was shot, it ticks much faster than warranted, resulting in the very first FireInterval in ZT being 23-32% shorter than the rest, no matter if the rest were under effect of high FPS or not;
• If the FPS was >400 in all cases in zed time the RefireCheckTimer expires sooner than the declared 0.165 seconds (slowed down 5 times because of the zed time dilation to make 0.825 seconds), the more FPS the sooner it expires.

The following Gibson’s function in the KFWeapon class is rather simple and basically calls the Epic’s parent function of the same name with adjustments for some KF2 perk peculiarities, as some perks allow to resist zed time dilation:

	/**
	 * Timer event, call is set up in Weapon::TimeWeaponFiring().
	 * The weapon is given a chance to evaluate if another shot should be fired.
	 * This event defines the weapon's rate of fire.
	 */
	simulated function RefireCheckTimer()
	{
		local KFPerk InstigatorPerk;

		InstigatorPerk = GetPerk();
		if( InstigatorPerk != none )
		{
			SetZedTimeResist( InstigatorPerk.GetZedTimeModifier(self) );
		}

		super.RefireCheckTimer();
	}

Which hints that the problem with RoF on FPS dependence may be as complex as the problem of the UE3 engine.

Background on recoil

Here’s a good explanation of how recoil works in almost any first person shooter game by the maestro John Gibson himself, a screencap of the comments from the KFWeapon class:

Let’s consider the M14 EBR rifle for simplicity. It has these recoil parameters:

    maxRecoilPitch=225
    minRecoilPitch=200
    maxRecoilYaw=200
    minRecoilYaw=-200

This means that each time a shot is fired, the game calculates 2 random values for pitch and yaw. The pitch goes only up and never down, because both values for M14 are positive values and are pretty close to each other, so the random value is selected from an interval of 200…225. The yaw, or “horizontal” recoil can pull the muzzle of the weapon either left or right, that’s why the range spans towards the negative values: -200…200. After these two random rolls are performed and the values are established, let’s pretend that 210 was rolled for the pitch and 42 for the yaw, the game changes the player’s point of view relative to its current coordinates to new ones, adding appropriately 210 in-game units to shift the PoV up and 42 to shift the view to the right.

The “CustomWeapons” mod M14 EBR, by the way, is different from the vanilla KF2 M14 EBR from the recoil perspective in only one thing: its vertical recoil is derandomized and is always 225 in-game units. This does not have any effect on any other weapon behavior.

Because the vertical recoil pulls the muzzle only up and by a rather predictable value, it’s relatively easy to control for, and experienced gamers learn to adjust for it by moving their mouse slowly along the vertical axis. After a lot of time spent playing, this technique gets ingrained into their “muscle memory” so they do this very accurately without thinking about it.

Horizontal recoil, on the other hand, cannot be controlled because it’s unpredictable. A gamer never knows will it pull to the left or right, so they cannot pre-adjust for some expected value, like in the case of the vertical recoil. First they need to establish if the muzzle pulls to the right or to the left and then adjust. But human reaction speeds, even in simple scenarios, are in the range of hundreds of milliseconds and by the time a gamer realizes which direction the muzzle pulls the weapon is likely to fire a few more rounds which further exacerbates the situation and so on. Because one cannot control effectively the horizontal recoil, observing its patterns is promising from the standpoint of detecting cheaters, as if there’s none or close to none horizontal recoil after multiple shots, it is definitely cheating, because one cannot claim that they “control” or “adjust” for it.

Then, there’s this interesting thing called “RecoilRate”. According to Gibson’s comments, it works this way: “The weapon will recoil at for RecoilRate amount of seconds, and then when firing has ceased will blend back to zero”, or, another his comment:

Basically, this should be the time that determines the delay before the newly adjusted for recoil point of view is applied.

Recoil buildup

The “recoil buildup”, for the lack of a better already established term, is a phenomenon of the center of the screen dragging severely behind the accumulated recoil from multiple shots fired in a quick succession, such that the next round doesn’t shoot at the center of the screen anymore, instead, it shoots at a recoil buildup PoV, typically significantly higher than the center of the screen and sideways, especially on weapons with significant horizontal recoil, e.g. AF2011-A1. Technically, it’s a situation of a weapon rapid fire where FireInterval is lower than the recoil and the center of the screen convergence time determined by RecoilRate and RecoilBlendOutRatio parameters. This applies to all perks relying on various skills that either resist or completely negate the ZT world slowdown as it pertains to shooting weapons, as well as quite a few fast shooting weapons as well. It’s easier to demonstrate on a video than to describe it in words:

Here’s a side-by-side comparison of the total vertical recoil climb measured in pixels with a ruler (VLC media player, maximized window with a taskbar with 1080 resolution):

Note these:

• if a player shoots as fast as possible, the overall vertical recoil climb is almost twice higher;
• if a player shoots as fast as possible, each next shots is fired BEFORE the center of the screen could catch up with the new after-recoil PoV, so the next shot recoil values are applied to the after-recoil PoV instead;
• as long as the small pink box at the center, which, as far as I can tell designates the limits of the bullet spread, is divergent from the small yellow box, the recoil buildup persists;
• the recoil climb maxes out at the big pink box margin, which, as far as I can tell, is the margin of the maxRecoilPitch and maxRecoilYaw variables.

Shooting as fast as possible results in the total 125 pixels vertical recoil climb, while pacing shots such that the recoil can blend out and converge with the center of the screen results in the total 67 pixels vertical recoil climb. The arrow just points to a bullet dent on a wall demonstrating the fact that bullets were going significantly higher than the center of the screen, which is marked by a small pink box.

Overall, it’s a great risk/reward game design mechanic which allows a player to deliver higher DPS, but at a cost of making it very hard to aim and control the recoil. The recoil buildup applies to virtually all gunslinger weapons and is exacerbated by ZT, so for gunslinger one has to measure at least 2 scenarios as it pertains to recoil:

1) the “divergent” recoil climb, which is firing as soon as the FireInterval of a weapon expires and the game technically allows to fire the next round, but the after-recoil PoV and the center of the screen haven’t converged yet, due to the RecoilRate and RecoilBlendOutRatio parameters resulting in a value that is higher than the FireInterval.

2) the “convergent” recoil climb, which is a situation when the next round is fired only after the after-recoil PoV and the center of the screen converge.

This also applies to some sharpshooter scenarios, such as shooting with FN FAL, especially with the “Marksman” build.

While investigating the peculiarities of how the recoil works in this game I’ve consulted the TWI’s wikipedia editor “simplecat”, as for some reason this important game mechanic isn’t described in the TWI’s wikepedia page or on simplecat’s spreadsheet at all. Here’s a link to our short conversation:

https://docs.google.com/spreadsheets/d/1GDpg2mN1l_86U_RaDug0glFx8cZCuErwxZLiBKl9SyY/edit?disco=AAABW5C-qGY

I do not personally think that it’s a bug though.

M14 “Marksman” sharpshooter methodology

It’s important that I share the methodology. The findings are quite surprising. Most of those, who confirmed that both recoil and FireInterval decrease with FPS expected the dependency to be more or less linear. It turned out not to be the case. The character of the recoil on FPS dependency function hasn’t been established yet with enough precision, but to what degree it was already determined, it doesn’t make much sense. But this is a consistent finding that I’m getting on my rig with my config. More replication attempts are needed to verify these results.

It’s likely that nobody knows what can be at play here. CPU may affect this. Background apps that share the same CPU may affect this. GPU may affect this. Some UE3/KF2 ini settings, of which there are hundreds, may affect this.

And just to state this explicitly. I do this in clear conscience, in the most detached and unbiased way possible. I’m not trying to prove a point or deceive anyone. At no point I was trying to conceal anything or adjust anything, so it looks better in any way. I just honestly report my findings. It’s the truth, only truth and the full truth I know.

That’s, actually, my way of life, I do it as it pertains to anything else on this web site and it works for me. But, because of the weird nature of the findings, as well as the existing hostility between the hardcore “Controlled Difficulty” KF2 mod groups I am sometimes perceived by many as a biased source who seeks to gain some leverage or reputation or whatever. Not the case here and almost never is the case. I report what I see. If I’m wrong and it can be proven — I readily admit it.

So, the basic method:

1. Measure the vertical climb of a full mag dump of the M14 EBR rifle on a sharpshooter with the “marksman” skill in pixels with 1920×1080 monitor resolution on a wall of a test map in a controlled vanilla KF2 environment of an online game to measure the vertical recoil (horizontal recoil isn’t measured) on a video;
2. Measure the time in frames of a video filmed with 60 FPS with the help of “GeForce Experience” (former “Shadow Play”) software between the shots. The frame numbers are plastered on a video with the help of this ffmpeg (free command-line video tool) line: c:\ffmpeg\bin\ffmpeg -i ss700.mp4 -vf drawtext=”fontfile=C\:/Windows/Fonts/Arial.ttf: fontsize=72: text=%{n}: x=(w-tw)/2: y=h-(2*lh): fontcolor=white: box=1: boxcolor=0x00000099″ ss700-frames.mp4 (assumes Windows, change to whatever on MacOS or Linux);
3. Set a different MaxSmoothedFrameRate option in a kfgame.ini file from a preselected list of progressively increasing values that made the most sense to measure and repeat.

Note, that provided that your rig is powerful enough, you don’t need to change the MinSmoothedFrameRate from its default value. If it’s not powerful enough, it’s futile to change it to the values your rig cannot support.

This is a refined methodology that ended up here after several iterations. At first I was measuring the time between the shots in milliseconds with the help of various plugins which turned out to be less accurate and dependent on everyone who wanted to verify my findings to download the videos from YouTube. For now you don’t have to download. If you don’t want to bother with filming your own replication attempts, at least you can play the already filmed videos on YT by playing them frame by frame from the paused state by pressing “,” and “.” buttons on a keyboard.

There are guides on the Internet that request that you change these values in multiple ini files. For me changing this option in kfgame.ini was enough.

Crucial things to note while measuring:

• No mouse movement in order not to spoil the recoil climb. We are measuring the free uncontrolled recoil climb;
• The distance to the wall on which we are measuring the pixels is absolutely the same down to a few pixels +/- in all tests;
• The FoV must be the same for all measurements, in my config the default one of 100 in-game units which is equal to 90 degrees horizontal FoV is used.

For each test measuring the RoF I build a table measuring the frames between the shots:

The first FireInterval is discarded because of that surprising finding that the first FireInterval always takes less time in ZT than every other subsequent FireInterval. The rest are averaged, multiplied by the theoretical time between 2 frames filmed with the 60 FPS precision and the average time between 2 shots in milliseconds is arrived to. As you can see, the measurements turned to be extremely accurate, as they match the theoretical value of 825 seconds down to the 6th digit after dot. Then, this “average time in milliseconds” value is used in the table and the graph you’ve seen at the beginning of this post. One can measure the FireInterval in between any 2 arbitrary frames belonging to the weapon firing animation, but for simplicity reasons I always choose the first frame that shows that the bullet has left the barrel and compare to the next frame showing the next bullet leaving the barrel and so on:

My config used for experiments:

https://www.zsdr.org/aux/recoil-on-fps-m14-ss-Config.7z

Note, that it’s a default config my fully vanilla game, which files I’ve “verified” with the steam client to ensure its integrity, recreated from scratch. Besides the MaxSmoothedFrameRate option, here is a list of all the changes I’ve made to the config before beginning the experiments:

The testing map used for test is a good old testing map by Fauxy_. Although it hasn’t been updated, it serves me well for the purpose of this experiment:

https://steamcommunity.com/sharedfiles/filedetails/?id=1545251419

There are many ways to measure the pixels of the vertical muzzle climb on the wall of the test map. The most simple and obvious one is to make a screenshot, open it in any graphical editor, select the portion of the screenshot between the M14 laser dot on the wall and the low end of the wall, then crop it so the rest of the screenshot is removed, or copy/paste it to a new file and measure the new image vertical size in pixels with whatever basic stats the graphical editor offers.

I personally used this nifty tool from the olden days which still works and weighs only 600 KB:

https://pixel-ruler.en.softonic.com/

Here’s how it looks like when I use it to measure the pixels:

Note, that unfortunately, I don’t measure the pixels while playing the video full screen. In my tests I used the default size of the maximized video played in the VLC player on a 1920×1080 monitor resolution. This is a downside that resulted in a bit of lost precision, but by the time I realized it, I was deep enough into the experiment and didn’t want to restart everything from scratch for yet another time.

Note, that for the real time measurements of the climb I make 3 measurements and calculate the average. It’s mostly not needed, because the small RNG play of the vertical M14 EBR rifle recoil between the low margin of 200 and high margin of 225 tends to average itself around the middle ground value of 12.5. But, still, the demonstration of it is useful, so everyone gets the idea of the margin of error in such measurements, which turned out to be very small, the highest difference in the measured values I’ve had was mere 3 pixels in the values of the 200 pixel scale.

M14 “Marksman” sharpshooter videos

I relied on separate videos for RoF and reload times measurements and for recoil measurements, because when I was filming the videos for RoF I didn’t know that it’s worth combining them and make just one video per FPS value to measure everything. If you will be replicating this I suggest you film just 1 video for 1 FPS value. Below I’m going to post only the recoil measurement videos, which still can be used for everything, however, some numbers of the frames between the shots measured for the purpose of measuring the RoF won’t match the values provided in the RoF table.

 

 

Existing basic replications

Because the results turned to be extremely weird, several people (the EU CD group and the Russian-speaking players that hang on SPB-GS servers) made some basic replications that confirm the main finding, that FPS in KF2 does affect weapon recoil, rate of fire (RoF) and reload animations. Their partial replications can be found below:

https://youtu.be/-1vdfFufOLw?si=dpbrrn3lBzipd5US

https://youtu.be/EhMYzWMb_Q0?si=SAsw8yKYPBcjrIaU

Who was in the know?

CaptainSAWB5 was the first player who discovered the RoF/reload times on FPS dependency and was the first who went public about it, as well as recoil on FPS dependency, in August 17th, 2023. This was a very commendable action and this is how all and any exploits in the game that allow to have advantage over other players should be treated. He didn’t keep it for himself, so he could score higher stats, but, instead, shared everything with the community, so we can collectively work on addressing this problem.

However, there’s limited evidence that shows that some CD players from the olden times may have known about the recoil on FPS dependency (but not RoF/reloads on FPS dependency) as early as in 2018. We may have some players who have been abusing it to get better recoil KNOWINGLY all this time and never shared it with the broader community. The evidence I’m talking about is this screenshot of what I assume is a discord DM, shared by one old CD player who preferred his identity to remain private.

Although the results of this research turned out to be quite weird to say the least (e.g. 150 FPS has lower recoil values than 240 FPS), the general rule observed in this DM holds.

Conclusions

I’d like to thank CaptainSAWB5 for nagging me to finish this research, which I’ve been taking my time to do for at least half a year. If not for him, I would’ve rather done something else. CaptainSAWB5, overall, is the conscience of this game at this moment, and if not for him, we likely wouldn’t have any integrity in the higher levels of CD play at all. He needs a prize for his efforts.

I’d like to thank Fanta for providing useful tips regarding the process, such as having the ‘showdebug weapon’ command output, which warranted some adjustments in the last series of tests, as well as his overall contributions to the scene, such as putting ~20K lines of code into the “Controlled Difficulty ChokePoints Edition” KF2 mod project, and maintaining the “CustomWeapons” mod.

Obviously, more research and replication attempts are needed. If you want to contribute to this research and the CD scene, please run additional tests for some arbitrary FPS numbers which can improve the accuracy of the curve on the recoil on FPS dependency graph. If you do, make sure you rely on VLC with the same resolution maximized windows and all other peculiarities of my own videos, so we compare apples with apples.

We need to build similar tables and graphs for the gunslinger perk as well, at least for the SPX rifle and the dual Desert Eagle pistols.

If you are a talented UnrealScript modder, you will contribute a lot to the CD scene in KF2 if you help with finding the root cause of the observed phenomena and suggest ways to fix it.

There are obviously huge political implications for the scene and, no matter if the solution to detach FPS from recoil/RoF/reloads is found or not, we need to come up with a common standard for every hardcore player in this game which should be followed with a gentleman’s agreement across different groups, to make the runs comparable. I intend to run 2 polls, the details of which are still being discussed, one for HoE+ players and another for hardcore CD players, which FPS should we consider mandatory to maintain the level field for every player. I intend to wait for 2 weeks before running the polls to allow enough time for digestion and basic replication attempts.

Note, that, unlike with RoF and reloads on FPS dependency, where the beginning of the graph is absolutely flat, we can’t assign a “cap” to FPS for recoil on FPS dependency, because the graph is NOT flat. E.g. if we assign it to 240 FPS, those who rely on 150 FPS are going to have advantage with less recoil in ZT and minimally less recoil in real time over those, who rely on 240 FPS. I believe it shouldn’t be just a “cap”, but a mandatory value every player should stick to.

The new developments, speculations, gossip and drama will be discussed first in discord and steam blog and may be added here when established as solid later on.