Vaccaria

You have windowed mode, windowed mode has a resolution, what resolution are you using? What is the monitor size and native resolution? Do you use windowed mode in other games? example:

These are not constants, these values will be different as they use centimeter in the formula. For example, these are the values I got in CoD:MW Jedi's Tick - Horizontal ≈ 107%MDV, 60%MDH; 107*(9/16)=60.1875%MDH Jedi's Tick - Vertical ≈ 68%MDV, 38%MDH; 68*(9/16)=38.25%MDH

What I don't understand is when a person tries to point out in words something that only they are experiencing. I've done some tests of what you pointed out. I got a match. I also know the reasons for the CPI inconsistency on the mouse, i.e. lack of consistency. \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ 4.17*100=417 px The cursor started and ended the movement of the active are - That means the math works. \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ You want to know how many pixels you can get through at 216 mm. so: 216/25.4=8.50393700787*800=6803.1496063 px - We multiplied the distance by CPI, we got a value, let's understand it as px. Since CPI are counts, they can be tied to anything, in the case of a monitor, they are tied to resolution, i.e. px. >>> 6803.1496063/1920=3.54330708661 - We found how many can fit 1920 px on this area.

Variables: 1) Active Area is the mouse pad - 216x135 mm. 2) Relative Mode is the same DPI, but in a different form - 800 DPI. 3) Screen Resolution - FHD: 1920x1080. 4) Field of view in the game - Overwatch, 103 Hdeg 16:9. 5) Game sensitivity multiplier - Overwatch, 6%. First we need to find out what kind of 800 DPI is in OTD. 1 inch = 2.54 cm = 25.4 mm. 800/25.4=31.496062992125985 X'Y sensitivity in OTD. If we want to have edge-to-edge desktop resolution in the active area, then: (1920/(216/25.4))/25.4=8.8888888888888 X in OTD or (1080/(135/25.4))/25.4=8 Y in OTD. If you don't use a different X'Y DPI, you need to have a single X'Y multiplier in OTD. You can use inches for calculation. The workings of the variables field of view, screen resolution, and sensitivity multiplier in the game, can be seen here. Sensitivity 1: Sensitivity 6% 360° Distance: 28.8636 centimeters Pixel ratio: 0.5278 pixels/count

Yesterday I realized that the lock on X'Y is a coefficient of "1" between distance on 360 under any FOV. When we use the % scaling calculator, this lock always works, so we choose to scale either X or Y. We can currently use tools from the game itself, in the form of unlock the X'Y lock, or third party tools like rawaccel. In rawaccel there is a Y Range, it gives a different feel to changing Y, I have not seen this type of Y change in the game yet. Here we unlock the lock under hipfire, we did scaling, we have changed the Y coefficient, it became higher than "1". This coefficient above "1" will work over a 360 distance for ADS and Scope, even when we choose to scale for ADS, Scope either X or Y. What we need to do is to reduce the coefficient, make it lower than "1". And since the coefficient above "1" is the coefficient that will always be there, if set same scaling method for Hipfire, ADS, Scope, e.g. only X, then like when we lock to X'Y, it is the same, it means that it also keeps the scale as "1" for 360 distance, and this does not give a percentage match on the monitor, because the monitors have aspect ratios, e.g. 16:9. And with that in mind, vertical scaling looks like the best fit for the X'Y lock(Of course, I'm not writing about 0% here, since using a stretched res for any aspect ratio, will give a different sens multiplier for X'Y, 0% takes this into account, by setting the multiplier for Y in rawaccel, we will get a coefficient, it will the same for both the sens multipliers and the 360 distance coefficient between Hipfire, ADS, Scope).

Apparently the person wants to get the Y string for rawaccel in the output for the game, when using split X'Y, since not all games have the ability to change Y. There are two options: 1) Use X'Y Ratio(in the image above, he indicated ) 2) Use Y Range (TheNoobPolice here explained how to do the other option) Only as you said it will only work for Hipfire, for ADS and Scope the vertical multiplier will be different. So 0% of 2D is most effective:) With him there is no reason to do that.

