TheNoobPolice

I thought I'd share a formula I have used that matches my own preferences pretty perfectly for a "one size fits all" scope zoom scaling, (an updated "uniform soldier aiming" if you will, for games that use many scope zoom levels).
As many of you agree focal length or "0% monitor match" is the mathematically principled way to scale, with arbitrary monitor distances effectively being just a hack to mitigate the natural slowdown effect that zooming-in creates when using focal length scaling. 
While playing games like Battlefield 4 / 1 or the newer Cod's, I always ended up with the coefficient set to 0% for low-zoom scopes, and then each scope's individual slider gradually increasing in sensitivity the higher the zoom level.
It was always fairly apparent to me that commonly used monitor distances like vertical 100%, 133% or especially 178%, are too fast at low-mid zooms of irons / red dots etc, whereas focal length scaling is always much too slow at high zooms / sniper scopes. I think this experience is also shared by many others.
So I have taken the monitor distance hack a step further to allow what is effectively a dynamic coefficient via a simple calculation based on the start and end FOVs. This is nothing new of course, but unlike other variable methods like Viewspeed or Jedi's trick that also do this, it scales much more broadly by comparison. Converging to focal length scaling for the lowest zooms, and approaching an asymptotic monitor distance limit at an "infinitely high zoom" (or a hard cap).
Here's a graph of the formula with regular 133% vertical monitor distance and focal length scaling for comparison. By replacing the monitor distance coefficient with simply Limit*(1-(ZoomFOV/HipFov)) the coefficient approaches a value of zero when the two FOV's are close together, and gradually approaches the limit the more they diverge.
https://www.desmos.com/calculator/rlrmeml65f

If you enter the hip and zoom vFOV's with the sliders, the graph will calculate a monitor distance based on the variables entered for any games ADS FOV level exposed on this site.
A limit of 2 would mean the maximum monitor distance is 2 for when "zooming to infinity" - the transitional shape would then be like a logit function with the midpoint of 0.5x zoom sensitivity multiplier occurring at exactly half of the base FOV (i.e coefficient of 1 at the midpoint). This value probably makes the most sense, but I personally prefer a limit of 1.5, as seems the most appropriate for the zoom amounts we tend to use in games. As an example, this results in the highest zoom scope I used in BF4 having roughly 130% mdv, and the red dot sights having around 14% mdv when scaled from hipfire. The power could be raised to stay closer to focal length scale before approaching the monitor distance limit, but probably best to leave at or around 1-2.
This is still just an arbitrary solution of course and I am not claiming it is objectively better than any established method, just an approach that very closely approximates my own preference formulaically - with pre-set limit / power of 2 I do believe it would be better for users as a "one click" option than the existing relative / USA with coefficient options.

There is no solution to your request. "Instant" and "After" are emulations of an old, poorly designed system and should not even be options. "Gradual" is the only sensible choice, but even this is different between games - it can be "procedurally gradual" by FOV change per frame (so sens adjustment follows a sigmoid curve) or sometimes it's just "gradual over time" (linear sens adjustment).
Even if you attempted a hacky fix, like scaling DPI by zoom transition time using a filter driver or script (which might trigger anti-cheats), you couldn't stop the game from doing its own scaling. This scaling is nearly impossible to reverse engineer unless you have access to the source code, which would still be an extremely inelegant solution.
I'm afraid this just falls under "learn to play the new game," similar to adapting to changes in movement speed, camera pivot point, crosshair position, recoil/sway, and other factors that make targeting feel different in each game.

A new feature is added to the calculator that enables you to reverse calculate your current sensitivity. This functionality helps you identify the most suitable method, coefficient, and scale to align with your existing sensitivity settings. It simplifies the process of finding the precise matching parameters to effectively maintain your preferred sensitivity.

