Scrolling the hotbar on mac behaves weirdly starting in 18w01a

This hasn't been fixed, it takes multiple clicks of my mouse's scroll wheel to move one slot over in 18w21b.

There is now an option to change scroll sensitivity.

So where can I change this option? I still have that problem, too.

Agreed... this is not fixed! I also tried to report, it just got closed due some way I formatted it. 

Just tested Pre-release 2, this is not fixed. This makes the game annoying and almost unplayable. And yes, where is this so called option?

Like the moderator's note says, simply change the value very clearly listed in the options file in the Minecraft directory.

Ugh... there is a reason you keep getting "duplicates" of this issue. Because it is NOT fixed. `mouseWheelSensitivity` is not a solution. I truly think that your devs just don't understand what the issue is.

With a Logitech M705 mouse, the wheel "clicks" as you scroll. In 1.12, the number of item slots it would move is the exact number of wheel clicks, no matter how quickly you scroll. That is the behavior we want back.

With "sensitivity", if you scroll quickly it will pass many more items than clicks. If you scroll slowly, it will pass fewer items than clicks (or not move at all). A higher sensitivity value improves the behavior for fast scrolling, but worsens slow scrolling. A lower sensitivity value improves the behavior for slow scrolling, but worsens fast scrolling. See the problem? Since nobody always scrolls at the same speed, there is no sensitivity value that fixes the behavior consistently.

I think you really need an option to disable sensitivity completely, and always move exactly 1 item slot on a mousewheel event, regardless of the "amount" of scroll.

1.13 is completely unplayable until this is fixed.

And given the large number of people reporting this issue, I can only imagine how many more are experiencing it but aren't savvy enough to report it here.

Maybe sensitivity is an "improvement" - and I can definitely see how it is on certain screens such as the chat history and creative mode inventory.

But with item switching, we've come to expect a certain behavior. One wheel click = one slot.

Item switching is probably the 3rd most frequently used control (after left and right clicking) and it's absurd that you would a) change the default behavior, b) tell people to go hack into their options.txt file - I'm sure many have never touched this file and wouldn't know how to, c) especially when there is no configuration possible that will revert to the 1.12 behavior.

Not to mention the setting gets erased if you load a world up in any version previous to 18w21a and then change any setting in that version (e.g. modify the sound settings). This results in the options.txt file being rewritten, and of course, mouseWheelSensitivity is not a valid option in earlier versions.

Obviously this is only an issue when running older versions of Minecraft but since this is the way the launcher is designed to work, I'd say that this renders the new feature fairly tedious for any user.

I don't think this is resolved by the wheel sensitivity option.

In macOS, disabling "smooth scrolling" in Logitech Options takes back the desired "one-slot per one-wheel-click" behavior.
Previous Minecraft versions did work consistently regardless of this option, but since 18w01a, the smooth scrolling option began to destroy the hotbar scrolling in Minecraft.

Though Logitech Options offers "application-specific settings" where I can disable smooth scrolling for specific apps,
it does not help us because Minecraft is a Java-based console program, not a native macOS GUI application, and thus not recognized by Logitech Options.

This is definitely a big deal for me, and makes the game a pain to play.   If the wheel sensitivity option is not working for others besides me, please fix it soon!  Just my emphatic vote.

Thank you

Changing my mousewheelsensitivity to 10 from 1 in the .minecraft/options.txt fixed it for me
😞

That worked for me as well.

Not sure if the solution will work. The weird thing is the inconsistency of it. I'm not sure if upping my sensitivity will fix the weird "scroll lag".

I am unable to find .minecraft/options.txt
Got it fixed. Thank you everyone.

This issue does not reproduce on my machine on windows, with several different kinds of mice. Can everyone experiencing this issue please give:

A) Their OS
B) The mouse they are using, and what kind of scroll wheel it has

I'm encountering this myself.

OS: macOS 10.13.6

Mouse: Logitech M720 Triathalon.  Mouse wheel is in "click" mode, where each click is supposed to scroll one line (and did so in previous versions of Minecraft)

I've tried modifying the Mouse Sensitivity option and it doesn't seem to do anything.  Issue is also intermittent, sometimes a single click does scroll only one line, other times it jumps 2 or 3 or 10.

