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^^