/// 1800 dpi sensitivity "0.568889" zoom_sensitivity_ratio_mouse "1.000000" (Zoomed: AUG, SG 553) zoom_sensitivity_ratio_mouse "1.000000" (Zoomed 1: AWP, SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "1.000000" (Zoomed 2: SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "1.000000" (Zoomed 2: AWP) or zoom_sensitivity_ratio_mouse "1.088317" (Zoomed: AUG, SG 553) zoom_sensitivity_ratio_mouse "1.096285" (Zoomed 1: AWP, SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "1.124343" (Zoomed 2: SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "1.127085" (Zoomed 2: AWP) /// 1600 dpi sensitivity "0.755628" zoom_sensitivity_ratio_mouse "1.088317" (Zoomed: AUG, SG 553) zoom_sensitivity_ratio_mouse "1.096286" (Zoomed 1: AWP, SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "1.124343" (Zoomed 2: SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "1.127085" (Zoomed 2: AWP) /// 1600 dpi sensitivity "0.853333" zoom_sensitivity_ratio_mouse "0.963707" (Zoomed: AUG, SG 553) zoom_sensitivity_ratio_mouse "0.970763" (Zoomed 1: AWP, SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "0.995608" (Zoomed 2: SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "0.998036" (Zoomed 2: AWP) or zoom_sensitivity_ratio_mouse "1.088317" (Zoomed: AUG, SG 553) zoom_sensitivity_ratio_mouse "1.096285" (Zoomed 1: AWP, SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "1.124343" (Zoomed 2: SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "1.127085" (Zoomed 2: AWP) /// 1355 dpi sensitivity "0.755628" zoom_sensitivity_ratio_mouse "1.088317" (Zoomed: AUG, SG 553) zoom_sensitivity_ratio_mouse "1.096286" (Zoomed 1: AWP, SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "1.124343" (Zoomed 2: SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "1.127085" (Zoomed 2: AWP) /// 1200 dpi sensitivity "0.853333" zoom_sensitivity_ratio_mouse "0.963707" (Zoomed: AUG, SG 553) zoom_sensitivity_ratio_mouse "0.970763" (Zoomed 1: AWP, SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "0.995608" (Zoomed 2: SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "0.998036" (Zoomed 2: AWP) or zoom_sensitivity_ratio_mouse "1.088317" (Zoomed: AUG, SG 553) zoom_sensitivity_ratio_mouse "1.096285" (Zoomed 1: AWP, SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "1.124343" (Zoomed 2: SSG 08, G3SG1, SCAR-20) zoom_sensitivity_ratio_mouse "1.127085" (Zoomed 2: AWP) /// I have no idea which option is right for you. You can't get rid of the slowness of character movement at 16.9. You can only change Pixel ratio(mp and dpi)(res).

Your settings sens?