The "Reverse" button is positioned above the selected game in the "Convert from" dropdown menu. Initially, it will appear grayed out and inactive until specific criteria are fulfilled:
The selected aim must be "All" and be comprised of multiple sensitivity variables. For instance, it won't function for games that employ various aim calculations but all utilize the hipfire sensitivity. The calculation for the "All" aim must be error-free for the primary sensitivity. Errors related to ADS and scope aims being out of range won't affect this condition. When these conditions are met, the "Reverse" button will turn green. The sensitivity, FOV, resolution, and other parameters you input for the "All" aim will act as the foundation for the reverse calculation, necessitating an exact match with your current settings.

When you click the "Reverse" button, a popup with all the aim sensitivity will show. Note that aims that are not ADS or scope will not show up. Some sensitivity settings are shared between more than one aim, if so a dropdown box will show next to the sensitivity and you need to select the aim you are entering the sensitivity for. Enter your current sensitivity into corresponding boxes, vertical sensitivity is also supported for reverse calculation. You do not have to enter a value into all the boxes, but it is recommended for best accuracy. Once all values are entered, clicking "Reverse!" will generate a table presenting all suggested calculations based on your inputs.
If you are converting from a game with both ADS and scope sensitivity, you will see three tables: One for the best match for both ADS and scope combined, one for just ADS and one for just scope. If the game only has ADS or scope, only one table for both ADS and scope will show up. Vertical sensitivity will show up at the bottom.

 
The Monitor Distance methods will only show up in the ADS and scope table if the coefficient and scale is identical for ADS and scope.
Click the "Use" toggle for the matching method(s) you want to use, then click "Apply" to use the settings for your calculation.
If you find anything not working as expected, post it here. Note that you will not always get the expected result because of rounding.

We now have a Discord server for the community, join it to both discuss stuff and get support!
https://discord.gg/yY3PAg6r32

View full update

Pixel ratio is calculated by dividing the sens- scaled yaw value (I.e degrees per count) by the amount of degrees in the centre of the screen over 1 pixel’s distance at any given FOV, which can be found as follows:
e.g for Counter Strike at 1920 x 1080 res:
yaw = 0.022 degrees;
sens = 0.5;
horizontal res = 1920 pixels;
horizontal FOV = 106.26 degrees;
Degrees per pixel distance = 2 * atan(tan(hFOV / 2 * pi / 180) / hRes) * 180 / pi = 0.0796 degrees;
Pixel ratio = yaw * sens / degrees per pixel distance = 0.138;

With mouse input we convert a physical distance to a virtual distance. To do this we normalise both to virtual units.

The "count" or "mickey" is a virtual unit defined by the DPI. If you are at 400 DPI, then 1/400th of linear inch movement, sends a "count" of 1 to the PC. 

At the PC side we convert these virtual count units to output distance units. This is either in pixels in 2D, or angles in 3D.

The angles in a game is indeed defined by a "Yaw" value e.g. Source engine by default has 0.022 degrees - this means that 1/400th of an inch (1 count) from our mouse movement turns 0.022 degrees (the base yaw) in the game. These are our normalised input and output virtual distances from your hand motion.

The sensitivity of any function is the ratio between the output and the input, therefore we can say it is a multiplier. Since we already have our normalised values, then we know the sensitivity of "1" is an input of 1/400th of inch on the mouse pad, and an output of 0.022 degrees, so a sensitivity of "0.5" would be an output of 0.011 degrees for the same input distance.

This can always be calculated as outputAngle = yaw * sensitivityFunction() * counts.

Therefore to solve for counts instead, we do counts =  outputAngle / ( yaw * sensitivityFunction() ).

Example; we have a game that has a yaw value of 0.014 degrees, sens of 1.2, and we're at 1600 DPI and want to turn 30 degrees. How many counts do we need to turn to this position?
so we have 30 / ( 0.014 * 1.2 ) = 1785.71.

To convert back to physical hand motion, it's therefore:  1785.71 / 1600 = 1.12 inches on the mouse pad turns 30 degrees in the game.

