How do you get mouse scroll input

I am unsure on how the mouse scroll input is detected from the InputSystemManager. I have an action called Scroll and on that I added a button of scroll from mouse. I then have a script called OnScroll and it's supposed to detect the scroll input from the inputmanager but it isn't. I am adding image below of my input manager. My mouse is working and is connected.

 

If i add the left and right mouse clicks to the keybind it works, but the scroll doesn't. Mouse is fine, not broken so no issues on the physical mouse.

 

I got this to work by setting the value type to be a Vector2. Then when you do a context.ReadValue<Vector2>() from the action the value will be on the Vector2.y

The value always seemed to be (0,120) or (0, -120), but it was enough for me to get it to work correctly.

Sorry for the crappy formatting I'm on my phone.

 

Set it as an Axis. Then pick just the axis you want to track. Most likely Scroll/Y [Mouse]. Then it will come in as a float. Why it picks 120 as the value of a single scroll I have no idea.

 

Just for clarification. You cannot set the binding up as a 1D Axis Composite otherwise itll only work in one direction (Scrolling up) but not down. It has to be a regular binding.

However when you choose regular binding you can only select on the X or Y axis. If you select the Y axis only Scroll Wheel Up will work and again down will not. Regular scroll turns greyed out and you cannot select it. If you manually type it in using the T on the right it finally works. "<Mouse>/scroll"

 

Thanks, but what kind of wizardry is this ? Is this really a 1.0 verified package ..

 

Just as a helpful hint for people who comes across this - if you want to convert the 120 number to a -1F to 1F range, you can add the processor 'Normalize Vector 2''.

I've done this so all my scroll inputs match those of my keypad and gamepad so I can use the one action to handle for each.

 

uhmmmmm

 

There is only Normalize processor,and still get -120~120.

 

For reference, if you want to get the mouse scroll in code alone, you can also do this:

Code (CSharp):

1. Vector2 vec = Mouse.current.scroll.ReadValue();
2. scroll = vec.y

 

It depends on the binding type you're creating. It drove me nuts until I figured it out.

It's a sensible choice filtering out Axes when making a button binding, but it should communicate this filtering better.

Example A :: Button (Default)




Example B :: Axis

 

Seems to still be broken in late 2021 (latest version of InputSystem from PackageManager). Nothing in the docs to suggest Unity will randomly multiply by 120 on some OS's (but not others, apparently?)

 

I'm on 2021.1.16, had an issue with the scroll input registering multiple times. I changed Action Type to Pass Through, Control Type to Axis, and Binding Path to Scroll/Y [Mouse], and im getting the scroll input as expected. It's still in increments of 120 but just treat the 120 as 1 increment of scroll. Hope this helps someone!

 

Code (CSharp):

1. Debug.Log(Mouse.current.scroll.ReadValue().normalized);

While using the UnityEngine.InputSystem namespace, this debugs values of -1 and 1 for me
Unity 2021.1.18f1

 

You realise that's literally just wrapping the API call in "if < 0 return -1, if > 0 return 1", right? If we wanted to do that we could easily do that (it's less than one line of code).

As far as I can tell this is incorrect code: different scroll wheels should be returning different amounts per frame. Discarding the data and converting them all to +/- means that sensitivity is now broken for your app on every platform - the user will have set sensitivity in their OS, and Unity is removing that.

Certainly: I get different sensitivity by default on the broken New Input implementation than I got on the old Input system. Maybe they're both wrong! But it seems unlikely that 'randomly return 120 times 1' is correct.

 

Since the standard value seems to be 120, and then any operating system/software scroll wheel speed modifications will likely be influences on that default (e.g. ramp-up speed would be somewhere between 0-120), the way I handled this to get manageable values is to add a Scale processor on the Scroll/Y input.

Then you can use math inside the text input - 1/120 to get the proper fraction, which brings any 120 values directly to -1 or 1. This also maintains the data of any easing/modifications to the scroll speed that may occur - if a value of 60 were to come through, it'd be 0.5. This also still handles values above 120. if you got a scroll input of 180 it'd be 1.5 (I'm using easy numbers to demonstrate with, but this works with literally any number coming in from the input value and doesn't lose input data). still very useful/good values to work with in my opinion.

 