Edit: I'll also confirm that disabling Smooth Scrolling in the Logitech Options application does appear to work around this issue.  Go to the Point & Scroll tab, change Smooth Scrolling to "Disabled".

I'm still having this issue.

I'm running OS: 10.13.6 and I am using the track pad on my laptop.

I am still having this issue, and I'm playing the official release of 1.13. This has never happened to me EXCEPT on the 1.13 snapshots and releases. 1.12.2 and below all work fine.

I'm running macOS: 10.13.5

My mouse is a blackweb Wireless Bluetrace Mouse.
I'll also add that it does NOT have an options section anywhere, so there isn't a way to disable Smooth Scrolling like with Logitech (at least I can't find one).

Also when I loaded 1.13 and went to .minecraft/options.txt, I opened it and could not find "mouseWheelScrolling" anywhere.

Mods, please don't mark an issue as resolved WHEN IT CLEARLY ISN'T!
PLEASE PRIORITIZE THIS, as 1.13 survival is completely unplayable for me with scrolling like this. 

Similar as above for me. Scrolling the hotbar often takes multiple wheel ticks to do in 1.13, but is fine in 1.12.2. On macOS 10.13.6, using a SteelSeries Engine 3.12.9 with a Rival 100 mouse.

I did try setting mouseWheelSensitivity to 4.0 and it didn't seem to make a difference. Tried 20.0, and it works nearly all of the time - there still seems to be an issue when I change scrolling directions. So I tried 40.0 and that appears to always be consistent. I've probably exceeded some upper threshold value, but that worked for me.

@redstonehelper

Why was this marked as "fixed".

Why did you say you would make a new ticket when this ticket describes the issue as well.

Why did you never link to this new ticket you made, I can't seem to find it.

This isn't fixed for me either... 

We can except this bug to be resolved in 4 or 5 years like the Mac-only super annoying bug that affects the dead keys in international keyboard mapping. 

@unknown, Like @unknown said above:

This issue does not reproduce on my machine on windows, with several different kinds of mice. Can everyone experiencing this issue please give:

A) Their OS
B) The mouse they are using, and what kind of scroll wheel it has

Edit: Did you even adjust the mouseWheelSensitivity option in options.txt?

The problem with mouseWheelSensitivity is that, while fixing the scroll problem, it makes it so that when you scroll in the creative inventory, the scroll bar goes super fast and skips a ton of items; so the mouseWheelSensitivity is not helping.

Right, sorry, I've gotten distracted. What you said there pretty much sums it up; something is messed up with how scrolling is input, and it seems to be exclusively a mac issue. I've been meaning to investigate further, but the basic data I got shows that initially the sensitivity is super low, but after a bit it jumps higher up.

I'm reopening it for now, since there is definitely a bug separate from this, but where the bug is I have yet to ascertain (and I can't do that until I get access to a mac again, which will happen in a few weeks).

Please let me know if this happens on a device other than a mac, or if you have a mac and do not experience it.

The game is unplayable...

This does make it extremely hard to play, as switching items is unpredictable (at best). I am running under macOS, 10.13.6

I'd like to note (and unsure whether related or not) that the scrolling doesn't work at all while holding shift. That is, I cannot change hotbar inventory anymore while crouching.

Setting mouseWheelSensitivity to 20000 seems to have restored the ability to scroll the hotbar with my Logitech G500 on macOS 10.13.6. Creative inventory, however, is completely unusable. Scrolling any of the pages causes the window to go from whatever position it's currently at to the very bottom (or very top if I scroll up).

Same here, Agent, except I have a blackweb wireless bluetrace mouse and 10.13.5

I don't know if this is related or not, but I cannot scroll while holding shift.

Asteraoth : 

macOS 10.13.6

Logitech G402

Like others said, changing the mouseWheelSensitivity in the option.txt isn't a fix since it screw up and other scrolling in the game. Also, if you expect users to manually change a text setting in a game that got out of beta 7 years ago, I consider this a bad fix.

I think that's related to the LWJGL v3 update that fixed MC-6436 for Mojang (after 5 long years without the possibility to correctly chat or naturally type ~ without a trick). I just hope Mojang won't again wait until a third party update does the trick... I'm sorry if Minecraft relies on LWJGL but they're not responsible for Minecraft. Mojang is. 

