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.
1 Like
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.
1 Like
I got this to work by setting the value type to be a Vector2. Then when you do a context.ReadValue() 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.
2 Likes
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.
4 Likes
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. “/scroll”
13 Likes
Thanks, but what kind of wizardry is this ? Is this really a 1.0 verified package …
7 Likes
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.
4 Likes
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:
Vector2 vec = Mouse.current.scroll.ReadValue();
scroll = vec.y
6 Likes
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
6 Likes
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?)
1 Like
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!
1 Like
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
3 Likes
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)
3 Likes
…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.
1 Like
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.
1 Like
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.
1 Like