Well… yeah, that’s how it has to work. Because there’s nothing to “normalize” on in a 1D Vector. Let’s say you have a scroll on a scale of 0-60, and you want to normalize it to 0-1. This is accomplished by dividing by 60. But the function has no clue what range it should do this on, because it doesn’t know what values to compare it to–it doesn’t know what number to divide by. Normalization only works “automatically” when you have 2D or beyond, because it can reference the magnitude of each individual axis and scale accordingly so that the magnitude of one axis is proportional to the magnitude of the other brought down to 1.
Typically scroll wheel hardware applies the inputs in “ticks”. My best guess is that the 120 value refers to 120 pixels of motion across the screen in a single tick, or some other measurement. I’d also wager that something like an Apple mouse or touchpad has more degrees of motion than your standard 5 button, so those might register input events at lower values. However the key takeaway is that the reason these values are different is to accurately approximate the amount of physical motion from your device. Even though an Apple mouse might come in with a 10 value instead of 120, it’s likely because the scrolling “event” happens more frequently due to hardware mechanics and so actually scrolls at the same speed. So really, if you want to emulate the effect of scrolling like through a web browser, you should just leave the value alone and manually scale the entire Action’s value to match the speed of your game. Doing this means that people with lower mouse scroll values will likely have a higher frequency of input events, meaning the resulting motion should be about the same as those with high scroll values if you compare over the course of several seconds.
I should also mention that this hardware-agnostic value scaling likely happens through the OS. On Windows you can set your scroll speed in the mouse options, so I’d presume it affects the value read by Unity. That means no matter what, users will scroll slower or faster depending on their personal OS preferences, there’s no avoiding it. Unless… (and this is where it gets tricky…)
If you’re just looking to consider each scroll event as a single “tick”, you can Clamp the value instead of Normalizing it. That means that no matter how big the value is for each mouse, the scroll value will always come in at either 1 or -1. Then you can speed up or slow down according to your game speed so that every single input (scroll and keyboard) makes the zoom at the same rate. However, be warned: while this may make things “technically” the same, it completely ignores point of the dynamic values in the first place, which is to make the physical motion of scrolling universal. Essentially, if you use this method with the same Apple mouse example I had before, people with the Apple mouse have their scroll events happen more frequently. People without the Apple mouse have events that happen less frequently. Since everything is scaled to 1 regardless of the frequency, you will see people with the Apple mouse scroll more than people without one.
With that in mind, my recommended solution is to just leave the mouse binding values unchanged, so that your map can account for the frequency of scroll events and just have people scroll using their personal preferences. Then I would say just scale the keyboard binding to match that of a standard mouse, say 100 or so. Then if you’re still unhappy you can always add a user defined parameter for the speed. I hope this has helped in some way. You’re right to question every corner case about potential input devices, it shows that you’ve really thought about how things will end up working for the user. So hopefully this example will show that doing these thought experiments and understanding the data you’re working with can go a long way towards making better programs.