Sorry to write like this but the previous bug made me bitter against Mojang. That was kind of an important bug and it took 5 years to be solved and was never assigned to any developper and if the plan was to wait for the LWJGL update, there was no communication about it.

This new bug is a MAJOR bug : it affects the hotbar scroll greatly. It was submitted 9 months ago : no assignment still and no communication about it. I thought the very purpose of the snapshots was to detect major bugs thanks to the big number of users. Yet the final version of 1.13 was released while it was still unplayable on Mac.

As a note: I'm currently analyzing this issue. This one actually isn't an LWJGL 3 issue, though a number of other input ones. Rather, it's something with how the game interprets the scroll data, which works fine on windows (and presumably linux) but goes poorly on mac. I'm currently working on figuring out exactly what's wrong and the right way of putting it.

It does seem like there's been a communications issue here; the mouseWheelSensitivity thing was intended as a workaround for this issue which partially worked, but was known to be experimental and was supposed to have been more clearly worked on if it worked well. (However, it seems like this wasn't communicated clearly on the tracker, and then the issue was resolved as fixed, which just lead to more confusion).

I'm still working on digging up exactly what's going on here and how scrolling on mac should behave vs how it does behave. Some stuff is very weird, and that's why this is taking a while (combined with the fact that I don't actually have access to a mac, so I need to go through other people to get the needed data). Just hang tight for a bit.

Thanks for the communication, I really appreciate that. If that's not LWJGL than I thought about something.

macOS handle scrolling differently if it comes from the trackpad (with multitouch) or if it comes from a mouse with a physical wheel (a non Apple mouse) :

• with the trackpad, the scrolling works like iOS or Android : The scrolling is smooth and with inertia.  is  In my experience, Minecraft respond to that inertia too. However, nobody in their right mind would play Minecraft or any FPS with a trackpad...

• with the mouse with physical wheel it works exactly like it should too. Every wheel click is registered and the scrolling is discreet The “scrolling speed” setting in macOS only affects the acceleration. However, that shouldn't affect any games IMHO.

• with an Apple Magic mouse, that use touch stuff for scrolling, I suppose it works similar than the trackpad but I can't verify that since I haven't used an Apple mouse for more than 15 years.

However, I don't know how Apple does the difference but since the trackpad has a smooth scrolling and the mouse click is discreet, maybe something is up with that and interfere with the new Minecraft. However, everything worked well until Minecraft 1.13.

P.S.: How come Mojang doesn't have Macs to test on?  

Are there any news about this bug? I can't play the game since 1.13 because of this and the update is amazing. mouseWheelSensitivity does not work and I could fix it by making the scroll speed fastest in the settings. Even then it is not as responsive as it was in other versions

Shouldn't the “Fix Version” be removed?

I didn't notice anyone comment on it skimming through the notes just now, but it REALLY needs to also be noted that this isn't just scrolling between tools. Also this: when you crouch and try to change tools, NO SCROLLING HAPPENS. You can't crouch and change tools at all.  

This really does need to be looked at, beyond "mouse sensitivity". And even with that, I wouldn't call it mouse sensitivity, because for me I can only seem to get a tool change to happen when a scroll action is a "double-click" (two scroll notches advanced). When I just scroll notch/click once, nothing happens.

Anyway, it has rendered the game virtually unplayable for me, which is especially frustrating because the server and crew I play with are all moving on to 1.13 very, very soon, and this bug has existed for months now.

Setup for me is: 

• Discovered the bug on OSX 10.12.6

• Just upgraded to OSX 10.14, and the bug persists

• Mouse is a totally un-special generic "Microsoft Basic Optical Mouse v2.0"

• Machine is imac Retina 5k, 27inch, late 2015 (4Ghz Intel core i7, 32 GB ram)

Also, this issue with the UI, which is likely suited for another thread: 

On all the snapshots prior to 1.13, when you'd switch between versions, the UI would retain its look, scale and feel just fine. But when you switch to 1.13, the US is scaled absurdly small, and you have to totally mess around with the scaling just to get it to look right... which ends up making all the other snapshots look HUGE in scale when you switch back to them. 

