Jump to content

Arena Breakout: Infinite

Hipfire is added, aims coming soon!
Read more...

Project L33T

See the game notes for instructions on how to disable smoothing.
Read more...

Twilight Town: A Cyberpunk FPS

Just added.
Read more...

Contain

See the game notes for instructions on how to disable smoothing.
Read more...

Vomitoreum

Just added.
Read more...

Killing Floor 2


Recommended Posts

Something is wrong with the FOV PercentageValue 😥

I am having a 21:9 monitor and want a 121 hfov. In theorie 90* 1.3476 = 121, and the calculator is saying the same. But ingame 134.76% is waaaaaay too much tho, I need like 113% to get 121 hfov 😕

Any ideas?

 

Also: changing the horizontal resolution in the calculator does not the affect the horizontal fov, while in game it does affect the horizontal fov

Edited by WhoCares?
Link to comment
1 hour ago, DPI Wizard said:

Then it's probably locked to 16:9, and for 21:9 it just adds on the extra width. I'll take another look at it.

The way it works is overly complicated but if I remember right the base FOV is locked to 16:9 but the percentage multiplier is on the real horizontal FOV after that. So base 21:9 horizontal is ~120 but 125% fov slider is actually 150.

It's been a very long time since I tested all this so I could be misremembering though.

Link to comment
  • 2 weeks later...
On ‎6‎/‎9‎/‎2019 at 10:46 PM, DPI Wizard said:

Then it's probably locked to 16:9, and for 21:9 it just adds on the extra width. I'll take another look at it.

Could you find the fix? :)

I took Skwuruhl advice but it still seems off for me 😕

Edited by WhoCares?
Link to comment
  • 1 year later...

Hello everyone,

I see that this website only reports one value for "ZoomedSensitivityScale", but this discussion page seems to indicate that I should set ZoomedSensitivityScale to different values depending on what gun I want to match the sens with. I'm reading through Skuwuhrl's messages but tbh its a bit hard to decipher what I should be doing here. 

Given a certain gun, how do I calculate what I should set my "ZoomedSensitivityScale" in order to get 0% mdv/mdh for that gun? Does my hipfire sens change that at all?

Link to comment
  • Wizard
3 hours ago, KimiNoKataware said:

Given a certain gun, how do I calculate what I should set my "ZoomedSensitivityScale" in order to get 0% mdv/mdh for that gun? Does my hipfire sens change that at all?

I need to add the gun with the correct parameters to the calculator, doing the calculation manually is quite complicated.

Which gun are you thinking about?

Link to comment

According to Skuwuhrl's old spreadsheets in this discussion, it looks like most of the weapons have 70 FOV.

Assuming all 70 FOV weapons have identical behavior, then one of those would be the best to add to the calculator, because they cover the most options.

So, "MP7, RPG-7, all assault rifles, all shotguns,  all medic weapons except HMTech-101". I guess that means MP7 is as good as any.

Thank you

Link to comment
On 4/24/2019 at 1:30 AM, Skwuruhl said:

@p0sey https://github.com/Skwuruhl/kf2ads

It's kinda hacky since you can only match 1 zoom level at a time, but this helps create keybinds for every zoom level.

@Skwuruhl

I have a question about this line: "Zoom ratio scales sensitivity by the focal length then multiplies it by the coefficient. Use 1.0 by default."

I wanted to confirm that "zoom ratio mode" with a coefficient of 1 is the same as 0% MDV/0% MDH/"my reticle moves the same speed regardless of whether I'm ADS'd or Hipfiring"

Link to comment
  • 2 years later...

If I'm not mistaking, the Halloween 2022 update added UI Horizontal and Vertical sensitivity settings, though I don't think this affected any of the calculations, I guess it is worth mentioning. 

 

