Mouse input issues concerns and what will be done about it

[RedCat]

I've been play-testing the builds from the #BeyondUnreal IRC channel aka the Non Epic Play-test and one major issue I noticed is the mouse input. It is extremely difficult to playtest when the aiming feels so off and quite frankly I'm surprised that almost no one is discussing this, there are a few topics here and there but no one seems really concerned by it and the general attitude seems to be "it will be fixed later, we are just proto-typing".

While yes, we are just proto-typing, how can someone proto-type / play-test weapons and movement when the mouse input is inconsistent?

I am personally having huge problems, for example: I can not properly test any weapon because of the mouse input being no good at all, even though I make the same movements with my mouse physically, my crosshair ends up somewhere else - testing weapons becomes a pain in the ***. The same goes for movement, if I can not move my camera exactly like I want to, how am I expected to test out wall jumps and the like?

While, obviously it's still possible to test, some people even got good with the current input, I do not believe that it is acceptable to keep this any longer, because: mouse input, just like movement (where an entire forum board is dedicated to) is one of the VERY basic things of the game, something which should properly work from the beginning.

I saw someone reply in another topic about the same subject that maybe there was something wrong with the guy's PC or mouse and that he should check it out. This is, most definitely, not the case and the input issues affects literally everyone who is playing - even if you don't notice it, it's there and it's affecting your play style, skill level and most importantly your testing and proto-typing abilities.

I would offer to fix it but sadly I do not know enough about Unreal Engine 4 or any of the underlying code to fix it.

I do have someone who could possible help, a pretty famous person in the competitive scene is MarkC or Mark Cranness. Who made a fix for the Windows 8 and 7 mouse acceleration, more info about that can be found here:
http://donewmouseaccel.blogspot.nl/2...ation-fix.html

It has some interested stuff in it, perhaps he could help with this? I've found one account of him to contact: http://www.reddit.com/user/MarkCranness

Or else someone from the Unreal community could step up and bring in a fix, so we can play-test the game better and provide more accurate feedback.

[KaL976]

Well said.

[TheWhiteDragon]

The issue on the community side it's that we really don't know what the problem is. Many point to the need for raw input, but we don't really know where the engine even handles this stuff. It probably already has raw input. I don't experience the lag in the editor, and I believe it's a more general performance issue. Ini tweaking seems to help significantly.

The issue on the other side is that this really falls under the domain of the engine team. They are really the ones this question needs to be posed to.

[Tetsu]

^ This, in the editor it's fine (since some build at least) but not in the packaged builds.

I really hope this gets a serious approach this time around. Mouse input was something that I always had a problem with for every game that used ue3.

[knepleyp]

Hello all, I really appreciate your attention to detail when it comes to input. I have been spending a lot of time recently trying to make sure we have the best input possible and will continue to do so for the life of the game. The last few days I've been doing input latency testing and Steve pointed me towards this thread so I started looking at our mouse acceleration issues.

I've read through http://donewmouseaccel.blogspot.nl/2...ation-fix.html and verified that we don't use the same SPI_SETMOUSE calls that would accidentally re-enable mouse acceleration in Window XP and above.

My mouse movement research has shown me that we do use WM_INPUT for raw mouse input as outlined in http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx . The article implies that WM_INPUT mouse movements are not smoothed by windows regardless of your "Enhance pointer precision" setting when it says "WM_INPUT has no ballistics applied to its data, so if you want to drive a cursor with this data, extra effort will be required to make the cursor behave like it does in Windows". I encourage you to test disabling that setting in the mouse control panel and let me know if you do see a difference. It's possible that we could provide a menu option in-game to disable the "Enhance pointer precision" setting for you.

The relevant code sections for anyone interested are all in Engine\Source\Runtime\Core\Private\Windows\WindowApplication.cpp on the github distribution of the UE4 source.

We do use the default UE4 mouse smoothing when not in-editor mode. This is most likely incorrect. You can see the effect of this by typing "showdebug input" into the console, you can see the divergence of the two boxes means you aren't getting 1:1 input. (You have to type "showdebug" again to make the debug HUD go away). I've added bEnableMouseSmoothing=false to our DefaultInput.ini so hopefully the next build you try will feel better. It looks like JoeW already made a Mouse Smoothing UI option, but probably better to just have it off by default for everyone. bEnableMouseSmoothing being the issue would explain how TheWhiteDragon is not seeing mouse issues in the editor as the editor does not smooth mouse input even if bEnableMouseSmoothing is true.

[TheWhiteDragon]

bEnableMouseSmoothing being the issue would explain how TheWhiteDragon is not seeing mouse issues in the editor as the editor does not smooth mouse input even if bEnableMouseSmoothing is true.

When I play I always disable the mouse smoothing, which makes a big difference. I don't consciously notice mouse lag, but I do find it more difficult to hit with hitscan weapons. Which is why I believe that it's more a graphical performance issue than anything. Graphics options that are enabled in the packaged build, but not the editor window. I haven't really turned off graphical options in the ini yet, but I will try it tonight assuming the packaging errors introduced by moving content is fixed. I'd also point out that when they upped the max/min values for the framerate smoothing I noticed a big difference.

[KaL976]