1.13 has a lot of neat features, sure, but good lord... it's just enough of mess in terms of controls and UI. A lot of great features are in this new version that I (and a lots of others) can't even play and enjoy.  😞  Huge frustration. 

Note: Edited for clarity.

Since they don't even seem to test on Macs, It's becoming obvious that that don't care that much about that platform; damn it... a bug that makes a game almost unplayable, reported since the very first snapshots and not even a developper is assigned. 

Just a status update: I'm still looking into this, and this is still present in 1.13.2-pre1 (from what I can tell). What I'm currently looking at is what firefox does with scroll input on mac, and that's what's taking a while (along with school and other projects).

As far as I know installing USB Overdrive will solve this problem. But still hope this problem get fixed though

For me, setting mouseWheelSensitivity to 10 dealt with the problem adequately. Updating LWJGL seems to have been the proximate cause, with the underlying cause being the way that LWJGL reads and interprets scroll wheel input.

Background

I use a Mac for Minecraft, but I don't know that much about its scroll wheel handling. However, I have written drivers for X11, including an input device driver. And to do that, I had to become familiar with both the input processing of X11 and the kind of information received from the physical input devices, including trackpads and scroll wheels. Based on that, I can provide some info and generate some hypotheses.

Legacy scroll wheel input is simple. Rolling the wheel a single click one direction is button 4, and the other direction is button 5. This would make its way to applications that would essentially scroll their windows however they wanted. Window managers that intercepted this input could create some consistency by controlling window scrollbars the same way across apps and even add some acceleration based on time between clicks.

When trackpads came in, the raw input became very fine-grained, in the form of multi-touch position changes. Legacy window managers and apps selecting for buttons 4 and 5 had to have these discrete clicks emulated, where the discrete clicks try to match the velocity from the touch-pad input, plus acceleration (where "acceleration" here is still used to refer to artificial boosting of scroll distances or emulated click rates when the user is trying go large scroll distances). In fact, there's code for going both ways. You can have an application/window manager select events for a variator, which can be taken either more directly from a track pad or emulated from scroll wheel clicks. And you can have an application/window manager select events for buttons 4 and 5, which can come either more directly from a scroll wheel or calculated from multi-touch input.

For a long time, Apple has directly integrated smooth scrolling into their UI infrastructure, and all Cocoa apps use what is assumed to be a direct mapping from multi-touch input and scroll position (plus acceleration, same definition as above). So for macOS, if you use a mouse with a physical and discrete scroll wheel, the emulation predominantly goes from clicks to smooth scroll. That is, wheel clicks are converted to jumps in smooth scroll position. On Windows, the smooth scrolling isn't as well integrated, and as a result, track pad smooth scrolling is highly inconsistent across applications. A common case is for track pad input to be converted to emulated wheel clicks and then back to scroll jumps by the application, and acceleration mismatches can be annoying.

LWJGL on macOS

The likely cause of the behavioral change on Mac is that LWJGL has switched its default handling of scroll input from discrete clicks to smooth scrolling, to better match the usual way in which applications get that input. However, Minecraft is still asking for discrete jumps. I'm not sure how LWJGL was able to get the wheel click input before, but I highly doubt that that is completely gone from the code. Most likely, there is a missing configuration setting on init that Minecraft needs to make to re-enable direct scroll wheel input. There, of course, needs to be a fallback in case LWJGL doesn't automatically fall back to converting from trackpad input when there's no actual wheel.

How to fix

There are multiple ways in which this could be fixed. Most likely, there's a single line of code that needs to be added that will re-enable discrete click support. I (if I have time) could have a look at the code to LWJGL (it's open source, right?) and see what's changed in that area.

If LWJGL has removed this completely, then the next course of action would be to modify LWJGL to add the legacy click wheel support back in. That shouldn't be too hard. Moreover, I would consider this whole situation to be a bug in LWJGL if that's the case. Of course, that doesn't mean Mojang can pass the problem back to LWJGL, because we'll wait around forever for a fix.

