Jump to content


Premium Members
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Skwuruhl

  1. Yeah it's different too Edit: I think? by script it's the same but it doesn't feel like it.
  2. Sensitivity is affected by polling rate.
  3. 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.
  4. 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)
  5. 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)
  6. 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.
  7. 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.
  8. 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?
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. Using 0% monitor distance. Something isn't right here.
  14. 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).
  15. 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).
  16. If you want 172.8% vertical match then just use 172.8% for the mod. I do wonder how you arrived at this exact % though.
  17. Virtually none. CoD used to (I think, but you can still use 0% if you want) and Titanfall 2 does if you don't change the FOV. Most games just do zoomedFOV/unzoomedFOV if that. Similarly in most games a 3x scope will just be fov/3 instead of 2*arctan(tan(fov/2)/3)).
  18. Unlikely. All my mods are based on decompiled source code and I don't think such a thing is available for cod 2. Also I doubt an existing mod framework exists for cod2 which means I'd have to write my own hook etc. And I mean even if all this stuff was available... it's more than a decade old, not really worth the effort. I mean co-op PVE games are currently a pretty limited genre. PD2, KF2, and Verm 2 are pretty much the only ones. There's deep rock galactic and GTFO coming though.
  19. So to rewrite what you're doing: Which is the same as This is just (vertical match multiplier) * (horizontal match multiplier) Honestly it feels like half of these threads are just throwing numbers at each other hoping something usable comes out of it. Viewspeed is the worst about this imo.
  20. A mod I made that allows you to customize zoom sensitivity recently got approved for official realm. By default the mod makes zoom sensitivity scale with focal length/zoom ratio but you can change it to scale by a custom FOV aspect ratio (aka monitor distance). The game uses vertical FOV to scale by default. https://steamcommunity.com/sharedfiles/filedetails/?id=1498189723 Unrelated to sensitivity but using the same math I also made a mod that fixes crosshairs: https://steamcommunity.com/sharedfiles/filedetails/?id=1569650837
  21. Ashe FOV isn't 66, (for horizontal it's more closely 65.8 but it's not exactly that either) In fact Widowmaker/Ana FOV aren't 51. It's actually 40° vertical and 30° vertical respectively. See: https://www.reddit.com/r/Competitiveoverwatch/comments/9ui5hv/ashe_fov_is_66_and_11_relative_sens_is_about_515/e95c2kj/?context=3 and https://www.reddit.com/r/Competitiveoverwatch/comments/9ujb0i/widowmakers_and_anas_fov_has_changed/
  22. 1 count is 1 pixel is dependent on the location on the screen. For the center of the screen it's unsurprisingly match distance for 1/960th of the screen (for a 1080p monitor). However for the edge of the screen it's a bit more complicated. The equation I'm using is (arctan(1/960*4/3*tan(90*pi/360))*180/pi-arctan(0/960*4/3*tan(90*pi/360))*180/pi)/.022 Which is basically (1st pixel's degrees away from 0th pixel)/m_yaw (counting pixels from the center of the screen) To get the multiplier m_yaw needs so that 1 count is equal to that number of degrees. So CS:GO http://www.wolframalpha.com/input/?i=(arctan(1%2F960*4%2F3*tan(90*pi%2F360))*180%2Fpi-arctan(0%2F960*4%2F3*tan(90*pi%2F360))*180%2Fpi)%2F.022 3.61716 sensitivity But for pixels at the far right of the screen (960th pixel's degrees away from 959th pixel)/m_yaw (counting pixels from the center of the screen) which is (arctan(960/960*4/3*tan(90*pi/360))*180/pi-arctan(959/960*4/3*tan(90*pi/360))*180/pi)/.022 http://www.wolframalpha.com/input/?i=(arctan(960%2F960*4%2F3*tan(90*pi%2F360))*180%2Fpi-arctan(959%2F960*4%2F3*tan(90*pi%2F360))*180%2Fpi)%2F.022 1.30305 sensitivity If you apply this to AWP Zoom 1 the sensitivity multiplier would be 0.817919 (when the default is 0.444444) for a horizontal match distance of ~621%. Unless I made a mistake in my equation, you probably shouldn't set your sensitivity based on 1 pixel per 1 degree at the edge of the screen or really any part at all. (worth nothing that a pixel is a completely arbitrary unit of measurement and has no direct link to perceivable skipping).
  23. Reminder that viewspeed is which makes literally 0 mathematical sense
  24. Completely overhauled version of the mod that gives customization to zoom sensitivity via monitor distance or zoom ratio. https://steamcommunity.com/sharedfiles/filedetails/?id=1498189723
  • Create New...