Skwuruhl

I just used cheat engine to set sensitivity to your given value and used AHK to verify it took exactly 12345 counts to do a 360. This persists between restarts but will get reverted if you change settings, just opening them doesn't do anything. This applies to any settings, even graphical options. Be sure to use the disabled anti-cheat version if you do this. Unfortunately FOV is stored as an integer so it can't be edited with decimals using this method. In any case the calculator could benefit from a memory editor mode for MCC (as could BL3 btw, it's also possible there)

Can you add the other weapons besides just pistol 2x DMR Needle rifle Sniper etc.

Back when I was testing it in deep rock galactic I was able to somewhat reproduce it with the following AHK script: #NoEnv #MaxHotkeysPerInterval 99000000 #HotkeyInterval 99000000 #KeyHistory 0 ListLines Off Process, Priority, , H SetBatchLines, -1 SetKeyDelay, -1, -1 SetMouseDelay, -1 SetDefaultMouseSpeed, 0 SetWinDelay, -1 SetControlDelay, -1 SendMode Input SetWorkingDir %A_ScriptDir% pixels := 30 * 800 / 2.54 steps := 1000 pixels := Round(pixels) stepSize := Round(pixels / steps) steps := Ceil(pixels / stepSize) - 1 lastStep := pixels - steps * stepSize End:: t := 0 while t < steps { t++ DllCall("mouse_event", "UInt", 0x0001, "UInt", stepSize, "UInt", 0) DllCall("Sleep", UInt, 1) } DllCall("mouse_event", "UInt", 0x0001, "UInt", lastStep, "UInt", 0) KeyWait, End Return Numpad0:: DllCall("mouse_event", "UInt", 0x0001, "UInt", pixels, "UInt", 0) KeyWait, Numpad0 Return Numpad2:: DllCall("mouse_event", "UInt", 0x0001, "UInt", 0, "UInt", pixels) KeyWait, Numpad2 Return NumpadAdd:: pixels++ DllCall("mouse_event", "UInt", 0x0001, "UInt", pixels, "UInt", 0) KeyWait, NumpadAdd Return NumpadSub:: pixels-- DllCall("mouse_event", "UInt", 0x0001, "UInt", pixels, "UInt", 0) KeyWait, NumpadSub Return NumpadEnter:: MsgBox, %pixels% KeyWait NumpadEnter Return Home::Reload pixels is the number of steps to turn to the right, steps is how many "chunks" you want the turn divided into. So in this case it divides the turn into 1000 steps. End to run the script. DllCall("Sleep", UInt, 1) is more accurate that AHK's default sleep and is able to get closer to 1ms delay so it simulates high polling rate mice better.

This is from mouse smoothing. Deep rock galactic had the same exact issue until the devs added a toggle to options from my bug report. I believe the config entry to fix remove it is: [Engine.PlayerInput] bEnableMouseSmoothing=false In Input.ini Possibly also bViewAccelerationEnabled=false but I don't know if it actually does anything or not.

Game has no anti-cheat It's a minor effect but I noticed if I do many rotations then I'll end up over/undershooting almost at random. I can't tell if it is actually random or linked to the sway but I think it might be.

I was able to edit sensitivity successfully using cheat engine (including decimal places). Use cheat engine to search for a float. The value you search for is 10% of the value you have the slider set to. e.g.: Set slider to 10 Search for 1 Set slider to 7 Search for 0.7 etc. Once you've found the addresses set them using the equation 360 / (desired counts per 360) / (0.07 * FOV / 90) Or alternatively 360 / ((desired cm/360) * DPI / 2.54) / (0.07 * FOV / 90) Edit: horizontal sensitivity changes if you're aimed too far upward.

Yeah I had a lot of issues trying to find any kind of consistent scaling. I don't know if it's just coincidence from the scopes I checked but listed scope power (e.g. 5.5x zoom) is approximately the proper zoom amount (e.g. the image on screen actually gets approximately 5.5 times larger). It's hard to tell exactly because the scope moves around while in ADS. This makes the ADS sensitivity scaling so oddly even more difficult to understand since they seem to grasp the proper concept of zoom ratio. I doubt it's related to viewspeed since that's a mathematically nonsensical method (then again the borderlands scaling seems to be nonsensical too so who knows). Edit: ADS sensitivity may change based on scope sway. This could be a compensation thing where fighting the sway doesn't mess with your crosshair placement, or it could be a bug. It's hard to tell.

Okay so two things: I found that using the same vertical sensitivity as horizontal gives equal x/y sensitivity in terms of cm/360. The camera appears to be slightly behind the point of rotation. The camera is still at a fixed height so it won't move vertically if you aim vertically. But looking left and right will move the camera on the horizontal plane. 2 likely accounts for the 10% discrepancy you found between horizontal and vertical. Since this is pretty odd I don't know what the "best" way to match your vertical and horizontal sensitivity would be from an aiming perspective. cm/360 at least is just same for both.

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.

@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.

Yeah it's different too Edit: I think? by script it's the same but it doesn't feel like it.

Sensitivity is affected by polling rate.

No game where aiming is important enough to need the accuracy 6/11 doesn't have raw input these days. Using 4/11 so desktop and in-game feel closer is perfectly fine.

As a temporary fix use the config setting of the calculator with a mouse sensitivity of 40 instead of 1 and then multiply the value by 0.82 before you put it into your config. Use the value for Aiming and zoom, imo also flight and swimming, then adjust zoom/flight/swimming from there as preference. They made the cm/360 between first person and javelin a lot closer (though again jav is still broken)

1st person sensitivity seems to have changed with GstInput.MouseSensitivity 40, seems to be about 25% faster. Negative acceleration on fast swipes seems be better but javelin sensitivity is still broken. Also changing GstInput.MouseSensitivity to 1 no longer changes sensitivity by a factor of 40 but something else (if it changes it at all)

Okay so the 3 flight settings: Sensitivity controls how quickly the flight cursor moves. Pretty obvious. Precision makes it so if you move your mouse slowly then the sensitivity is lowered further. Basically a mouse acceleration curve. Response I think adjusts how sharp you turn when moving the cursor. So say you move the cursor 50 pixels to the right and keep it there. Response controls how much you'll turn while the cursor is at that position.

Set all your sensitivities to the new value in the config GstInput.DylanOption_MouseFlightSensitivity GstInput.DylanOption_MouseSwimSensitivity GstInput.MouseAimSensitivity GstInput.MouseZoomedSensitivity I also personally found 0% flight/swim precision to feel the best for flying.

The calculated sensitivity still works however. Also is it GstInput.MouseSensitivity 1 specifically that removes acceleration or would a lower value of say, 0.2 remove even more?

I think the mouse is mapped to a joystick. I couldn't get any artificial mouse inputs to work and there's a minimum and maximum speed you can turn... just like a joystick.

Sensitivity is affected by WPS. Also kind of a general WPS thing, but WPS has an additional multiplier if you have size scaling on. e.g. if you use 125% scaling on a 1440p monitor so everything isn't so small then a WPS multiplier of 1.25 is added in addition to the usual WPS setting.

The potentially complicated bit will be the swapped endianness unless you already have that coded. But yeah a minimum sensitivity of 9.47 in OW or 2.84 in CS:GO is ridiculous. Especially when the maximum is the equivalent of 114 and 34 respectively.

So just a reminder that FOV and sensitivity can be set via registry. The conversions are a bit complicated but I've figured them out. Again 0% is 5760 counts and 100% is 480 counts. The config is located in Computer\HKEY_CURRENT_USER\Software\SKS\TheForest The complicated part is converting your desired sensitivity to the format used in the config (little-endian double). So for example say you want 1.5% (0.015) sensitivity in-game. First you need to convert this to it's double binary representation, in this case 00111111 10001110 10111000 01010001 11101011 10000101 00011110 10111000 Then you need to convert this to hex 3F8EB851EB851EB8 But this is big endian so you need to swap it to little endian. Split each pair of numbers and then reverse the order 3F 8E B8 51 EB 85 1E B8 to B8 1E 85 EB 51 B8 8E 3F This is finally what you input in MouseSensitivity_numbers and MouseSensitivityY_numbers. FOV is done the same way. Negative sensitivity values get defaulted back to 0 and don't work unfortunately. If you use python scripts on this website then this could help: import struct input = 0.015 def double_to_hex(f): return hex(struct.unpack('<Q', struct.pack('>d', f))[0]) output = double_to_hex(input)[2:].zfill(16) x = 2 for i in range(0,16): output = output[:x] + ' ' + output[x:] x += 3 print(output.upper()) For anyone wanting to do sensitivity themselves in the meantime use this equation: (5760/desiredCountsPer360-1)/11 to calculate an input value for the python script. Then type the output into the registry fields (be sure to get the x and y fields). If you're doing FOV you just put the desired vertical FOV in the input variable.

Using 0% monitor distance. Something isn't right here.

There's a person I've had discussions with that advocates discarding match distance entirely and instead scaling based on focal length entirely with a multiplier. I can't say I really disagree with him entirely. It's definitely way more sound than "viewspeed" or whatever else. And the concept of "match distance" has a lot of significant flaws, largely that it completely falls apart if you're aiming up or down from the horizontal at all. The new equation would just be tan(zoomFOV/2)/tan(hipFOV/2) * Coefficient For example CS:GO's default multiplier in AWP zoom 1 is 4/9ths with a zoom of ~2.75x. This means that the coefficient in this case is 1.2211. If you used this to convert to Overwatch your Widow/Ana sensitivity would be 46.27 (zoom scaling * 1.2211). There are 2 issues I have with this method, the first is that say you have a scope with 1.1x zoom. If you used a 1.2211 coefficient with this zoom level then your ADS sensitivity would be higher than hipfire resulting in a reduced cm/360 distance which just... doesn't make sense to me. However this could be okay, the way our brains perceive sensitivity is complicated. The second is that this doesn't really provide a way to scale between hipfires if the FOV is different other than "scale by focal length with no coefficient" or "scale by 360 distance". This also could be fine as scaling hipfire by just focal length is a decent solution. Both of these could be "solved" completely if you scaled the coefficient by focal length in some form but I don't know that that's necessarily a good idea or that it'd actually be solving anything. The benefits are that your sensitivity is more grounded in the actual zoom ratio which is good. Also it "solves" people who prefer a sensitivity lower than what 0% match distance would provide. Match distance has no answer for people who use 35 widow/ana sensitivity while this method does (0.9237 coefficient).

Match distance isn't "accurate within a circle." Any match distance will only be perfectly matched at that specific distance and just get more and more off the further you are from it, whether it's more inside or outside. However distance match only works when you're starting at 0° horizontal. I.e. if you're aiming up or down at all, even a little bit, then the concept of a distance being matched stops working entirely. The big reason to use "0% distance" is that it's actually scaling by zoom ratio aka focal length. This is desirable most obviously because you're, well... scaling by the zoom. 2x zoom means 1/2 sensitivity. A secondary reason this is desirable is that this mimics how your brain automatically scales aiming based on distance from target. E.g. if a target moves from 100 meters to 50 meters then you have to move your mouse 2x the distance to stay on target. The target will also appear 2x as large since it's half the distance away (kind of like 2x zoom).