A third solution is for Minecraft to stop asking for discrete click wheel events. Instead, it would take the smooth scroll data and perform the reverse conversion itself. Most likely, the smooth scroll input comes in time-discrete jumps, even when it's from a trackpad. The OS probably batches them a bit, below human perception, in order to avoid passing too many messages to application, which would have significant energy and CPU overhead costs. When the scroll wheel is used, I expect that you'll typically get one batch per click except when you're rolling it so fast that the OS decides to batch them. The PROBLEM probably comes from the fact that a scroll wheel click is being converted into a scroll distance that's too small; LWJGL must be accumulating these until the total motion reaches a threshold, at which point it delivers an emulated event to the application. By adjusting mouseWheelSensitivity, what we're doing is multiplying that distance by a constant factor so that each wheel click distance passes that threshold. This in turn is affected adversely by acceleration; when using mouseWheelSensitivity, if you turn the wheel too fast, then each click will be made to correspond to an artificially greater distance, and the result is that Minecraft will skip over hotbar slots.

So, to fix this in the way I'm describing, what Minecraft would have to do is accept smooth scroll events and then work out based on their rates and distances when they appear to be coming from a trackpad (small motions at a high rate) or a mouse wheel (large motions at a lower rate). It would also have to figure out when acceleration kicks in by observing when these large jumps get larger. For the most part, when heuristics indicate wheel input, then it's the number of events that matters, not their distances. However, if the OS consolidates them when the wheel is scrolled too fast, then there's a corner case where some clicks might get lost; I'm not sure if there's any point in bothering, though, because the hotbar only has 9 items in it, so most people won't be whipping the wheel that fast. In fact, the harder problem might be to decide how much smooth scroll distance (from a trackpad) is appropriate for hopping between hotbar entries.

@unknown's analysis above is close, but it doesn't actually match the data I've been collecting (and after talking with him, he agrees that this superseeds his). Here's my full analysis; you don't have to read the whole thing but do check the first section and the last two sections. The most important bits of it:

• 18w01a fixed MC-122053 by looking at the scroll magnitude values given by LWJGL; before it just looked at the direction. (Note that what theosib said about the magnitude not being reported seems to be inaccurate on windows and mac; a magnitude is present here at least for some mice)

• It did that not only for scrollable lists, but also for changing hotbar slots, but also they made it so that for changing hotbar slots, a total scroll amount of 1.0 needs to be hit. This seems reasonable in theory, but there are other issues...

• On windows, a small scroll produces a single event with a small magnitude; for my mouse, it's 1/4th of the full size. Scrolling faster produces some larger events, but scrolling at a constant speed produces events of the same magnitude as per this graph.

• On mac, a small scroll change produces a delta of .100 on LWJGL 3. However, continuing to scroll produces a MAJOR acceleration, as seen in this graph from a mac using a windows-style mouse – from .1 to 10, over a very short amount of time.

• This weird acceleration isn't a bug in LWJGL 3; it can also be seen on LWJGL 2, and also on firefox - it's an inherit behavior on macs, as such.

Why does mouseWheelSensitivity help? Setting it to 10 makes things slightly better, but that's just because it makes it so the smallest reported value from a mac of .100 is treated as 1.0 and thus a hotbar rotation. It doesn't do anything about the acceleration, and isn't a perfect solution.

My recommendation thus is to just eliminate the code from 18w01a that checks for rotations less than 1.0 and adds them, and instead to treat any rotation as sufficient for the purpose of changing hotbar slots (as was the case in 1.12.2). It may make sense to allow configuring whether to ignore the magnitude in various cases as well.

Any word yet on resolution for this bug? Mojang explicitly sells Minecraft for MacOS... yet support for this matter (and the gamers) seems to be going nowhere. Sorry to be terse/short here, but it has been months since 1.13 was released (in July, and it's now November, which is 5 months later, and still, to this date, it's not playable in full. As community servers are being updated, a huge chunk of us are being left behind because 1.13 is broken. 

Again, noticeable across multiple machines: 

1) Mouse scroll sensitivity is broken (a lone scroll click does nothing, and reckless/quickly scrolling works ok)
2) also, mouse scrolling doesn't work at all when crouching (you can't change tools at all when crouching).
3) Interface scale doesn't carry over correctly when switching between different versions (1.12 interface might look fine, but 1.13 is ultra tiny, and anytime you have to switch between versions you have to frustratingly mess with the UI to get it looking consistent)

Any idea when this is going to be resolved?

Thanks,

MTS