Osu vs McOsu and the impact on conversion from Hipfire to ADS, Scope. At the very beginning of the study, I used native osu. McOsu I used as 3D, with a native square osu. Since I used native osu, the area of note appearance has a square. By moving the pointer over the square area each time, I arrived at the method: MDH 60% from Hipfire to ADS, Scope. When I moved to McOsu to test the full screen format instead of the square, I continued to use MDH 60%. I didn't even have any doubt that MDH 60% was the most effective. Not long ago I came across questions, topics, discussions about 100%MDH, and it prompted me to double-check this method, because past experience is past experience, because as soon as you think, there is, found - you start to die. /// When I started running tests with MDH 100%, my confidence was shaken, I immediately realized what was wrong. Square is MDH 60%, but when fullscreen it is MDH 100%. From here we get the following data: 1) Native osu is 0-60%, maybe someone will have 100%, but according to my data 60% is most effective. 2) Fullscreen McOsu is 60-100%, yes, can use 60%, 90%, 98.434389% or any other value to address any shortcomings you may personally have. But for the sake of understanding, let's take 100% as a base. How to make full screen mode: Need 3 commands, I don't know how these values will display on other monitors, my values are as follows: osu_playfield_stretch_x 0.5 osu_playfield_border_bottom_percent 0.112 osu_playfield_border_top_percent 0.112 1) Manually enter one command each time you run McOsu. The key combination to open cmd is "Shift+F1" or 2) Enter these lines in the file "osu.cfg" in the path "*\SteamLibrary\steamapps\common\McOsu\cfg" /// The images show the value of the size of the circles(cs 0). The higher the cs, the more the area is narrowed. This is the mechanics of cs, there is no way around it. Therefore, at the usual values of 4-6 cs, the area will be narrowed. Comparison of area: Native area in osu(cs 0) Fullscreen(cs 0) What does cs 4 look like with fullscreen. Or Here are more fullscreen for specific cs values: cs 2 osu_playfield_stretch_x 0.471 osu_playfield_border_bottom_percent 0.097 osu_playfield_border_top_percent 0.097 cs 4 osu_playfield_stretch_x 0.446 osu_playfield_border_bottom_percent 0.081 osu_playfield_border_top_percent 0.081 cs 5 osu_playfield_stretch_x 0.432 osu_playfield_border_bottom_percent 0.073 osu_playfield_border_top_percent 0.073 cs 6 osu_playfield_stretch_x 0.418 osu_playfield_border_bottom_percent 0.064 osu_playfield_border_top_percent 0.063 I check the values in photoshop to make sure the lines are the same from the edges. /// Well, another confirmation that the same method shows different effectiveness when the environment changes. This means that you should choose methods by studying your own environment of training, playing games or whatever else you do with your PC:) Let's take The Finals game as an example, the calculator shows limit of MDV 100%, i.e. in the game cannot be set higher than this value. The environment limits by imposing restrictions. Playing native osu, you will be changed by the osu environment as there is no way to change the area. /// That's all for now. Tag solution On topic, this is: Click Click together with Click Click other posts additional information

@Aim DASH 1) I don't play games. 2) If talking about OW, I use 103. If talking about WoT, I use 100. WoT was my main game, and OW has a feature set for testing. But I don't play games anymore:) 3) I will explain the impact through numbers in a calculator. If I start explaining about how FoV affects visual response, since the eyes are receptors, I might fail. And that's just the word FoV, but there are objects in the game, the distance of your eyes to the monitor screen, the size of the monitor screen, your ergonomics in your chair, your visual acuity, glasses with or without diopter and etc. etc. etc. First step: FoV affects the 360° Distance for hipfire(different multiplier) and the Pixel ratio: 103: 90: Second step: With different FoV for hipfire(different multiplier) there will be different multiplier values when scaling for ADS, Scope. And this will already affect the shooting. Yes, will adapt to it, there will be no difference for brain. But these methods affect the principle of shooting differently. 103: 90: There is no right or wrong here. You can try all of these, record the results, analyze the results and decide which FoV is the most effective for you. Another condition is that not all games have a high FoV, not all games can change FoV. So you don't need to fixate on specific values. I'm going to take it out of context a little bit and steal the words: /// If there are any more questions, ask. ///

You are right. The new version really has all the features I need. But where I live, banks are disconnected from SWIFT. So I can't pay directly. Since I tried it and collected data that I tried to analyze afterwards, I understand what you wrote about. That's awesome. Data input has become very consecutive. Something like this was consistent with angle-snapping "6", but the quality is much different. Also with angle-snapping I felt the square on the monitor, which was able to show effectiveness in osu, only in osu(2D)... In 3D the square helped with stability, it helped with input consistency, but that's something I was able to notice right away as the process of comparing between A and B was underway. But when I compared Anisotropy and Angle-snapping, all my reasoning about why I feel that consistency (crosshair stability) at certain angles immediately became clear in the form of math. Thank you @TheNoobPolice