Also, as some users pointed out before, could you look into the LookRightScale and LookUpScale values (KFInput config file), I personally set both to 0, and the only thing I noticed is the calculated sensibility is ever so slightly off (barely noticeable if I'm being honest). It would also be great if you could add the ADS sensitivity for the various types of weapons instead of the unknown weapon the calculator uses 😁

Link to comment
  • Wizard
On 5/20/2023 at 4:06 AM, benedu3095 said:

If I'm not mistaking, the Halloween 2022 update added UI Horizontal and Vertical sensitivity settings, though I don't think this affected any of the calculations, I guess it is worth mentioning. 

I've added the horizontal and vertical sensitivity values now, clarified what the ADS is and added ACOG. Let me know if you want a specific weapon added :)

https://wiki.killingfloor2.com/index.php?title=Useful_Console_Commands_(Killing_Floor_2)#Weapon_Class_Names

Link to comment
9 hours ago, DPI Wizard said:

I've added the horizontal and vertical sensitivity values now, clarified what the ADS is and added ACOG. Let me know if you want a specific weapon added :)

https://wiki.killingfloor2.com/index.php?title=Useful_Console_Commands_(Killing_Floor_2)#Weapon_Class_Names

Thank you!!

Based on @Skwuruhl's old research, I would say the Flamethrower, 9mm Pistol, MP5RAS, M79 Grenade Launcher, SCAR-H &/or MP7, Winchester 1894, and Husk Cannon would pretty much cover most of the weapon "types" present in the game. It would also be worth taking a look at scoped weapons such as the Crossbow, M14 EBR, and Railgun, though I think these are already covered by the "ACOG" sensitivity  you just added :)

Link to comment
  • Wizard
On 5/26/2023 at 2:17 AM, benedu3095 said:

Thank you!!

Based on @Skwuruhl's old research, I would say the Flamethrower, 9mm Pistol, MP5RAS, M79 Grenade Launcher, SCAR-H &/or MP7, Winchester 1894, and Husk Cannon would pretty much cover most of the weapon "types" present in the game. It would also be worth taking a look at scoped weapons such as the Crossbow, M14 EBR, and Railgun, though I think these are already covered by the "ACOG" sensitivity  you just added :)

All are added now :D

Link to comment
  • 6 months later...

Hello there,

I would like to inform you that the Killing Floor 2 sensitivity calculator needs to be updated.

First of all, the "Sensitivity 1" and "Multiplier 1" text boxes in the calculator adjust the wrong variables:

  • "Sensitivity 1" should be "MouseSensitivity" in the configuration file.
  • "Multiplier 1" should be "MouseLookRightScale".

At the moment, the variables are reversed: "Sensitivity 1" sets the value of the "MouseLookRightScale" multiplier, and "Multiplier 1" controls the actual sensitivity variable, which is "MouseSensitivity".

When the "Conversion Source" is set to "Distance", the calculator takes a "Sensitivity 1" from the user, assigns it to "MouseLookRightScale", and automatically picks the "MouseSensitivity" value for the requested 360° distance. The value suggested by the calculator feels correct, but the problem is that the locked text box in the calculator is "Multiplier 1" when it should be "Sensitivity 1".

Secondly, the minimum and maximum values need to be updated as well.

In the game's source code (which comes with the Killing Floor 2 SDK), the minimum and maximum sensitivity values are defined as 0.01 and 0.7, but what the user sees and manipulates in the game are these values multiplied by 100: from 1 to 70. The default value is 30.

Please note that these boundaries are only applicable to the GUI slider. It is possible to go beyond them using the "SetSensitivity" console command or by setting "MouseSensitivity" to the desired value in the configuration file ("KFInput.ini").

The multiplier, MouseLookRightScale, ranges from 20 to 500, both in the code and in the user interface. Default: 100.

Those numbers can be checked in the following file for the Steam version of the game:

[Killing Floor 2 root directory]\Development\Src\KFGame\Classes\KFGFxOptionsMenu_Controls.uc

 

defaultproperties
{
	// ...
	MinMouseLookSensitivity=.01
	MaxMouseLookSensitivity=.7

	// ...
	MinMouseLookRightScale=20
	MaxMouseLookRightScale=500
}

And here is the multiplication of the MouseLookSensitivity sensitivity limits by 100 in the UI:

[Killing Floor 2 root directory]\Development\Src\KFGame\Classes\KFGame\Classes\KFGFxControlsContainer_Input.uc

 

function InitializeOptions()
{
	local GFxObject ValuesObject;
	local KFPlayerInput KFPI;

	// ...

	if ( !GetPC().WorldInfo.IsConsoleBuild() )
	{
		ValuesObject.SetFloat("sensitivityValue"					, KFPI.MouseSensitivity);
		ValuesObject.SetFloat("sensitivityValueMin"					, 100 *	ControlsMenu.MinMouseLookSensitivity);
		ValuesObject.SetFloat("sensitivityValueMax"					, 100 * ControlsMenu.MaxMouseLookSensitivity);

		// ...

		ValuesObject.SetFloat("lookRightScaleValue"					, KFPI.MouseLookRightScale);
		ValuesObject.SetFloat("lookRightScaleMin"					, ControlsMenu.MinMouseLookRightScale);
		ValuesObject.SetFloat("lookRightScaleMax"				    , ControlsMenu.MaxMouseLookRightScale);

		// ...
	}
}

There is no separate category for UnrealScript, and the existing color scheme for C++ makes the code hard to read. Sorry about that.

Edited by IceBeam
Formatting.
Link to comment
  • Wizard
9 hours ago, IceBeam said:

First of all, the "Sensitivity 1" and "Multiplier 1" text boxes in the calculator adjust the wrong variables:

  • "Sensitivity 1" should be "MouseSensitivity" in the configuration file.
  • "Multiplier 1" should be "MouseLookRightScale".

At the moment, the variables are reversed: "Sensitivity 1" sets the value of the "MouseLookRightScale" multiplier, and "Multiplier 1" controls the actual sensitivity variable, which is "MouseSensitivity".

When the "Conversion Source" is set to "Distance", the calculator takes a "Sensitivity 1" from the user, assigns it to "MouseLookRightScale", and automatically picks the "MouseSensitivity" value for the requested 360° distance. The value suggested by the calculator feels correct, but the problem is that the locked text box in the calculator is "Multiplier 1" when it should be "Sensitivity 1".

It makes more sense to calculate the actual sensitivity rather than the horizontal axis multiplier, and it gives you slightly better precision for the in-game sensitivity, that's why they are in that order.

9 hours ago, IceBeam said:

Secondly, the minimum and maximum values need to be updated as well.

In the game's source code (which comes with the Killing Floor 2 SDK), the minimum and maximum sensitivity values are defined as 0.01 and 0.7, but what the user sees and manipulates in the game are these values multiplied by 100: from 1 to 70. The default value is 30.

Please note that these boundaries are only applicable to the GUI slider. It is possible to go beyond them using the "SetSensitivity" console command or by setting "MouseSensitivity" to the desired value in the configuration file ("KFInput.ini").

The multiplier, MouseLookRightScale, ranges from 20 to 500, both in the code and in the user interface. Default: 100.

These are already the defined minimum and maximum values, and the MouseLookRightScale does go below 20 in the config file.

For in-game sensitivity:

image.png

For config file sensitivity:

image.png

Link to comment
7 hours ago, DPI Wizard said:

It makes more sense to calculate the actual sensitivity rather than the horizontal axis multiplier, and it gives you slightly better precision for the in-game sensitivity, that's why they are in that order.

At the moment, [ Sensitivity 1 = MouseLookRightScale ] and [ Multiplier 1 = MouseSensitivity ]. It doesn't make sense.

I will use an example to explain why I believe that the current order in the calculator's interface is an oversight.

Let's assume that the player has set the following values:

  • Conversion Source: Sensitivity
  • Units: Centimeters
  • Convert from: Killing Floor 2
  • DPI: 800
  • Location: Config File (default)
  • Aim: Hipfire Horizontal (default)

They are using the calculator for one of the following reasons (or both):

  • Convert the 360° distance from Killing Floor 2 to another game.
  • Check what the 360° distance will be when they change the sensitivity value using the calculator's text box.

If the mode is set to "Simple", the calculator becomes essentially useless: since the "Sensitivity 1" field in the UI is responsible for the "MouseLookRightScale" multiplier, the player can only adjust that multiplier. The sensitivity variable, "MouseSensitivity", is hidden because it's controlled by the "Multiplier 1" field. To adjust the sensitivity, the player will need to change the mode to "Default" or "Advanced".

If the mode is set to "Default", the calculator becomes usable. However, the player is expected to use the "Multiplier 1" field for the sensitivity value, since the "Sensitivity 1" field is already reserved for the "MouseLookRightScale" multiplier:

- Sensitivity 1: 100
- Multiplier 1: 4.5

If the field names were substituted with the variable names from the config file, this is what this pair of numbers would look like:

- MouseLookRightScale: 100
- MouseSensitivity: 4.5

The variable names are backwards now.

Here is a snippet of code showing how the multipliers are applied:

[Killing Floor 2 root directory]\Development\Src\KFGame\Classes\KFPlayerInput.uc

 

/** Overridden to do custom FOV scaling, especially for weapons with 3D scopes */
function AdjustMouseSensitivity(float FOVScale)
{
	if ( bEnableFOVScaling )
	{
		FOVScale = GetSensitivityByFOV( ZoomedSensitivityScale );
	}

	Super.AdjustMouseSensitivity(FOVScale);
	aMouseX			*= MouseLookRightScale / 100.0f;
	aMouseY			*= MouseLookUpScale / -100.0f;
}

Do the calculations happen the same way on your website? Will setting "Sensitivity 1" to "MouseSensitivity" and "Multiplier 1" to "MouseLookRightScale" break some existing functionality the calculator relies on? Please let me know if I am missing something.

7 hours ago, DPI Wizard said:

These are already the defined minimum and maximum values, and the MouseLookRightScale does go below 20 in the config file.

<...>

For config file sensitivity:

image.png

Yes, as I said before, it looks like those limits defined in the code are meant for the UI, and the parameters can go beyond them if a config file or a console command is utilized for that. However, since the upper limits of the config file variables match the limits in the UI (100 and 500), I assumed that the lower limits were supposed to match the UI values as well.

Would it make sense to change the upper boundaries of "MouseSensitivity" and "MouseLookRightScale" to bigger values? The upper boundary of the "float" type, for instance, since I have not noticed any other enforced limitations so far. Or do you think leaving them at 100 and 500 will suffice?

Edited by IceBeam
Formatting.
Link to comment
  • Wizard
6 minutes ago, IceBeam said:

If the mode is set to "Simple", the calculator becomes essentially useless:

In simple mode, converting from Hipfire Horizontal for Killing Floor 2 should output an error saying it's not supported:

image.png

Are you not getting this error? This is by design and unrelated to the order of the sensitivity parameters. Any aim with two or more parameters are unsupported to convert from in simple mode.

10 minutes ago, IceBeam said:

If the mode is set to "Default", the calculator becomes usable. However, the player is expected to use the "Multiplier 1" field for the sensitivity value, since the "Sensitivity 1" field is already reserved for the "MouseLookRightScale" multiplier:

- Sensitivity 1: 100
- Multiplier 1: 4.5

The naming of the fields are not really referring to the absolute function of the variable they represent in each case. In some cases the Sensitivity 2 field might the FOV for ADS. Sometimes a game uses four equally weighted multipliers spread across Sensitivity 1, 2 and Multiplier 1 and 2. What each field actually represent is mentioned in the game info section.

16 minutes ago, IceBeam said:

- MouseLookRightScale: 100
- MouseSensitivity: 4.5

That's what you see in the calculation output. Renaming the header of the input fields is not possible since some games have sensitivity parameters that look like this:

<root>
 <scriptsPreferences>
  <controlMode>
   <arcadeMode>
    <camera>
     <sensitivity> 1 </sensitivity>
    </camera>
   </arcadeMode>
  </controlMode>
 </scriptsPreferences>
</root>

Or this:

{
  "Name": "Control.MouseXSensitivity",
  "SettingType": 2,
  "FloatValue": 0.236478898
},

 

24 minutes ago, IceBeam said:

Do the calculations happen the same way on your website? Will setting "Sensitivity 1" to "MouseSensitivity" and "Multiplier 1" to "MouseLookRightScale" break some existing functionality the calculator relies on? Please let me know if I am missing something.

The calculator will always calculate the rightmost value of the input fields. So if the game is using Sensitivity 1 and Multiplier 1, Multiplier 1 is the value that will be calculated. If the order of MouseSensitivity and MouseLookRightScale are switched, the MouseLookRightScale is the value that is being calculated instead. Now that will work as well, but it makes more sense to actually calculate the sensitivity rather than the axis scale.

30 minutes ago, IceBeam said:

Would it make sense to change the upper boundaries of "MouseSensitivity" and "MouseLookRightScale" to bigger values? The upper boundary of the "float" type, for instance, since I have not noticed any other enforced limitations so far. Or do you think leaving them at 100 and 500 will suffice?

100 and 500 is so high no sensible calculation will ever reach them.

Link to comment
20 hours ago, DPI Wizard said:

The calculator will always calculate the rightmost value of the input fields. So if the game is using Sensitivity 1 and Multiplier 1, Multiplier 1 is the value that will be calculated. If the order of MouseSensitivity and MouseLookRightScale are switched, the MouseLookRightScale is the value that is being calculated instead. Now that will work as well, but it makes more sense to actually calculate the sensitivity rather than the axis scale.

20 hours ago, DPI Wizard said:

The naming of the fields are not really referring to the absolute function of the variable they represent in each case. In some cases the Sensitivity 2 field might the FOV for ADS. Sometimes a game uses four equally weighted multipliers spread across Sensitivity 1, 2 and Multiplier 1 and 2. What each field actually represent is mentioned in the game info section.

Thank you for the clarification. If it's the rightmost value that gets calculated to convert the 360° distance to the sensitivity, it makes sense to shift the main sensitivity variable to the right and leave the input field(s) on the left ("Sensitivity 1" in this case) for the multiplier(s). I assume it's a universal solution to accommodate all games without building a separate calculator for each one.

20 hours ago, DPI Wizard said:

100 and 500 is so high no sensible calculation will ever reach them.

Fair enough. Strictly speaking, 16 cm / 360° at 100 MouseLookRightScale and 100 DPI pushes beyond 100 MouseSensitivity, and the same goes for higher sensitivities like 12 cm / 360°. However, the probability of someone using 100 DPI these days is very low, the [12;  16] cm / 360° isn't a reasonable sensitivity range sensitivity for many shooter games, and the calculator still provides a value for MouseSensitivity while converting the 360° distance to sensitivity, just with a warning that that it's too high. I'm bringing this up as a theoretically possible edge case rather than a suggestion to implement a change.

20 hours ago, DPI Wizard said:

image.png

Are you not getting this error? This is by design and unrelated to the order of the sensitivity parameters. Any aim with two or more parameters are unsupported to convert from in simple mode.

Thanks for elaborating on that, too. When I made that point, I assumed that it could be possible to make the calculator work if "MouseLookRightScale" became "Multiplier 1" and got forced to its default value (100). Since it's a feature related to the number of configurable sensitivity parameters rather than their order, it clears things up.

Edited by IceBeam
Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...