Honestly, yeah, I'm with you on being confused as to why this hasn't yet been fixed yet (however, please don't start a giant debate here in response to it; if you want to talk more about that then do so in /r/mojira to keep this ticket organized). I feel like they should also be experiencing it, or at least someone at the actual office uses a mac and should notice it (I personally don't have a mac, which makes keeping track of this issue a pain...).

In any case, addressing your points:

1) is this issue, and might be fixable by increasing your senstivity but acceleration is still insane and that isn't directly an issue with MC itself, but mojang could fix it by not trusting the magnitude of the scrolls on mac. I will amend my previous comment by noting that trusting the magnitude on windows actually seems beneficial (now that I've gotten used to it, it feels a bit nicer than on 1.12.2, but that's where a full rotation click makes sense and such which isn't the case on mac)

2) is a separate issue, and won't be fixed by my comment. I actually have no idea why that's the case... and I'll try to investigate it when I get a chance. I will note that that does not happen on windows. One possibility is that you can change tools by using the numbers 1-9, but of course if you're used to scrolling that's probably not going to be ideal.

3) is not a bug. Downgrading versions isn't supported and will clobber the configuration; this is mentioned in the update notes. If you want to run both 1.12 and 1.13 concurrently, do so in separate game directories (this is an option in the launcher). This also has the benefit of you not being able to accidentally corrupt a world by loading it in an older version.

I'm going to ping the devs again about this issue; hopefully they'll be able to fix it (at least 1 which I've documented an explanation of)...

Yes, please, do speak with them about this, beyond a simple "ping" if you can. Bugs do happen of course, and that's ok. But this? This is a significant issue, and it has now existed for several months. It's baffling why the issue is not resolved, and it's frustrating and especially disappointing that a significant chunk of the player base, and the very platforms the game is literally advertised as supporting, are not being supported and taken seriously (seemingly).   😞 👎    

Thanks for your reply on the 15th.

– ST

Yes, this is REALLY frustrating. The last major bug that affected the Mac was NEVER assigned and was resolved only after five years with the LWJGL update to 3.0 that gives us this present bug as a gift. It really feels like Mojang just don't care about the Mac plateforme or plan to abandon it in the future.

That's what I'm left wondering too, seriously. If they are going to abandon it, then out of respect for everyone they just need to be forthcoming and officially outright say it, so we can all move on. This routine of repeatedly bringing up this issue - "it's broken... fix?" "it's broken... fix?" "it's broken... please, fix?", and then to only be ignored repeatedly, is absurd. And it's absurd not just from the standpoint that you're dumping all over your own customers, but to the point that their concern about critical functionality and playability in their own released products is below par. And that's disheartening.  

To blow off your player base like this is something that I'd expect from like Activision or EA, but not Mojang. I just don't get it.

And here I was about to buy additional licenses for my family for xmas so we could all play together (and we all have Macs)... Thank friggin' god I didn't jump the gun on that purchase this holiday season. Time to start looking around on Steam instead? I guess? Just in case?

No dev in sight after almost one year. I guess the only solution to be heard is to bother them on Twitter, since the official way of reporting bug seems useless.

Can't believe this isn't fixed yet, this is a really frustrating behavior.

What's the status of resolution for these bugs?

The status is « Don't care about Macs ». Since the bug came with an update of LWJGL, they don't seem to bother. However if they do care, they don't really show...

Still a bug on macOS. Unbelievable. I've taken a hiatus from Minecraft entirely and hoped that it would be fixed by now. Guess I'll just quit playing forever then.

OS: macOS Mojave 10.14

Mouse: Logitech Marathon M705, with click wheel

I was hoping there'd be a fix to this issue. 
Over a year and Mojang still hasn't fixed this... wow. 

I'm kind of glad I have a mouse with a num-pad, though it's a bit annoying to select the higher numbers. 

I found a temporary solution on reddit that may help until/if mojang fixes this issue. 

A member by the name of WhateverTechBits replied with this:

I have found this problem as well. I checked the mojang bug fixing page suggested by @Lordofthevillagers and it said to access the option.txt file in the minecraft folder and "tweak" the option named mouseWheelsensitivity. Tweak. The mouseWheelsensitivity was set to 0.5. I put it to 20000. It now scrolls like 1.12.2 did. As a temporary solution, it works, but i still find it to be mildly annoying to go through all that hassle just to make it something that was already in the game.

https://www.reddit.com/r/Minecraft/comments/7zk8lj/new_snapshot_scroll_wheel/

I think 20000 is still too low, and you may have to play around with it to get what you like. But it's something that might be a temporary solution. 

See the body of the ticket itself. Setting it to 20000 is excessive; if it's higher than normal then it won't give any advantages for scrolling (but will completely mess up other things). Try just 10 and see whether that makes a difference.

Can't play on Mac with this, there is no detailed instructions on how to patch.  Frustrating. 

"Adjust the new mouseWheelSensitivity option that has been added to .minecraft/options.txt. In most cases, setting this to 10 will produce a reasonable hotbar behavior."

Where is this .txt file?  I can't find it. 

See https://minecraft.gamepedia.com/.minecraft; .minecraft refers to the game directory. The exact location is actually ~/Library/Application Support/minecraft/options.txt.

Thank you so much for the help.  That did the trick on 2 iMacs with Logitech G502 mice.  This has been bugging me for sometime.  Was just playing with old release .12 or whatever, but just installed Optifine and wanted to try with new release is guess "18w01a".

At first like a month or so ago thought it was my mouse.  Spent sooo much time trying to fix what I thought was an Logitech mouse driver software issue.  

Seems to work, thanks!

Update:

Scrolling is between items is better, but there are other issues:

1) Scrolling wheel won't allow you to scroll while holding down L SHIFT Sneak you can not scroll different items.  So if you are building a bridge and run out of wool you cannot hold L SHIFT Sneak and change to different item. 