More digging: if you write the code yourself in C++ then 120 is what you get if you didn't read Microsoft's documentation on input in Windows (guess what happened to me while I was testing, and hadn't read the docs yet? ). Sooooo ... I'm feeling increasingly conifdent in saying that 120 is a (significant) bug from Unity's team.

You are not going to get numbers from 1...120. You are going to get:

1 = all platforms where Unity implemented the API correctly
120 = Windows, where they didn't

... I haven't seen Unity's source code, and Unity refuses to document their API, so they could just claim any value is "by design" and pretend they didn't make a mistake. But I would avoid being dependent on 120: it is very likely IMHO to get fixed in a future update when they realise the mistake.

(Windows has a macro that gets you the correct value. You pass-in the thing that appears to be +/- 120 and you'll get back more sensible numbres - e.g. +/- 1)

 

...although at the same time: on Windows I've given up on Unity's crappy "new input" system, so many obvious bugs (and this has been allegedly production-ready for a year or more!) -- it's easier and higher quality (with more features, more information) to wrap the native Windows C/C++ APIs and avoid Unity's bugs.

 

Please submit an official bug report on this, with the M$ docs indicating the issue. It'd help anyone in the future who will encounter it. (Assuming Unity addresses it.) @Rene-Damm you may want to take a look into this at some point as we're well past V1.0

Edit, on a related note, my mouse has a toggle for graduated or free wheeling, I set it to free wheeling and spun that sucker as fast as my finger would let me. The max value I saw on windows was 720 so there's certainly a need to manage scrolling more delicately than just clamping to + or - as a scroll. That said scrolling at that speed is certainly not normal.

 

As noted: I'm not using Unity's input any more. I submit a lot of bugs, and some of the Input ones have started being processed by QA/Engineering, but I don't consider this one worth the effort - takes a lot of time, then waiting months for Unity staff to read them, etc. There's enough wrong with Unity Input that I just don't use it now, except for simple/trivial uses in projects that are only doing simple input.

 

Run into the same issue. I believe the doc being talked about is:
https://docs.microsoft.com/en-us/windows/win32/inputdev/wm-mousewheel

which indicates values are in WHEEL_DELTA multiple which is 120...

 

Just ran into this problem while switching over to the new input system. Based on what's been discussed in the thread so far I'm now doing this:

Code (CSharp):

1. wheelDelta = Mathf.Abs(wheelDelta) > 1 ? wheelDelta / 120f : wheelDelta;

Would be nice for Unity to fix this though, but there are definitely bigger fish to fry

 

To be fair - this is not really a unity bug, but a platform difference. As per the WM_MOUSEWHEEL reference that blep linked, microsoft chose to represent a single 'click' on the mousewheel as 120 so that future devices could provide fractional scroll values (because the value is an integer in the win32 api; not floating point) - I think this started actually being possible with Vista, but it's up to the mouse (or trackpad) driver etc.

Smooth-scroll devices will do one of two things on windows: they'll either accumulate scroll motion and emit a scroll when enough has been gathered, or they'll emit more frequent lower amounts (30, 50, etc)

Because I know this is the way windows is - I've opted for a platform-specific conditional;

bool _isWindows = Application.platform == RuntimePlatform.WindowsEditor || Application.platform == RuntimePlatform.WindowsPlayer; //There's also the web and server values if those are relevant to you
...
return _isWindows ? scroll / 120f : scroll;

I can't speak as to linux or mac (or other platforms) - scroll values quite possibly will depend on a combination of platform, driver, and the specific device (mouse, trackpad etc) .. test where you can; if someone runs into something weird - log data.

 

Of course it's a bug - read Unity's API docs, read Microsoft's. Unity is providing a float that is supposed to be the same (or close enough) on every platform *anything else is by definition a bug in Unity, since this is part of Unity's core purpose: be multi-platform*. Microsoft provides a clear direct workaround and "divide by 120" is not the correct approach (As per MS's docs). So ... Unity's bug. Unity staff should fix it.

 

just ran into this problem and initially thought I just had the input system wrongly configured (wrong action/control type or needing processors or something), this thread saved me a lot of trying and testing^^

 

Code (CSharp):

1.  
2.         public bool IsScrollUp()
3.         {
4.        
5.             float value = _playerInputActions.Player.MouseScroll.ReadValue<float>();
6.             return  value > 0.1f;
7.         }
8.    
9.         public bool IsScrollDown()
10.         {
11.             float value = _playerInputActions.Player.MouseScroll.ReadValue<float>();
12.             return  value < -0.1f;
13.         }
14.  

 

That appears to be exactly what was already explained a year or more ago, but worse (as the replies above note: it's wrong). Why exactly were you commenting?

 

I wrote this for those who want to see the finished solution, and not for those who want to read your complaints about the new input system.

 

Just a question, who ACTUALLY uses input actions?

 

I use them all the time when enabling new input. Yes, the UX is a hot mess and in many places it's poorly designed (too many things that should be easy are way over-complicated to no benefir, or should work but are missing/dont work/do the wrong thing with no warning) but when you memorize the main mistakes and workarounds then it's easy enough to use.

I mostly use the actions as a clean way of interfacing between code and UI: e.g. I write them as class fields, allow the Editor to automatically create the Inspector UI, and then I ship (eg) editor-asset demos which are clean code (all script) and yet the end-user can easily change the mappings if they want directly in Editor. Assuming they've memorized all the weird bizarro design of new-input GUI -- but that's what the Unity tutorials are for, and people who've done it are happy using it.

 

It's funny that you call what he stated "complains", but he's the only one who correctly pointed out the problem in this thread.

 

I've reported it with an example program and a link to the MS docs.

 

Do you have an issue link for voting on this?

I've got the described bug in Unity 2022.2.1f1 + Input System package 1.4.4

 

Unity Issue Tracker - [Windows] InputValue of the scroll wheel changes with the step of ±120 when scrolling using Input System (unity3d.com)

 

Thank you very much!

Its beeing "considered", for the 1.4 cycle. I guess is good news
It had 0 votes

 

now it has 2^^

 

What macro gets you the correct value? The only macro I see for mouse wheel is GET_WHEEL_DELTA_WPARAM() and that gives +/- 120. I don't see any other macros on their documentation (https://learn.microsoft.com/en-us/windows/win32/inputdev/wm-mousewheel), and all other examples I've seen online (e.g. https://social.msdn.microsoft.com/F...-vista-solution?forum=gametechnologiesgeneral) just divide by 120.0f.

 

It's been almost 2 years since I was working on that code, but from memory the macro was described in the Microsoft docs somewhere - but there's a lot of docs on mouse/keyboard/HID input (including the different generations of it from MS) and I can't remember which one it was. It might have been in the public header files instead - there are detailed docs written-in to the header files for HID if I remember correctly - but I'm pretty sure it was in the online web docs too.

 

Bad news I'm afraid:

 

This is a policy sometimes deployed by Unity's dev teams - certain teams auto-reject any/all bugs to keep their bug counts down. As a bug-reporter, it's insufficient for you to simply "report" bugs, you often have to also "pitch" each one to Unity. Unity's QA people in particular often don't understand the bug reports (they only have basic knowledge of using Unity themselves) and will close them without having understood the issue.

(In a typical year I log 20-40 bugs, many of which get rejected initially, but most of them get accepted and fixed after a few emails back-and-forth to get the people at Unity to take them seriously).

 

right... I guess if you ignore bugs hard enough, you can pretend they dont exist... probably not the best way to handle tickets from the dev/QA side ^^

 

Your time is better spent on pitching other devs to avoid Unity like a plague

 

Wow, what a weird problem lol.
Just coming here to bump, I have the exact same issue and was wondering why 120... sometimes 240, 360 if I scroll hard enough with my mouse.

 

What a mess. I guess they think that cherrypicking bugs and discarding the rest is a helpful practice? No idea what are they thinking, had a few similar experiences recently. It is preposterous, they arbitrarily discard reports like if the time we invested creating them was out of fun or boredom.

Of course not going to create any more bug reports, but the underlying issue is quite worrying: the required chain of decisions and events leading to unity devs discarding field reports with such disdain, speak of something very, very bad in there.

 

Note that while the bug report got set to "won't fix," the issue is still marked "in progress" and currently has 15 votes. The more votes, the more likely it is to get fixed I guess.

 

I don't think Unity has ever paid attention to the votes. Maybe 10 years ago when the original voting system was new? But they didn't like the votes results, we kept upvoting important bugs that needed fixing but were painful/expensive to fix, so ... they just ignored them, or seemed to (I think they said they used the votes 'to get an idea of what people want, but it's not a promise we'll actually do anything with them')

A lot more effective is either of:

1. Explaining to QA what they are supposed to accept/reject, using copy/pasted text from unity3d.com, official docs, etc -- QA often rejects items because the Engineering/whoever tells them to, and if you give them the 'evidence' that the (person who is refusing to fix the bug) is wrong, then QA seems quite good at using that to go back and get that other person to - in turn - do their own job, and to stop making excuses that confuse the QA team.

2. Finding an Engineer at Unity (on twitter ideally, or in person at a Unity event. If that fails: hope they notice you on the forums) who works in / near the team responsible, and who cares enough to 'adopt' the bug, and go and ask the person responsible why they aren't fixing it (which sometimes causes that person to surrender and fix it) -- or to see it's an easy fix and fix it themself.

3. Making social media posts showing how easy the bug is to fix, and how embarassing it is that Unity staff claim they 'cannot' fix it, until someone at Unity gets so embarassed they fix it / instruct someone else to fix it to make the bad PR stop.

This may sound ridiculous, but ... option 3 was actually the most traditional way, back when Unity was a tiny company: posting on social media / blogging bugs was the primary bug-reporting strategy (alongside emailing Unity directly). This was before they created the crappy badly designed (AND STILL BROKEN) UnityBugReporter.exe and insisted all bug reports go via that.

 

Unity's old input system is returning ±0.1 not ±1 with my mice (Logitech G600 and SteelSeries Aerox 9). I've tested with Unity 2022.3.5 and 2023.1.5 on Windows 11. The new input system is returning ±120. Aside from adding the new input system package and enabling both I haven't made any changes to the "3D" built-in template project.

Code (csharp):

1. using System;
2. using UnityEngine;
3. using UnityEngine.InputSystem;
4.  
5. public class MouseTest : MonoBehaviour
6. {
7.     private void Update()
8.     {
9.         var oldScroll = Input.GetAxis("Mouse ScrollWheel");
10.         var newScroll = Mouse.current.scroll.ReadValue();
11.    
12.         Debug.Log($"Old: {oldScroll}");
13.         Debug.Log($"New: {newScroll}");
14.     }
15. }

 

Yeah, the old input system is quite different.

 

Code (CSharp):

1. // KeyboardCharacterControls is the name of the action map
2. [SerializeField] PlayerInput PlayerInput;
3. [SerializeField] float MouseScrollDirection;
4. void Awake()
5. {
6.     PlayerInput = new PlayerInput(); // PlayerInput is generated automatically by New Input System
7.     PlayerInput.KeyboardCharacterControls.MouseScrollWheel.started += onMouseScrollWheel;
8. }
9.  
10. void onMouseScrollWheel(InputAction.CallbackContext started)
11. {
12.     MouseScrollDirection = started.ReadValue<float>();
13. }
14.  
15.  
16. void OnEnable()
17. {
18.     PlayerInput.KeyboardCharacterControls.Enable(); // script is enabled, enable Action Maps
19. }
20. void OnDisable()
21. {
22.     PlayerInput.KeyboardCharacterControls.Disable(); // disable Action Maps
23. }
24.  

Results in -1 / 1 for those interested.

 

Problem comes when you're aiming at more than just Windows


On other news, they've silently removed the "wont fix" note.