There was another function that came to my attention. "Angle snapping" Considering what I encountered and came to rotate the sensor, angle snapping gives a noticeable result in 3D along with sensor rotation. If remove the sensor rotation to 0(I have that, as 0 gives me a strong bias relative to -5), the value in angle snapping goes up. This means that the efficiency goes down. Hence. First of all, need to determine the sensor rotation angle (ex. 5, 0, -5, etc., etc.), and after all the long tests, should move to the angle snapping. By doing this, the value of the angle binding will be less, which will increase the efficiency. This may not be useful to some people, but for me, it's a useful feature. It can also be useful in 1-2-3 degrees, i.e. small values, as a kind of helper. I'm using 20k dpi, I need 508 dpi. That's why the "Sensitivity multiplier" is like this. Raw Accel - settings.json. 3D, vertical multiplier for OW "Sensitivity multiplier": 0.0254, "Y/X sensitivity ratio (vertical sens multiplier)": 1.42486085343, "L/R sensitivity ratio (left sens multiplier)": 1.0, "U/D sensitivity ratio (up sens multiplier)": 1.0, "Degrees of rotation": -5.0, "Degrees of angle snapping": 6.0, (search process) "Input Speed Cap": 0.0 2D, non 3D games "Sensitivity multiplier": 0.0254, "Y/X sensitivity ratio (vertical sens multiplier)": 1.0, "L/R sensitivity ratio (left sens multiplier)": 1.0, "U/D sensitivity ratio (up sens multiplier)": 1.0, "Degrees of rotation": -5.0, "Degrees of angle snapping": 6.0, (search process) "Input Speed Cap": 0.0 I have the sensor turned to -5, which is pretty significant. When I increase Y, it also gives less stability, but when I add an angle snapping - I'm getting stability. end

Have you tried the experiment on linux? For example, in the latest versions of Mint there is an option to disable mouse acceleration in the settings, when I started using Mint there was no such option. Need to define the scope of your search rather than immediately burying yourself in the depths of windows. As one example, I remember Logitech had a lag issue on wireless devices with close proximity to a wifi device, but this problem was not with Razer. The problem itself, the person solved by replacing the mouse, but was initially trying to dig deeper. Any suggestion can be discussed and a solution can be reached. The USB itself contains a lot of things. It is a physical port (mom, dad) which is soldered to tracks in the layers of the motherboard, these tracks go to the chipset, the chipset itself is blah blah, etc. Which means if dig deep, need to know what to look for. The data you provided can be interpreted as another type of information, the first type is what we capture with our eyes, the cursor is drifting. You were able to learn from the machine how it reads the signal. But there are many more variables in the depths, and only a limited number of people can know them. I don't know. I can suggest an idea, test it in Linux.

I got the data after comparing two Y: "1" and "custom". With a multiplier of "custom" the vertical and diagonal tracking distance is more "comfortable" for the forearm and fingers. With a multiplier of "1" the "comfort" distance is shortened, so the forearm is more active in moving and taking the load, and the fingers are used in less area. The more vertical and diagonal distance required, the better the performance of the "custom" multiplier will be. At multiplier "1" the movement becomes 1:1, thus vertical and diagonal tracking becomes more labor intensive, but there is stability in the form of "flick" movement on short vertical, diagonal area, long horizontal movements at sharp angles. When the multiplier is "custom" with "flick" movement on a larger vertical, diagonal area, long horizontal movements at less acute angles. In other words. The image depicts figures, dimensions are a convention and should be interprised as for clarity. Y - custom Y 1 - lock X & Y Yellow rectangle - area of forearm. Green square - area of fingers. With multiplier "1" on one green square the fingers show more stable flick, forearm the same. At two squares the forearm is connected, fingers work only at one square. The forearm performs a more stable flick with a long movement and a sharp angle. With the "custom" multiplier on two green squares the fingers show a more stable flick than with one square, but that doesn't mean that the difference can reach several times. It is there, it can be felt when moving, that's what I recorded. There are difficulties when trying to make a long forearm movement with an acute angle, but these difficulties are not present if you make a more diagonal movement, i.e. with a less acute angle. 3D to Osu With a multiplier of "1" when playing osu, the forearm is used more than the fingers. With a multiplier of "custom" when playing osu, the fingers are used more than the forearm. That is, with different multipliers, the forearm and fingers are used to different degrees relative to each other. If at "1" in 3D we are more active with the forearm, then in Osu will be transferred to the forearm (going the distance). And vice versa in "custom". From here it follows that some games that use more horizontal aiming can form the habit of aiming in this way and no other way, if a person wants to try to use "custom Y", his habit will make itself known. In OW you can aim diagonally and maintain that style. But in Valorant you can't anymore. And that's where "recoil" comes in, so recoil is distance measured. Which means that if I use my fingers for vertical movement, I'm more comfortable controlling most of the recoil with my fingers, and only after I engage my forearm(shoulder). To use "1" or "custom" is a compromise with yourself, i.e. your habits. But to know your habits, you have to try and only then compare: the old experience and the new experience. p.s. Because I tested rotating the sensor, I was able to gather even more data on how I hold and move the mouse. I was able to come up with a more efficient grip. I compared two mice, my last mouse and my current mouse. The shape and grip give differences in sensor rotation, but on my two mice sensor rotation is necessary, on both with sign "-". On the Razer Viper between 2 and 4, this is an approximate range, because by warming up it is possible to reduce the value, if you take an unstretched arm, the value is closer to 4. Also tested the rotation "0" with multipliers Y: "1" and "custom". When rotating the sensor, the performance of "custom" increased dramatically. I have some reasoning as to why mine is the way it is, but I'm not ready to share yet, i.e. the reasoning is not ready. I use 200% MDH(X) and 200% MDV(Y) at FHD/650dpi.

