TheNoobPolice

Actually 0% is the only "monitor distance" (because it isn't actually one) that maintains it's relationship regardless of orientation in the world. The velocity at the crosshair is always the same no matter where you look. You feel slower when you move away from the equator for precisely the same reason it feels slower when you zoom in a lot using 0% - the distortion within screen space. You have to move in a curve on the mouse pad to move in a straight line on your monitor the more you look up or down to the poles, and therefore more distance on the pad is necessary in angles where you naturally have less range of motion (diagonal / more vertically). That's why it's generally a good idea to increase the vertical sensitivity somewhat, at least for ergonomics sake.

What Fortunate said is correct, it does not matter as the calculator works it out for you. If you have 1.33 aka default coefficient set in game, it will scale the majority of the scopes slower, besides high zooms. and when set to 0, it will scale all faster (and increasingly so as you zoom in) But the net result is identical once you are zoomed in (technically, there may be a small difference when using "gradual" transition, because the sensitivity ramp during the animation will likely scale procedurally by the coefficient selected, only to be multiplied directly by the scope factor as a post-scale, which would not have the same transition shape as if you just had set the final monitor distance as coefficient to begin with. This is such a tiny detail though that occurs over such a short period of time I would not even consider it worth trying combinations of in-game coefficients vs scope multipliers)

Set the calculator like this

There's no relationship. Rawaccel is scaling your sensitivity by mouse input speed, the dynamic monitor distance curve is scaling sensitivity by zoom ratio. You can always move at all hand speeds at every zoom level.

Correct. Just note that the monitor distance at the limit is the vertical (edit.....and you totally did see that, which is why you said MDV. I'll try and read better in future.)

Originally I was framing the idea as scaling based on FOV values. 2 & 2 made the most sense because the mid-point of monitor distance was then the midpoint of the FOV scale range. This made it easy to visualise without any graph - one could easily remember that when the FOV cuts in half your "mouse movement to monitor match point" is exactly half way between the crosshair and top of the screen (this website tells you the FOV change in it's outputs, but doesn't tell you the zoom level), and it's easy to visualise this point getting closer to the crosshair on smaller FOV changes than that, and moving upwards as the change gets larger. The curve also produced very sensible outputs as far as the FOV ranges typically chosen / used in games. But the purpose of the method is really to have a personal barometer for ADS/Scope/Zoom transition across games to your preference, and as you rightly pointed out, when the base hipfire FOV was significantly different the FOV change ratio is actually unimportant, rather instead the actual zoom (i.e level of "magnification" effectively) as far as the users perception. So better to keep this relationship. In either case, though, the fundamental method is still the same - starts at focal length scaling, ends up at some monitor distance and the values of 200% for both limit / power are still likely the best defaults. The change to V2 made the scaling slightly more aggressive toward the limit with the same limit & power values, but there would be no "makes sense" in the same way because the "zoom amount" is not shown anyway on this site's conversion output, and this is all now moot since DPI Wizard added the ability to customise the options directly here so the user can store their own preference in a preset. I like limit 150% and power 250%, which at my hipfire vFOV of 84 is basically the same as limit 150% / power 200% in the linear ratio version I first mapped my preference to. The reason this doesn't matter to me personally either way, is because for any game where I would personally care about this I will always use the same hipfire vFOV that I am used to.

I think DPI WIzard's summary here is nicely succinct. But here's how I will use it personally: Set both ADS and Scope aim classifications to Monitor Distance - Dynamic and also to the same values. The defaults of 200% for both are good. I would leave hipfire on 360 distance. Set the game's base hipfire and FOV to your preference, then match "all" aims. For example, here's using it from Battlefield 1 hipfire and FOV, to scale all the Battlefield V zooms You then get the outputs for each scope multiplier Because the default scaling in the game uses monitor distance 133%, dynamic scaling here reduces the sensitivity of the low zooms a little, and increases it for the high zooms by a similar amount in this example.

Glad you find it useful!

Excellent! The only thing I noticed is setting scope power to 0 (which admittedly there is no point in doing, since it is then just the limit monitor distance for any FOV) results in the calculations voiding and an error message saying adjust scale to 1 https://www.mouse-sensitivity.com/?share=8c7946577c6d712c7895650d19b0fdd8

Alternatively, do you think it even requires an entry for desktop or hipfire? I would personally only ever suggest this for someone wanting to scale all their scopes from one game to another (like for example, a BF player to their CoD scopes when they all use different zoom FOV's)

I can't check the math right now, but I'm pretty sure the match point between the two would have to vary when selecting different FOV ranges. There would definitely be "some value" that was the same between the two though for any individual case, which is why I don't think it would be required to have both.

I think "Dynamic Monitor Distance" or "Dynamic Coefficient" probably makes the most sense as to what it is doing. Also, are you going to add the linear scaler version or the zoom ratio scaler version? I think the latter is possibly more useful, but the limit 2 and power 2 was really defaults I suggested based on the former. @PressingForward had a good suggestion to me of using the existing scale and percent parameters and having them a call a different function when selecting this aim method, so they could directly apply to Limit and Power instead (if the structure of the site allows for it). You could have an max of 3 and a min of 1 for Power, and scale those values from 0-100% in the scale field (perhaps inversely? So increasing it makes the sens scale faster), with the percent field simply setting the target maximum monitor distance i.e limit. This would of course remove the usual function of those parameters for this mode, but it saves any extensive GUI updating

It's not a bug. See above video. It's because both the crosshair & reticle move away from the centre of the screen in the direction you turn, but at a variable rate and distance depending on the speed of your mouse movement. Your perception of sensitivity is formed from a combination of not only the game world's velocity relative to your mouse movement, but also this velocity relative to the crosshair. The eye is naturally drawn to the centre of screen as you turn by the projection of the FOV (the angles of the game world all bend away from the centre of the screen, which is called "pincushion distortion"). When the crosshair decouples from this centre there is a subtle contradictory sensation, which is greater when moving fast and less obvious when moving slowly. Having the crosshair partially move with the game world's turn-rate makes your sensitivity feel much faster when you move faster and less-faster when you move slowly, hence your perception of sensitivity feeling floaty and imprecise, and like it's too fast overall. It's not actually acceleration as far as the game world movement, but as far as the aiming movement - it actually kind of is. This is not an issue with a timing-based aiming device like a control stick but for a direct movement aim device like a mouse it's not intuitive. I think this is probably ok for some game types, single player or milsim games - but for an Arcade PvP FPS it is probably a bad design choice. I'm sure people will adapt though.

yeah, I instantly noticed that on a lot of weapons. It's a bit like the "free-aim" feel that you get in games like Insurgency. Always feels bad.

although it was quickly bought regardless, awesome game!

Just to note for anyone else it appears the demo still uses the pre-release sensitivity

IMO it makes way more sense to use the vertical FOV at all times. This is because the standard convention now is to use Hor+ FOV scaling in games, meaning no matter what aspect ratio you choose, the vertical FOV stays the same. It doesn't make sense to be changing your sensitivity just because you got a wider monitor - think about this, let's say some company brought out a huge wrap-around monitor that curved around you 90 degrees each side. Would you then want to increase your sens for aiming at targets in the centre drastically due to the now extremely high horizontal FOV value? Of course not, you'd want it not affected in the slightest.

This is really nothing new. The "soldier zoom sensitivity" multiplier has always been a global camera function scaler and not actually related to any input device since BF4 when it was introduced - i.e so also in BF1 / V. If you go in those game's options menu, you will see this option affects all input devices and this is fine since no one is using both controller and mouse simultaneously for infantry gameplay. Creating a separate function for something that could not be used at the same time as another input device anyway and fundamentally does the same thing is what people seem to be requesting here, but this would be extremely bad programming practice. 2042 has a poor UI in many ways, but putting options in multiple places where relevant is actually good UX design so the user does not have to menu hop to find all options relating to how their input feels. The ADS FOV option was also present in the controller menu for example, but it is clearly not a controller-only setting since it's a graphical FOV change and not related to input devices per se. What no one seems to be wondering is why a kb & m infantry player is in the controller menu changing the soldier zoom sensitivity in the first place, besides looking for problems that don't exist. This is also the same UI approach taken by such games as Call of Duty ever since the excellent Beenox handled the ports. You can find "motion blur" in both graphics menu and accessibility menu but there's not two different motion blur functions, it's just shown in two different places where it is relevant for convenience. To be honest, I am absolutely astonished this confuses people, but there you go. The reason 2042 feels bad is due to the high and widely variable latency each frame which is a core render pipeline problem that will probably never get fixed. Since we interface with games through our input devices though, people will say there is "something wrong with the sensitivity / input", but that's like having a flat tyre and saying there is something wrong with the engine because the car won't go as fast - it doesn't actually help fix the root cause.

If you want to maintain focal length (0%) scale on both axes when using a stretched resolution you can just use a different vertical sensitivity. if you play 4:3 stretched on a 16:9 screen, then the horizontal tracking sensitivity is faster within screen space by the ratio of “stretch” (in this case 1.333). So you’d just increase the vertical sensitivity by that ratio to compensate. If a game doesn’t have the option and your mouse driver doesn’t either, you can use Rawaccel to do this without issue.

The coefficient is already a multiplier. if you set scaling to 0% in an options menu, and then scale up the global ADS sens by a fixed linear percentage, it is no longer 0% scaling. What you are describing is effectively another variable coefficient to the one I describe in the other thread, but inversely. If we take your example of an added fixed linear 1.06x multiplier to 0% scaling, then it would begin as equivalent to a high monitor distance for low zooms, and as zoom increases this added multiplier to the 0% scale would become less dominant, and it would get closer and closer to 0% (probably around 40% for the actual zoom amounts that exist in games). This would definitely be the wrong way around for my preference, but clearly is the right way around for you. Although, I would go a step further and say this approach has potentially an “objective” (using the term loosely) flaw, in that for a very low zoom, such as one that would result in a multiplier of say 0.96x with 0% scaling, if you then scale up by a fixed linear multiplier of 1.06x on top then your ADS sens ends up being faster than hipfire sens even though the FOV has reduced. In other words, there would have to be sensibly low multiplier values and a minimum zoom level for it to apply and be logical. Even then, low / medium zooms would still likely have a monitor distance far out of screen space even with e.g only a 1.1x multiplier etc. That’s not to say it’s wrong for you to prefer a faster aiming sensitivity than hipfire, it’s just that it’s not really logical IMO.

Like I said in the dm you sent me, it's pixel ratio. A formula to work this out was kindly posted by Drimzi here:

This was actually a really good point, so I went ahead and amended a version that uses the zoom ratio instead. As I mentioned this will maintain the same scaling as per actual zoom vs just the ratio of FOV change, which I guess may be more intuitive if you play games with different base hipfire FOV's. https://www.desmos.com/calculator/yfn7lpyfbf This would then scale slightly more aggressively towards the limit with the same parameters set, but you could increase the power to compensate to create similar results to what you had, whilst now maintaining that relationship for zoom amount on different hipfire FOVs.

Well, yes and no. The starting hipfire value does not change how it scales when the target zoom FOV is the same ratio away from it. zooming from 90 to 45, yields the same scaling as zooming from 70 to 35, or 60 to 30 etc for any values you select, because all FOV's in this example are being reduced by half. You'll notice this is not the same as "zoom amount" though (which is focal length change). This is because reducing the starting hipfire vFOV reduces the change of zoom ratio when the numerical ratio of the target FOV is the same. 90 to 45 is 2.41x zoom, but 60 to 30 is 2.15x zoom. So you may indeed have a different preference. Now I think about this, the calculation within the coefficient could change to the zoom ratio instead which would mean that the opposite occurs - the scaling would be consistent on zoom amount regardless of hipfire FOV, but not by the ratio of FOV change. So instead of: monitor distance coefficient = Limit * (1-(ZoomFOV/HipFov))^power it would be: monitor distance coefficient = Limit * (1-(tan(ZoomFOV/2)/tan(HipFov/2))^power For what it's worth I always use a hip vFOV of about 84 where available. I would never use this as a way to scale hipfire between games, only for ADS / zoom changes within a game where I have set the base FOV I prefer. Graphing like this is also slightly misleading visually since they all seem to converge to zero, when in fact the ratio between the calculated sensitivities of focal length vs any monitor distance is larger at the highest zooms, not smaller. The values are just an example, you can enter whatever you want. 100 vertical FOV is pretty high though.

You can just divide any base hipfire 360 distance by the graph calculated "zoom sens multi" to arrive at that for any target FOV and configured variables, if you wanted to calculate by 360 distance instead of monitor distance. afaik the calculator here doesn't support a method where the user could tune 3 variables for a scaling method (although perhaps only 2 are needed; cap could be omitted most likely), so it would be a case of hard-coding specific parameters that make sense (of which I would suggest both Limit and Power set to 2) but the intent is really for the user to find their own preferences by feel, and "map" those closely via the coefficient curve that they can then use again in the future as a shortcut, as it is clear you have done. My own preference of limit 1.5, power 2, just so happens to be extremely close to where I set all the BF4 / BF1 scopes by feel that I am extremely used to, so this then functions as a barometer for me with at least slightly more logic than just "set everything by feel", which is of course also a valid approach but hardly the target user of this website