An Analysis of Mouse Input and Related INI Variables

[Trankquel]

NOTE: I have not kept track of which INI file each variable should reside in as the intent of this analysis is to understand how the relevant variables interact rather than the implementation specifics.

 

Acceleration and Smoothing

 

By default smoothing (have not personally checked) and acceleration are enabled. The two relevant INI variables are:

bMouseAcceleration     ; =1 enables acceleration. =0 disables acceleration
bForceIgnoreSmoothness ; =1 disables smoothing. =0 enables smoothing

From this stage forward it will be assumed that acceleration and smoothing are both disabled.

 

 

 

Mouse -> Creation Engine Input

 

To the best of my knowledge the Creation Engine uses raw mouse input (I haven't checked, please correct me if I am wrong) and thus takes the raw changes in x and y coordinates outputted by the mouse (herein referred to as delta_x and delta_y) and transforms them into the rotation of the camera.

 

 

 

Creation Engine Input -> Change in View Direction While Not Aiming

 

By default and while not aiming down sights or scoped the only unusual thing Bethesda has done is multiply the pitch (i.e. the change of view in a vertical direction) by 0.5625 relative to the yaw. The relevant INI variables are:

fMouseHeadingSensitivity ; the variable for overall mouse sensitivity, values set for this by the in game slider are between 0.01 and 0.06 and the default is 0.03
fMouseHeadingXScale      ; the variable for mouse sensitivity on the x axis, default 0.021, recommended to not touch
fMouseHeadingYScale      ; the variable for mouse sensitivity on the y axis, default 0.021, recommended to not touch
fPitchSpeedRatio         ; a second variable for mouse sensitivity on the y axis, default 0.5625, recommended to set to 1

The equations for the rotation of view (in radians) from the inputs of delta_x and delta_y are as follows:

x_rotation = Pi * fMouseHeadingSensitivity * fMouseHeadingXScale * delta_x
y_rotation = Pi * fMouseHeadingSensitivity * fMouseHeadingYScale * fPitchSpeedRatio * delta_y

These equations are useful if you know the delta_x for your sensitivity in another game that uses raw input as they can be used to calculate an exact fMouseHeadingSensitivity.

 

 

 

Creation Engine Input -> Change in View Direction While Aiming

 

This is where everything falls apart and I start cursing Bethesda's name. By default Bethesda again multiplies the pitch, this time by 0.8 relative to the yaw, and then proceeds to do several other mysterious things. Relevant variables are as follows:

fIronSightsFOVRotateMult   ; overall sensitivity is multiplied by this while aiming down sights or scoped, default is 1
fIronSightsPitchSpeedRatio ; analogous to fPitchSpeedRatio except for when aiming down sights or scoped, default is 0.8 

There is however at least one more relevant variable that I am yet to find, as when aiming down sights or scoped the sensitivity changes relative to zoomed (i.e aimed or scoped) FOV.

 

In a sane game (such as CSGO with zoom_sensitivity_ratio = 1) you would expect the sensitivity to scale linearly with FOV so that a certain movement of the mouse translates consistently to a movement of the crosshair from it's current position to what was at a certain point on the screen from before the movement began. This can be represented mathematically as follows, where zoom_ratio is the zoomed FOV divided by the unzoomed FOV:

x_zoomed_rotation = x_rotation * zoom_ratio
y_zoomed_rotation = y_rotation * zoom_ratio

For example, a 10mm pistol with tactical (reflex?) sight has a zoom ratio of about 0.8, thus if a certain delta_x causes a rotation of 2 Pi radians while unzoomed you would expect the rotation while zoomed to be 2 Pi * 0.8 = 1.6 Pi radians.

 

However what I have found is that the fIronSightsFOVRotateMult and some other variable(s) are also being applied in some way as to change the rotation (and thus sensitivity) relative to the zoomed FOV.

 

For an example from my testing, if the zoomed FOV is 72 degrees then a certain delta_x will lead to a smaller x_zoomed_rotation than if the zoomed FOV is 90 degrees. Thus as zoomed FOV increases, sensitivity increases.

 

 

 

Further Research

 

At this point I have written this post in the hope that someone has found or will find an INI variable or variables that relate FOV to zoomed sensitivity (and that Bethesda hasn't been idiotic enough to hard code this).

 

To get to this stage I had to do a lot of testing with emulated mouse movements. To do this I used FreePIE and the scripts I used are attached.

[Trankquel]

After further research I have found that my assumption that the zoomed FOV was calculated using a sight specific ratio was incorrect and that with the right fIronSightsFOVRotateMult value the zoomed sensitivity scales linearly.

 

From testing it appears that as the unzoomed FOV (i.e. fDefault1stPersonFOV) is increased fIronSightsFOVRotateMult needs to be decreased in a non-linear fashion to maintain linear sensitivity scaling at different zoom levels.

 

I plan to update the original post either once I have found the equation for calculating the correct fIronSightsFOVRotateMult value or, failing that, a series of common FOVs and approximately correct fIronSightsFOVRotateMult values.

[Slider2k]

Seem that Power Armor has and additional pitch modifier (or limiter).

 

EDIT: It has reduced pitch sensitivity when crouched.

Edited December 11, 2015 by Slider2k

[H0T5H0T]

Seem that Power Armor has and additional pitch modifier (or limiter).

 

EDIT: It has reduced pitch sensitivity when crouched.

 

I noticed the same issue, but it seems to revert to normal sensitivity while moving. Setting fPitchSpeedRatio=1.7778 (1.0/0.5625) is a very close, if not perfect, fix. The downside, however, is that the vertical sensitivity is now much too high in every other situation. It seems there's another multiplier specific to being crouched and stationary in power armor, but I have no idea if it can be changed via ini or will require memory editing or an F4SE plugin.

 

On an unrelated note, based on my (admittedly anecdotal) findings, bForceIgnoreSmoothness seems to relate to a graphical setting rather than mouse input, as it's under the [Display] heading of the ini and lowers one of the launcher presets to medium when enabled (shadows or lighting, I can't remember which at the moment). I don't think any prior incarnation of the engine had an ini setting specifically for mouse smoothing, and after playing 50+ hours with equal vertical/horizontal sensitivity I haven't noticed any smoothing whatsoever. It also appears bMouseAcceleration is no longer a valid ini variable according to the saveini command: http://forum.step-project.com/topic/9309-fallout-4-default-values-for-all-valid-ini-settings/

 

It certainly doesn't hurt to keep it disabled anyway, but I haven't noticed any difference with it set to 0 or not in the ini at all.

[Grifflester]

I tried fixing it in the Creation Kit. Maybe try this out and reply if this fixed the issues for you guys?

 

https://www.nexusmods.com/fallout4/mods/12480/?