Since I was doing a lot of testing, in my dream I came up with the idea to reduce the DPI to the minimum value, i.e. Viper V2 = 100. It is possible to reduce via the RawAccel multiplier. I decided through DPI. After that I started testing movements through different shapes(symbols etc). After getting the results, I compared them. With different mouse shape, with different palm shape(i.e. all properties are included, ex. size.) Rotating the sensor allows to correct the discrepancy between X and Y. If at "0" there is a perfect vertical line, then at X it can be curved (and the opposite effect), so need to determine the degree of importance of the horizon or vertical line for yourself (what you do, etc.). In my case, turning the sensor to -4 turned both: X'Y and there was no choice between X and Y. I once learned that ergonomic mice physically rotate the sensor relative to the body. And if we take into account how unpopular in discussions "sensor rotation" is, we can assume that people change(create) the mouse shape for mass hand, but do not take into account the location of the sensor in mass hands. We have cyber sports for FPS games, if my hands don't fit a mouse by all properties, but another person's do, then I am at a limited development potential. I was able to come up with the sensor rotation, but here we have LAN tournaments banning any outside software, that means I've reached the limitation again. This is my observation about the competition between people in FPS games. This is just one of many. Here's another one. Adjusting sensitivity in game, I want to control the multiplier under each FOV, but the game has a formula and it scales. So I'm limited again. Games don't separate the multiplier into X and Y, so again I'm limited. Funny observations on how we put our own sticks in our own wheels.