You have to always use the same units for both outputAngle and yaw value obviously. I use the term "sensitivityFunction()" because the value exposed to the user is not always linear like in Source, so this multiplier would be the return value of whatever formula a game uses to represent this to the player, which is highly variable and completely arbitrary so is one of the main reasons for this site's existence.

Read here
 
 

You are going about this in an overly complex way. If you want to increase vertical sens without changes in direction and without using acceleration you would really need to use something like the Bias mode I added to Custom Curve.
In Raw Accel you can do similar but you kind of just have to "hack" it using the LUT mode and anisotropy by using an "instant" acceleration to a cap that all occurs below minimum input speed.

You could set it as follows:

LookUp Table (Sensitivity mode):
1e-17,2;
1e-16,2;

Sens Multiplier = 0.5
Y Range = 2 * desired y/x ratio - 1 = 1.84972170686 in your case


This creates the same graph as your y/x ratio version, but does not change diagonal directions (This shows what usually happens).

This method works because we create some invisible instant acceleration between sens 1 to 2 and the range function has a formula of:
(acceleratedSensitivity -1) * (rangeX + (rangeY - rangeX) * (atan(|y/x|)) / (pi/2)) + 1

or more easily understood as:

"A single sensitivity applied to both axes, that is linearly scaled to each axes configured sensitivity value by the ratio of input angle to 90 degrees"

The transition across angles would be entirely linear in Raw Accel, so an input of 45 degrees would have a sens of (1 + (desired y/x ratio -1) * (45/90)) = 1.212430426715, and an input of 22.5 degrees would have a sens of (1 + (desired y/x ratio - 1) * (22.5 / 90)) = 1.1062152133575, but there is only this one sensitivity applied to both axes components at all times so directionality is preserved - increasing vertical sens in this way does not make near horizontal motions less stable by "pitching up" your crosshair like what happens with a y/x ratio change.

Using legacy threshold-based angle-snapping is a bad idea since it is extremely flawed and simply obfuscates angles below the set threshold - which is doing nothing except reduce the fidelity of input. There could be less compromised ways to facilitate a larger / more forgiving angular window to move along an axis, but none that are available at the moment.

ohhh okay. Thanks a bunch for explaining everything to me and great work on that program, I'm glad I bought it way back. And yeah, that '1 sec' thing really threw me off, i was thinking im sure i didnt notice a delay in input hahahaha. Have a great day dude

Yes! Well, everything that actually affects your mouse input. The GUI which is just used to visualise and apply settings is in user space.
Obviously not as that would be ridiculous lol. When you press "Apply" all profile settings are written to the driver, and there is a 1 second delay until they are operational. There is no delay in use.

Why would it be required to scale sens and not DPI? If you want a smaller turn increment, just set sens to the lower value of whatever the change is. You could load the rawaccel profile only when playing the game or even script it trivially with something like Autohotkey to load both the game and the profile automatically, this is much safer and would work better than trying to modify game memory using cheat engine.

I've updated the calculations using the latest version of the mod NoMouseSmoothingReducedScaling. I've also removed the NoFovScale entry as there's basically no reason to use it over the other.
The sensitivity was changed significantly (1/3 of before), and the X and Y are now the same.

Read here
 
 

You only need to enter DPI in the app for the velocity chart (since it charts real-world meters per second as units) and / or if you want to measure true DPI accuracy / deviation (can also be done on this website).

Your mouse has much better performance than any of mine as far as it's SPI timing (jitter) and counts distance consistency, probably why it also drifts far less than any of mine do.
You plot would not improve much if at all from any smoothing as it's remarkably un-noisy (most likely because there is some internal smoothing applied in the sensor / firmware which is why the plot is so nice).

So basically, although this is a big issue for you personally, you probably have less than or equal to the lowest drift of any modern mouse available, and I once again refer to my previous advice of you really should find something else to worry about. If anyone tells you they are getting less drift they are probably either not testing in real-world conditions or just talking nonsense.