2) Also on 5k iMac mouse pointer gets stuck on. Disabling the right and left mouse buttons.

3) The mouse buttons don't work because even when you come out of E or ESC menu the pointer mouse pointer is still on the screen.  I had a very hard time getting rid of it because in the options menu I had to double click the menu items and double clicking send you to a sub-menu that isn't the one you wanted.  I was trying to toggle to full screen and it took forever to figure out how to get there.  Finally I figured out you needed to double click. 

I'll update this post soon.

I will try to add the mouse sensitivity option as a real, in-game option for you to configure. I will also fix the issues where it goes wildly out of control in some UI elements. When scaled up to 10, it should be acceptable behaviour all around.

The core issue here is actually something in OSX/GLFW - all we are told is that "something" scrolled about 0.1, whether that comes from a trackpad or a real mouse. This makes sense for trackpads - they have precision scrolling. It unfortunately doesn't make sense for mice, and needs to be scaled up by 10 - but we do not get told when it is a mouse or when it's a trackpad, so we aren't able to dynamically adjust for this 😞

It's unfortunate that this will have to be an option, but until we are able to get more control from the native API then this will have to be the solution for the time being.

@Dinnerbone, I appreciate the effort to add this dirty patch to the GUI, but that's not promising at all... I'm sorry. If the issue was on Windows, I'm pretty sure that would have been another story.

Maybe it's time to ditch Java or least all the unreliable third parties libraries you don't have control over.

I'm sorry but that's not fixed in Minecraft 1.14 Pre-Release 2... I had to change the scroll Sensitivity up to 10 in order to get the hot bar working. But now the creative menu scroll is completely out of control... but well.

Please check what happens when you toggle Discrete Scrolling and turn down the scroll sensitivity. Discrete Scrolling is a new setting.

The general mouse scrolling does seem better in 1.14-pre2, thanks for the update there. However I am still not able to mouse wheel scroll the hotbar while sneaking. This was possible in 1.12.x, but since 1.13 to 1.14-pre2 this hasn't worked and is a bit frustrating while building when in a precarious position. Thanks.

@Pokechu22 My bad, I'm sorry about this... The discrete option does indeed work at sensitivity 1 and above. Thank you.

@unknown: Great, thanks for checking. I'll update the mod note comment about it.

@unknown: That's a separate issue. which I thought there was a second ticket for but it looks like I never got around to creating one. Can you create a new report for it? I'll look into it later when I've got a chance (I think it probably has something to do with vertical vs horizontal scrolling). See MC-121772 (which for some reason wasn't linked as related to this report; I've linked it now.)