Some remarks for "sensor rotation" I was adjusting the horizon from 1 to 1(X'Y) . When setting Y, the horizon will shift more significantly, so need to change approach to tuning. 1) Adjust the horizon with Y already set. 2) Make side-to-side movements with wrist in a relaxed state, without any horizon projections in head. I experiment a lot, when I turn the sensor around my grip changes, i.e. I am not limited to 0 or 5 in the turn around, the main thing is to gather as much information as possible. Today I have -2, tomorrow it will be -2.5, the day after tomorrow 0. The final decision on the closest value will be made after determining the framework of efficiency - and +. Further interaction with the obtained close number. In the previous screenshots the value is -2.4, the grip changed the value became -2.

Different X'Y will cause the sensor to rotate in relation to the grip. The mouse forms the grip, if you change the sensor rotation through the software, the grip can also change, my fourth finger has taken a position further from the sensor, before it tried to grip so that in osu there was at least some acceptable horizon. I came to the rotate because I was testing different X'Y, in which some phenomena became immediately noticeable. I started the movements from the center to the left. All movements were done with eyes closed. The movements should be similar to Jump's, but with stops at the edges. Muscles should tense at the beginning and relax at the end, i.e. you could say "flick with LMB holding" repeat the motion cycle from side to side about 8-12 lines. When I go into the game, I put Y and the movement on the horizon is now less like a sine wave.

Since I test in games where there is no X'Y separation, I did not pay proper attention to Y. With the horizontal (X) I made a decision. - 200%MDH, it's time for Y - 200%MDV. In osu I use the same X'Y. When I enter the game, I set the multiplier for Y in RawAccel. In Kovaak can set multiplier for Y, but in Kovaak there is no manipulation of the 2D interface, like in the game Rust, so this is the first problem when using RawAccel or software in the mouse. If use the 0%MDV(H) method from 2D, there is no difference in X'Y. And if use percent in any MDV(H) method, there is a difference in X'Y. I've always run into a lack of "Y" because of my fingers, but I always grabbed for X and couldn't switch to Y. With 200%MDH - X, 200%MDV - Y, vertical, diagonal tracking became more accurate, and most importantly, fingers began to actively help, they used to go the distance quickly, and in 3D it was not enough for adjustments, so the shoulder was connected. Different X'Y can be used with the method of Jedi V and 60%MDH (it is slightly more accurate than Jedi H, but also Jedi H fits) Also with 100%MDH and 100%MDV. I'm leaning towards the 200%MDH - X; 200%MDV - V method.

I will allow myself to correct you. As I wrote above, I was not aiming for a result, in osu or any other 3D game. I was looking for a method to use osu as a starting point. Every day to warm up in osu, afterwards to warm up in a 3D game. This can take 1-2 hours as a warm up-workout process. Over time, the brain will get used to any setting. That's why I described what I want to move from osu to 3D. This is the area of "efficient" work. The resulting MDH200% is Hipfire. MDH60% - ADS, Scope. Another example. Since the Jedi method is monitor accurate, I used the calculation for X'Y, but instead of Jedi H, I used MDH60%. With FHD I got a multiplier of 1.08625 between X'Y. I know the X'Y can be adjusted in RawAccel, but I went ahead and gave up on RawAccel. In the Razer only steps at 50, since I was using 600DPI originally, that's where I started. And the result was MDH60% - X:600; Jedi V - Y:650. ADS, Scope - MDH60% And this method works perfectly. And now can compare them, but how? As I wrote, "feeling", at this point I couldn't express it in any other word or method. But it is possible to describe what is meant by the word "feeling. In my post above I touched on this slightly: What I was getting at. When you described which method you use for this, that, etc. Then you backed up your words with the result in osu. But with this DPI and also with FHD, it is not difficult to do "Jump". The movement of the cursor is sensitive. But also do not miss that "Jump", even if they are fast, it is a basic pattern, every beginner, including me(once was) quickly learn to pass the patterns of "Jump". From this it follows: That there is no correlation between 0% and "Jump" in osu. I also gave an example above about collecting data from "pro-players". If a person plays CS:GO and constantly changes the sensitivity, because he does not succeed, and his idols show the result, he copies-copies and so on in a circle. In a conversation with him, I can use this calculator, as well as players "s1mple" "NiKo" "m0NESY" as pressure on his beliefs. s1mple is MDV100%, NiKo is MDH200%, m0NESY is MDH100% and they are all 4:3. And there are many such examples to be made. For example: I have yet to see a single pro player with MDV(H)0% and that means... I think you get the manipulation. That's it. https://www.mouse-sensitivity.com/?share=71a91e57d89bfb358bf1968a732fd991 https://www.mouse-sensitivity.com/?share=d7829230856694875cb4be669aa31a44 https://www.mouse-sensitivity.com/?share=8d35609e8b50059b6247044c2ec64335

It's been a while, maybe even a lot of time. At some point have to finish what started... If collect the data of sensitivity settings from pro-players of any game, then get to form a groups called "the method to which this player approached" Which means 100%MDH, 100%MDV, 200%MDH, etc. Each method works, but I need a method that gives maximum efficiency from Osu to any 3D game. Exactly Osu, not Windows. The movements in Windows and Osu are different is the thesis. I have tried all methods. I collect data, analyze, not have fun with friends or alone in games, my goal is to study. Briefly about how I imagine the Jedi V method works. This method was created for maximum cursor accuracy, going to 3D gives the same accuracy around the crosshair, but in Osu the patterns are not pixel-by-pixel accuracy, which is the pointer control in Windows. In Windows I use micro-correction to hit the X, etc anyway, and I do that with my fingers, but when I go into 3D, the same movements to shoot have to be used, and that is given by a titanic effort, all control goes to the fingers, and it doesn't matter what DPI you use, 200,400,800, etc. You use micro corrections at any DPI. But I can't go in from the other side, as I can't physically take the mouse in my palm, claw or whatever. Which means I only base my grip on a finger grip that involves my forearm and shoulder(600DPI). Several of my mates use this method(because I gave it to them, LOL) they are satisfied, but not me for myself. Conclusion: Works great, but not for Osu. The other methods will not take apart, because they correlate the points on the edges of the monitor, everything is explained in the technical section of the forums. What I arrived at using this site and the excel calculation tools that MacSquirrel_Jedi created. 1) Using MDH 200% for Hipfire. https://www.mouse-sensitivity.com/?share=dfdd6a7f86c7e3beec1a24fe85cf2790 2) Use MDH 60% from Hipfire to ADS, Scope. https://www.mouse-sensitivity.com/?share=6cfc6b711e19e9f183bddf02cca0cb06 Why 200%? - We need distance, not pixel accuracy. The distance here is in the form of centimeters. Why 60%? - In osu there are a lot of horizontal movements that we do not pay attention to, because we do it with the wrist, in the game too the crosshair moves with the wrist and fingers, but if we take 100%, the emphasis is entirely on the wrist, but in osu works and the forearm and shoulder, at what values will not notice the difference in the transition between the shoulder, forearm, wrist, fingers in osu, and then also in 3D? The most accurate averaged points on the horizon are 60%. But accuracy is not enough, because you can also be accurate at 0%. And this is where you have to describe the so-called "feel". If you open two applications and switch between them, there will always be a feeling of slowness or speed of the pointer in osu, 3D. What I mean by that is a change in the use of the hand, if you control the wrist and fingers in osu and if you control the forearm and shoulder in 3D, you immediately sense a change in the pointer (crosshair). From this follows the so-called "confidence" in the movements of the hand and the result on the screen. In Osu we can track (this is the passage of the distance without jerks) and jerks from side to side (on confidence). The same thing needs to be repeated in 3D, but how? We have a target, it moves from side to side, our crosshair doesn't move(no tracking) and here the target moves 50% of the screen from the crosshair, and here 0% fails, the wrist is not enough and there is no confidence in the action. If you use 100%MDH, there is confidence in the flick at the wrist. This is a feature that needs to be disassembled. I disassembled and got 60% MDH. I am also aware that some pro players use -60% for Ashe and 60% on Widow. As I wrote above, this is how they represent the movement of the hand and the result on the screen. All methods work, but not all methods work effectively with Osu. I can only guarantee operability between Osu and the 3D. End.

https://www.mouse-sensitivity.com/?share=beb8225f9b883972f35a0807e9abd178

@DPI Wizard The game came out in steam. In it, can adjust the sensitivity via .json on the path "C:\Users\%username%\AppData\LocalLow\1CGS\Caliber\Settings.json". Calculation: the number from the game divided by 20. Example: 44.1\20=2.205. "Key": "input", "Store": { "MouseSensitivity": { "ValueFloat": 2.205 }, "MouseSensitivitySight": { "ValueFloat": 1.88 }, I also attached screenshots, can you add ".cfg" and recalculate FoV? Considering that even on pistol is different FoV, since I only played 4 operatives, and there are 68 of them in the game, I can presume that this is not the end... So I wrote a proposal to replace the formula for calculating sensitivity in the game. Their calculation formula is a torment for players, people out there don't play Snipers at all and I'm not surprised, even though it doesn't apply to balance.

I got it, thanks!

Yes, that's what I mean. It saves the value without conversion, which means that to do the conversion now have to set 2 games instead of 1. This I'm writing only about WoT. Was it like this in previous versions?

I meant, since "multiplier 1" is locked in this particular game, I could change the zoom by switching and the calculations applied. That doesn't work in OW2, because switching unlocks "multiplier 1".