I’ve seen this said before, but just to note it isn’t true that this is the cause of this. Your wrist does indeed move left to right and back in an arc, but the sensor is fixed in its position in the body of the mouse, so rotates to exactly the same angle made by the arc at all times, so from the sensor’s perspective that can only read delta x and delta y relative to it’s own orientation, it is simply moving horizontally. 
As long as the sensor stays in contact with the surface and isn’t lifted, you could move it around in any mixture of circles or curves and lines and put it back to where it started in the same orientation, and mathematically the cursor would always be back in the same position. The reason it doesn’t work like that is just because the sensor / firmware combination is fundamentally not an accurate technology
 
This test shows a lot of optical sensor drift  even when moved by a machine that keeps the mouse fixed in the same orientation - even the G900 drifts a little and there hasn’t been any major technological reinvention of optical sensor tech since then.

You're correct. It's just that some people miss the human factor in it and others deny modern sensors having any drift, so I guess I was just covering the possibility.

Not easily. I just quickly added the code in a test build of a driver I contribute to, which requires a development environment (and it isn’t open source anyway).
I’m not aware of any method using windows hooks to block the native mouse input after reading raw input to then send out modified output to the cursor, because the same hook would block the modified output also, so to do this with the cursor would require a kernel driver (to my knowledge) that doesn’t see it’s own output.
I could just build that function into an .exe with a free-to-use signed kernel driver library like Interception, but then my .exe wouldn’t be signed and any anti-virus would probably immediately panic and mistrust it these days.
I’d rather just share the code and anyone who wanted to try it build it themselves locally, which given you don’t code is a bit of a stumbling block.
But it wouldn’t solve your kind of drift fully anyway, and neither does an exact replication of the code you linked before - it just helps mouse they have very noisy distance input feel a little more stable. I’d run MouseTester on your own mouse first to see if it would be any benefit.

I don't think anyone should run an .exe from a mega link. If it's not open source and linked on Github or similar, and there is nothing particularly interesting about the value of how much the cursor drifted IMO. You can see on the screen how much it drifts after all, you don't need to accumulate the mouse counts via Raw Input to do that, since 1 count = 1 pixel * WPS multiplier you could just check the cursor position before and after. For what it's worth my Razer Orochi v2 mouse on my current mouse pad, drifts up much faster than yours does.

I'd just suggest you stop worrying about this very normal issue with every mouse ever made.

 

Yes, Beenox introduced the Relative mode a few titles ago as a way for Battlefield players to easily convert from it's Uniform Soldier Aiming option with the same default scaling multiplier.

ADS and scopes added, but only for "PreserveFOVScaling" as this is how the base game actually works.

Just a tip; the FOV line in the config file won't appear unless you have changed the FOV in game.

This also goes for all the sensitivity values, and they will appear in a random order 😵‍💫

Just a tip; the FOV line in the config file won't appear unless you have changed the FOV in game.

The aim punch / flinch is indeed awful. Makes 1v1's very frustrating. I hope that gets tamed a little.

It wasn't added for this game per se, the sliders are a legacy setup from older games and sometimes there isn't anything in the new game to bind them to (or they could be considered placeholder in case the design teams add them later). This was the case for BFV also. It's often easier to leave in a function than to remove it.

Only BF1 had an actual 1.0x ADS magnification option (BFV conceded and made it 1.01x). All the other games have always had a varying degree of magnification for "iron sights", "close range" or "1x" regardless of the number stated and this is not unusual  - in most military shooter games the target sizes at the hipfire FOV's people tend to favour are not suitably large enough for the distances the designers build the geometry scaling around, so especially for games that are to be played on console (where players are usually sat much further from the screen) not reducing the FOV when aiming just produces a bad experience. The only reason it worked in BF1 were that the engagement ranges were on average much closer for a Battlefield game, and the manual 3D spotting made enemy visibility easy enough to access to get away with "no zoom".