[CS1.6] small mousemovements doesn't change viewangles

[f4k3]

http://youtu.be/8Z09xvpNQ3E

With low sensitivity small mousemovement to the left doesn't change viewangles. It's really annnoing. Because when you use zoom, effect of that bug in 10 times stronger.

There is bugreport about it, but it specifies that this only happens with double zoom. So it isn't a dupe. And there is no activity about that issue. https://github.com/ValveSoftware/halflife/issues/154

[ghost]

I think it depends on your mouse DPI. My mouse DPI is 1600, and I can't confirm this bug.

[f4k3]

@MaxKorz It isnt dpi depented, it is count dependet, with fov 90 it is -1 count that dropped(you see it in mousemovement recorder -1x0), with fov 10(double zoom) it -4 counts that dropped.

It easier to reproduce with double zoom, set your sens to 0.2, buy awp or scout, double zoom it. And try. Slowly turn to left. Then at the same speed to the right. Also you need to have stable fps. Because mousemovement applied to viewangles each frame. 1000 fps do it more noticeable, but with 100 it will be happen too.

Problem that it isn't noticeable in standard circumstances. If you don't know it. And some people will not notice it but it will affect their aim and accuracy.

in video i was using 3500 dpi, with sens 0.2. but with 400 dpi it will be more noticeably even with sensitivity 1.

[ghost]

Sorry, I can't confirm it with dpi 800, 1600, 2000. Video http://youtu.be/T9GjBJaQ8y4

[f4k3]

@MaxKorz Actually you can see that at 20 or 23 second of your video. Your crosshair sprite is jittering to the left more but angles didnt change so much to the left. when you move to the right jittering is much less. And try to move mouse more slowly in 10 times more slowly. And look how it takes to turn on some angle by one slow swipe on the mousepad.

[f4k3]

@MaxKorz Also try to set default_fov to 9000 and fps_max to 1000 to reproduce it more constantly and you will see. It is there. And it's known problem. It isn't a placebo.

[ghost]

I'm sorry, I won't do that. If you are setting those cvars manually, you need to know what you are doing. I bet there's no way to reproduce this bug without changing cvars to extremely low or high values.There's no point in default_fov higher than 109.78 or lower than 86.3. And I don't understand why would you set sensitivity to 0.2 or lower. Even in your video, you can barely move the cursor. Use defaults and don't cheat with scripts. Also, as I know, GoldSource has some bugs when fps is above 100, so "If you are setting those cvars manually, you need to know what you are doing."

Actually you can see that at 20 or 23 second of your video. Your crosshair sprite is jittering to the left more but angles didnt change so much to the left

This bug is discussed here https://github.com/ValveSoftware/halflife/issues/154 https://github.com/ValveSoftware/halflife/issues/356

[r3n4m3]

@MaxKorz that bug is exists, and that should be fixed!!!

[f4k3]

@MaxKorz
But in my video i reproduce this with normal values. It's my normal settings just acceleration is off. You just need to know what looking for. It will affect you with normal settings, just less noticeable but it will. Some people wining about acceleration with rawinput 1, i think they affected by this bug.

I am using acceleration, so my base sensitivity is 0.2, with 3500 dpi. And i just cannot play with awp because of that bug. I need to move my mouse in few times faster to turn to the left on the same angle. And it will just eat some amount of my initial movement even without zoom, before acceleration is applied. It really affected my gameplay.

And if i buy a mouse with 6400 dpi, i wannt to use that advantage. In case 6400 dpi i need to base sensitivity like 0.15 or 0.1.

default_fov is used by engine only like multiplier. it is here
// set a new sensitivity that is proportional to the change from the FOV default m_flMouseSensitivity = sensitivity->value * ((float)newfov / (float)def_fov) * CVAR_GET_FLOAT("zoom_sensitivity_ratio");

[ghost]

default_fov is used by engine only like multiplier. it is here

try to change it in Half-Life

[r3n4m3]

at this time i use Razer DeathAdder 2013 via 6400 CPI, and it's awful because of these limitations and bugs

[f4k3]