The article implies that WM_INPUT mouse movements are not smoothed by windows regardless of your "Enhance pointer precision" setting when it says "WM_INPUT has no ballistics applied to its data, so if you want to drive a cursor with this data, extra effort will be required to make the cursor behave like it does in Windows". I encourage you to test disabling that setting in the mouse control panel and let me know if you do see a difference. It's possible that we could provide a menu option in-game to disable the "Enhance pointer precision" setting for you.

Hi, I've had the windows mouse movement slider in the middle position for 1:1 and enhance pointer precision off since those options were added to windows, so no, it makes no difference to the ingame lag in the packaged builds.
Nice to hear it's being looked into though. Thanks.

[Infiadux]

The last few days I've been doing input latency testing and Steve pointed me towards this thread so I started looking at our mouse acceleration issues.

I hope this means you realize that there is about a 30-40ms delay in mouse input, at least that's what I assume you mean when you said you are doing input latency testing. I don't have any acceleration problems (after doing a quick test), but this input lag is really killing my aim. I'm grateful that you guys are working on this though.

[tigerclaw]

Hello all, I really appreciate your attention to detail when it comes to input. I have been spending a lot of time recently trying to make sure we have the best input possible and will continue to do so for the life of the game. The last few days I've been doing input latency testing and Steve pointed me towards this thread so I started looking at our mouse acceleration issues.

I've read through http://donewmouseaccel.blogspot.nl/2...ation-fix.html and verified that we don't use the same SPI_SETMOUSE calls that would accidentally re-enable mouse acceleration in Window XP and above.

My mouse movement research has shown me that we do use WM_INPUT for raw mouse input as outlined in http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx . The article implies that WM_INPUT mouse movements are not smoothed by windows regardless of your "Enhance pointer precision" setting when it says "WM_INPUT has no ballistics applied to its data, so if you want to drive a cursor with this data, extra effort will be required to make the cursor behave like it does in Windows". I encourage you to test disabling that setting in the mouse control panel and let me know if you do see a difference. It's possible that we could provide a menu option in-game to disable the "Enhance pointer precision" setting for you.

The relevant code sections for anyone interested are all in Engine\Source\Runtime\Core\Private\Windows\WindowApplication.cpp on the github distribution of the UE4 source.

We do use the default UE4 mouse smoothing when not in-editor mode. This is most likely incorrect. You can see the effect of this by typing "showdebug input" into the console, you can see the divergence of the two boxes means you aren't getting 1:1 input. (You have to type "showdebug" again to make the debug HUD go away). I've added bEnableMouseSmoothing=false to our DefaultInput.ini so hopefully the next build you try will feel better. It looks like JoeW already made a Mouse Smoothing UI option, but probably better to just have it off by default for everyone. bEnableMouseSmoothing being the issue would explain how TheWhiteDragon is not seeing mouse issues in the editor as the editor does not smooth mouse input even if bEnableMouseSmoothing is true.

Thanks for taking the time to look into this issue Pete

I've used a program called Mouse Movement Recorder to test out raxxy's UT4 build and can confirm that enhanced pointer precision is off and everything looks pretty good with no positive or negative accel being recorded

However this is only measuring the input from windows(i believe)

As an example if you do a circle in game it does a horizontal oval... lol

If raw input is being called without the use of direct input or no other layers then maybe the problem is how the game is handing that input, rather than how it's getting the input

Even though the ini axis are both the same, with smoothing off and the exponent at 1.0 there's still an issue there

I'm not the only one who's reported getting an oval when they try to do circles with the mouse either

[tigerclaw]

Pointer movement is the same as mouse movement, so it seems to be taking the input 1:1 without issues

This would also show up as such if Direct Input was being used

[knepleyp]

I hope this means you realize that there is about a 30-40ms delay in mouse input, at least that's what I assume you mean when you said you are doing input latency testing. I don't have any acceleration problems (after doing a quick test), but this input lag is really killing my aim. I'm grateful that you guys are working on this though.

How are you measuring this? I'm using an LED soldered to the left mouse button switch and a high speed camera. I'm seeing ~83 ms between mouse touch and gun reaction in UT at 120 hz. Using the same setup, I'm seeing ~133 ms between mouse touch and gun reaction in CoD Black Ops 2 PC. In a DirectX test Windows app, I'm seeing ~42 ms to ~66 ms response time. It seems like USB mice are slightly to blame, but I don't have conclusive proof yet and I'm still investigating.

EDIT: Reread the post and you're talking about movement and not firing, my mistake. Which Windows version are you on? There are some Windows 8.1 raw input issues. I'm going to poke around in the packaged builds being referenced here and see if I can get a local repro on the lag issues.

[chicken-]

Already a thread about this: https://forums.unrealtournament.com/...te-Scalability

There is absolutely acceleration in this game, past Unreal Engine games had a bviewacceleration setting you could change to false to remove it. Why it's EVER on by default is beyond me but this definitely needs to be fixed in UE4 because even with the MouseSMoothing off, it's absolutely not feeling like 1:1 movement.

[sneh]

As an example if you do a circle in game it does a horizontal oval... lol

Is this what you mean?

[knepleyp]

Is this what you mean?

That would appear so, that can't be a good thing.

[knepleyp]

InputYawScale is now 2 and InputPitchScale is now -2 in DefaultGame.ini. Left them at 2 instead of 1 to keep sensitivity in the same ballpark. Must've been a holdover from gamepad stuff. Let me know if that feels any better and if the ovalness has gone away.

[/Script/Engine.PlayerController]
InputYawScale=2
InputPitchScale=-2
InputRollScale=1.0