That’s all totally unnecessary and just placebo.
Just so you know how mouse input works because it seems like you may not, but that’s fine. A mouse sends a packet of (x,y) data to the OS as defined by the DPI value and distance moved since the last poll timeframe (usually 1ms).
The game then takes this data and converts it to angular rotation, using a fixed pitch/yaw value and a variable (usually linear) sensitivity multiplier. So if it was pitch/yaw of 0.022 degrees at sens 1 for a given game, and you moved (10,5) at sens 2 then you would turn 0.44 degrees horizontally and 0.22 degrees vertically in a single update. These updates are then continually grouped together by the game engine since last simulation loop and divided by a fixed time constant (to ensure frame rate doesn’t affect the calculated distance).
When DPI wizard here analyses a game using scripts, he would send the exact same counts distance value at multiple speeds and cadences to detect what would happen if a mouse was moved slow or fast for the same distance, which would show if there was any baked-in acceleration, smoothing or packet loss(negative accel). Since the input now produces the same result every time, there is no issue.
Mouse sensitivity isn’t a black art. It’s just an objectively measurable ratio between an input and an output distance and simple math - it either arrives at the correct position in the game world for the same counts distance input, or it doesn’t.
I’m not really sure what you are trying to achieve with that video but it is not going to help either yourself or anyone else to be doing all that. Unless you are happy for people to waste their time trying to copy that just to get views then it’s probably best if you just deleted it
Hipfire sensitivity is unaffected by FOV (meaning the 360 distance stays the same), so to match it the sensitivity is lowered to 0.999995.
ADS is however affected by FOV, and as mentioned earlier it is rounded before calculation. So 1.28571 which is 89.999700 4:3 FOV is rounded up to 90 before calculation. And with MDV 0% as this game is based on this results in 1.000005 to compensate for the games buggy rounding.
It is already precise within 0.0001 inches, this is not even measurable with scripts so I think you're good with 6 decimals
The difference between 1.000005 and for instance 1.0000059 is less than 0.04 counts/360.
ohhh okay I think I get it now. So the point is that we have chosen to project vertical lines as straight instead of horizontal lines as straight (we have to pick one due to projection of a 3D space onto a 2D plane), if we are using monitor match, it applies on x-coordinates irrespective of y values. However, MM does not apply in the y-axis unless x-coordinate is 0. Therefore, choosing MM values other than 0% is going to lead to inconsistencies in y-axis when snapping to targets not aligned to the line x=0.
sidtai817 got a reaction from potato psoas in Perceived sensitivity