@MaxKorz
yeah in halflife it's used but in cs for long time it has been only way to achive sensitivity lower than 1. Which is needed if you use 3500 dpi. And still if i wannt to use sensitivity lower than 0.2 i can use default_fov, but there comes that bug.

You doesn't need low sens, fine. But bug is there, and it will affect you even with normal settings. But you will not notice it.

It need to be fixed.

[ghost]

See, that's how you should report a bug. Get more information about how to reproduce it

Sorry, I can't confirm it with dpi 800, 1600, 2000.

It isnt dpi depented

to achive sensitivity lower than 1. Which is needed if you use 3500 dpi.

obviously, high DPI causes this bug and I tried default_fov 9000 and fps_max 300 (I can't get more), still can't reproduce

[r3n4m3]

@MaxKorz lol u did before, we could see that in ur video...

i reproduce that bug! so finish this pointless polemics.

[ghost]

@r3n4m3

lol u did before, we could see that in ur video...

I reproduced shacking crosshair, not impossibility to move the cursor with low sensitivity

[f4k3]

@MaxKorz Oh there is mistake. It isn't impossible, it is just dropped some amount of mouse reports, if they smaller some value. but didn't when i move to the right.

[r3n4m3]

u didn't understand what u did and what u should pay attention, because that reason everything @f4k3 realized that video via mouse checker, which show what exactly happened.

[f4k3]

Can you fix that? It is absolutely destroyed my aim with awp.

[pcenthusiast92]

@f4k3 Hello fake did you solved your problem? Did you try to use Cl_mousegrab 1 instead to remove the (green bar) positve accel?

[bertbest]

Hello,

This "bug" is still present and really annoying for all players using low sensitivities in Half-Life engine games.

I can reproduce it in Half-Life, Action Half-life and Counter-Strike 1.6.

Once your sensitivity is low enough, small mouse movements will be ignored. You can literally move your mouse one meter without moving your crosshair, if you go slow enough. The problem seems to start when your sensitivity is below 1.

Ingame sensitivity 1 is usually low enough, even for most low sensitivity players. But the problem is, that all the zoom weapons lower the sensitivity further, which will trigger the bug. To avoid this, you are forced to play with a relatively high zoom_sensitivity_ratio (far away from common low sensitivities). As an alternative, you can increase your normal sensitivity (which is an even worse choice).

For example, the crossbow in Half-Life will reduce the FOV from 90 to 20 and in parallel lowers your sensitivity by the same factor (4.5) and additionally applies the zoom_sensitivity_ratio factor. Lets say you play at sensitivity 1. To make sure you are not affected by the bug, you have to get your effective zoomed sensitivity back up to about 1 (by playing with sensitivity 4.5 or zoom_sensitivity_ratio 4.5 or a mix of both). The same principle applies for other games, like Counter-Strike 1.6, where the FOV goes from 90 to 40 (factor 2.25) when using first zoom of AWP. When you play with sensitivity 1, you have to use zoom_sensitivity_ratio 2.25 or higher to fully avoid the bug. Although fps_max had a slight effect on it, I was not able to resolve this issue by altering fps_max, m_rawinput, m_filter or using another mouse.

I guess this bug was introduced with the engine patches 2013. I played on the Half-Life engine for so long (since release) and was always quite picky about mouse input. I don't think this bug has affected me since the beginning. It is not present in the Source engine btw.

There a still people playing Half-Life Mods in 2017, please improve it or provide a hotfix!

[pcenthusiast92]

@bertbest

I'm agree with you 100%, this is problem is real, in 2013 game changes alot........

When playing cs 1.6 on 100 fps, mouse are behaving bad i play on 2.5 sensitivity 800 dpi on my g9 with polling rate between 250-500, and when testing or dropping fps_max in game to 50 fps+0.02 ex_interp using rates 101 101, mouse feel a little be better

But i cannot play at 50 fps is very difficult, mouse behavior is bad till the point that for my g9 mouse is better to turn off m_rawinput to 0 and cl_mousegrab either 1 or 0, but even that is not good

but im guessing you play at 1 sensitivity with? 1500 dpi or something? or what are your mice settings My g9 is a logitech laser sensor and i use it on window 6/11 un-thick acceleration and ingame -noforceparms to avoid windows thick the acceleration

[bertbest]

@CloudHaze

Limiting FPS below 100 is no solution anyway, you should not bother with that.

To be clear, I still have pixel precise mouse movement in the HL1 engine, the problem only occurs when using zoomed weapons (or when setting the sensitivity to very low values on purpose).

For your reference, here are my settings: 800 DPI and ingame sensitivity 1 (that's about 53 cm / 360 °) 500 Hz 1024x768 Ingame zoom_sensitivity_ratio 0.5 Windows sensitivity 6/11, EPP unchecked -noforcemparms, m_rawinput 0, m_filter 0 (they do not affect the bug)

For example: switching to 400 DPI, ingame sensitivity 2 and zoom_sensitivity_ratio 2.25 fixes the bug for my Half-Life zoomed crossbow (for the cost of a very high zoom sens).

[pcenthusiast92]

@bertbest
Woah 800 dpi + 1 sensi you gotta have a good mouse or very smooth to play with at 1 sensi.

At least for me here in my ryzen build cpu 5 1600 +b350 motherboard In cs 1.6 by using 1024x768 too and 75hz 250 or 500hz, +6/11 Epp unchecked too

I cannot play with that 1 sensitivity I barely can move the mouse :/ maybe the culprit is the ryzen new technology that. seems to mess with USB ports or speed, or something or maybe the moues g9 or either my mouse-pad are no that good, or maybe Half life sensitivity is kinda different from Cs 1.6 ?

[djdallmann]

Can you guys try m_side 0, default is 0.800 and to me makes the sensitivity more consistent.

[pcenthusiast92]

m_side | 0.8 |   |   | float | mouse | It defines how fast you strafe while moving your mouse. It Needs lookstrafe 1 and Mouse Look Enabled(+mlook) to strafe with your mouse.

[satnatantas]

This bug is still here!

[satnatantas]

@djdallmann I tried it and it seemingly fixes it for me.

[djdallmann]

Glad to see someone tried it.

[satnatantas]

Actually, the bud is still there but the magnitude is significantly reduced with m_side 0.

[satorkain]

mouse: logitech g102 pro, 500hz, 400 dpi

launch options: -mousethread -noforcemaccel -noforcemparms -noforcemspd -high -16bpp -w 800 -noaafonts -nomsaa -nofbo -full -gl -console +v_dark 1 +gl_ansio "16" +strafe

in game cvars: m_customaccel "0" m_customaccel_exponent "0" m_customaccel_max "0" m_customaccel_scale "0" m_filter "0" m_forward "0" m_mousethread_sleep "2" m_pitch "0.022" m_rawinput "1" m_side "0" m_yaw "0.022"

in my case, the bug disappears at sensitivity 2.5 https://youtu.be/Xg71Nk8LBQQ

[r3n4m3]

I could see that your FPS is too high. Pls check with fps_max 99.5.

should shows 100.0 fps via net_graph 3

in my case, the bug disappears at sensitivity 2.5 https://youtu.be/Xg71Nk8LBQQ

and what is your zoom_sensitivity_ratio?

[satorkain]

I could see that your FPS is too high. Pls check with fps_max 99.5.

should shows 100.0 fps via net_graph 3

in my case, the bug disappears at sensitivity 2.5 https://youtu.be/Xg71Nk8LBQQ

and what is your zoom_sensitivity_ratio?

No difference what fps, zoom_sensitivity_ratio 0.90

In the new video "fps_max" 99.5 and "zoom_sensitivity_ratio" 1.2 Now the bug disappears at "sensitivity" 1.9

https://youtu.be/kBImBN0s2N4

[mjsmith707]

Can you guys try m_side 0, default is 0.800 and to me makes the sensitivity more consistent.

Thank you so much for this. I've been dealing with this forever it seems. The bug seems to completely go away for me at my sens (2.04 @ 400 dpi mx518)

edit actually I noticed something weird. In between maps I need to do m_side 0.800 and m_side 0 again to fix it. Maybe the bug isn't related to that setting so much as some side effect changing it has. Ya another time it did nothing but setting it back to 0.800 made the bug disappear