Scrolling the hotbar on mac behaves weirdly starting in 18w01a
In 1.14 (starting in Pre-Release 2)
In Mouse Settings, toggle "Discrete Scrolling" and set the sensitivity back to 1.
In 1.13 (starting in 18w21a)
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.
18w01a changed how scrolling works. Trying to scroll through hotbar slots is often unsuccessful now. Scrolling in the creative inventory is now very fine-grained, to the extent that it is now possible to change item lines without changing the position of the slider, see attached screenshots.
Scrolling, as observed in the creative menu, doesn't scale linearly with physical scrolling speed either.
I also attached a forced crash report for system info.
Note that this is different from MC-122641, which was introduced in an earlier snapshot.
Likely caused by the fix for MC-122053.
From the comments:
I have been doing some more testing on this issue. My setup is on MacOS 10.13.3 and a Logitech MX Master Mouse with the mouse wheel in "click-to-click" mode (i.e. you can move the mouse wheel one "notch" at a time with feedback.)
Prior to 18w01a, if you were to move the mouse wheel one notch on the hotbar, the selector would move across one slot for each notch.
Since 18w01a, it takes 10 individual notches to register the mouse moving across (it will move over on the 10th notch.) I have tested this by counting the number of individual notched scrolls before the selector will move across to the next slot in the hotbar. This effect happens in either direction.
Analysis
See this comment and this longer write-up.
Environment
MacOS only
Linked Issues
is duplicated by34
MC-124075Using the scroll wheel to switch hotbar slots takes multiple scrolls for each slotDuplicateMC-125328Scrolling not working correctlyDuplicateMC-125523Hot bar takes more force to scroll thru with mouse wheelDuplicateMC-126608Scroll Wheel item selection is less sensitiveDuplicateMC-128032Mouse scroll wheel is insensitive/game doesn't always detect scrollingDuplicateMC-128745Scroll wheel skipping in hot-barDuplicateMC-130578Scrolling through hop bar does not match scroll speedDuplicateMC-130792In the new snapshots for 1.13 and in pre release 1, the scroll wheel on Mac is messed up, you have to scroll many times to move one place in your hotbar.DuplicateMC-131212Scrolling is not responsive. DuplicateMC-131563Mouse scrolls too slow through hotbar (using actual mouse)DuplicateMC-131919Scrolling one space on the hotbar is extremely slowDuplicateMC-132080Scrolling Semi-Unresponsive in Hotbar Mac 1.13DuplicateMC-133033Logitech Mice's Smooth Scrolling makes Hotbar scrolling too fastDuplicateMC-133471Hotbar MovementDuplicateMC-134041Item SelectorDuplicateMC-134046Scrolling from the newly released 1.13 seems to not be working properly. It feels weirdly slow and takes multiple scrolls to change between items. This was also an issue in the pre releases of 1.13 and is still one in the full 1.13 release.DuplicateMC-134053Tool bar does not scroll properly when using a click wheel on a mouse.DuplicateMC-134140Scrolling to select hotbar doesn't work or temperamental DuplicateMC-134164Mouse wheel scrolling bugDuplicateMC-134198Mouse wheel sensitivity issue.DuplicateMC-134221Scrolling Through hotbar in 1.13 is brokenDuplicateMC-134376Wheel mouse not working properly and not being able to use Fn key as sprintDuplicateMC-134500External Mouse IncompatibilityDuplicateMC-134541Scroll Wheel Needs multiple clicks to cycleDuplicateMC-134632Scrolling is way too slow on MacDuplicateMC-135003Scroll wheel doesn't react until I move it fast (macOS)DuplicateMC-135404Scrolling is slower and lagging on Mac DuplicateMC-135430Un-reactive track pad when scrolling through HUDDuplicateMC-137278OSX hotbar scrolling unresponsiveDuplicateMC-137937Scrolling doesn't work well on macDuplicateMC-138238Menu with textures is not scrolled by the wheel immediately from version 1.13+.DuplicateMC-141560Minecraft 1.13.2 - Scroll Wheel not fully responsiveDuplicateMC-142268Delay from mouse to gameDuplicateMC-156429Scroll broken on mac.Duplicaterelates to7
MC-130093Changed, non-linear scrolling in inventoriesCommunity ConsensusMC-42367Mouse wheel scrolling function too sensitive with mouse wheels without distinctive clicksAwaiting ResponseMC-121772Can't scroll while holding SHIFT on macOSFixedMC-122053Mouse wheel/touchpad scroll amount is ignoredFixedMC-122641Very slowly scrolling up in chat does not workDuplicateMC-121381Slower sensitivityWon't FixMC-136359mouseWheelSensitivity bugAwaiting Response
![[Mod] redstonehelper](../../../data/avatars/users/10122.svg){kind=small}
Created Issue:
Weird scrolling behavior in 18w01
18w01a changed how scrolling works. Trying to scroll through hotbar slots is often unsuccessful now. Scrolling in the creative inventory is now very fine-grained, to the extent that it is now possible to change item lines without changing the position of the slider, see attached screenshots.
I also attached a forced crash report for system info.
Linked Issues
is duplicated by1
Attachments3
18w01a changed how scrolling works. Trying to scroll through hotbar slots is often unsuccessful now. Scrolling in the creative inventory is now very fine-grained, to the extent that it is now possible to change item lines without changing the position of the slider, see attached screenshots.
I also attached a forced crash report for system info.
Note that this is different from
MC-122641, which was introduced in an earlier snapshot.
Weird scrolling behavior in 18w01a
relates to
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
is duplicated by
18w01a changed how scrolling works. Trying to scroll through hotbar slots is often unsuccessful now. Scrolling in the creative inventory is now very fine-grained, to the extent that it is now possible to change item lines without changing the position of the slider, see attached screenshots.
I also attached a forced crash report for system info.
Note that this is different from
MC-122641, which was introduced in an earlier snapshot.Likely caused by the fix for
MC-122053.
Weird scrolling behavior starting in 18w01a
is duplicated by
is duplicated by
18w01a changed how scrolling works. Trying to scroll through hotbar slots is often unsuccessful now. Scrolling in the creative inventory is now very fine-grained, to the extent that it is now possible to change item lines without changing the position of the slider, see attached screenshots.
I also attached a forced crash report for system info.
Note that this is different from
MC-122641, which was introduced in an earlier snapshot.Likely caused by the fix for
MC-122053.From the comments:
I have been doing some more testing on this issue. My setup is on MacOS 10.13.3 and a Logitech MX Master Mouse with the mouse wheel in "click-to-click" mode (i.e. you can move the mouse wheel one "notch" at a time with feedback.)
Prior to 18w01a, if you were to move the mouse wheel one notch on the hotbar, the selector would move across one slot for each notch.
Since 18w01a, it takes 10 individual notches to register the mouse moving across (it will move over on the 10th notch.) I have tested this by counting the number of individual notched scrolls before the selector will move across to the next slot in the hotbar. This effect happens in either direction.
18w01a changed how scrolling works. Trying to scroll through hotbar slots is often unsuccessful now. Scrolling in the creative inventory is now very fine-grained, to the extent that it is now possible to change item lines without changing the position of the slider, see attached screenshots.
I also attached a forced crash report for system info.Note that this is different from
MC-122641, which was introduced in an earlier snapshot.Likely caused by the fix for
MC-122053.From the comments:
I have been doing some more testing on this issue. My setup is on MacOS 10.13.3 and a Logitech MX Master Mouse with the mouse wheel in "click-to-click" mode (i.e. you can move the mouse wheel one "notch" at a time with feedback.)
Prior to 18w01a, if you were to move the mouse wheel one notch on the hotbar, the selector would move across one slot for each notch.
Since 18w01a, it takes 10 individual notches to register the mouse moving across (it will move over on the 10th notch.) I have tested this by counting the number of individual notched scrolls before the selector will move across to the next slot in the hotbar. This effect happens in either direction.
18w01a changed how scrolling works. Trying to scroll through hotbar slots is often unsuccessful now. Scrolling in the creative inventory is now very fine-grained, to the extent that it is now possible to change item lines without changing the position of the slider, see attached screenshots.
Scrolling, as observed in the creative menu, doesn't scale linearly with physical scrolling speed either.
I also attached a forced crash report for system info.
Note that this is different from
MC-122641, which was introduced in an earlier snapshot.Likely caused by the fix for
MC-122053.From the comments:
I have been doing some more testing on this issue. My setup is on MacOS 10.13.3 and a Logitech MX Master Mouse with the mouse wheel in "click-to-click" mode (i.e. you can move the mouse wheel one "notch" at a time with feedback.)
Prior to 18w01a, if you were to move the mouse wheel one notch on the hotbar, the selector would move across one slot for each notch.
Since 18w01a, it takes 10 individual notches to register the mouse moving across (it will move over on the 10th notch.) I have tested this by counting the number of individual notched scrolls before the selector will move across to the next slot in the hotbar. This effect happens in either direction.
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
is duplicated by
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
is duplicated by
is duplicated by
18w01a changed how scrolling works. Trying to scroll through hotbar slots is often unsuccessful now. Scrolling in the creative inventory is now very fine-grained, to the extent that it is now possible to change item lines without changing the position of the slider, see attached screenshots.
Scrolling, as observed in the creative menu, doesn't scale linearly with physical scrolling speed either.
I also attached a forced crash report for system info.
Note that this is different from
MC-122641, which was introduced in an earlier snapshot.Likely caused by the fix for
MC-122053.From the comments:
I have been doing some more testing on this issue. My setup is on MacOS 10.13.3 and a Logitech MX Master Mouse with the mouse wheel in "click-to-click" mode (i.e. you can move the mouse wheel one "notch" at a time with feedback.)
Prior to 18w01a, if you were to move the mouse wheel one notch on the hotbar, the selector would move across one slot for each notch.
Since 18w01a, it takes 10 individual notches to register the mouse moving across (it will move over on the 10th notch.) I have tested this by counting the number of individual notched scrolls before the selector will move across to the next slot in the hotbar. This effect happens in either direction.
As of 18w21a, the mouseWheelSensitivity addresses the hotbar scroll speed, but inventory scroll speed is still too fast. However, it is no longer as fine-grained as shown off in the 2 attached screenshots.
18w01a changed how scrolling works. Trying to scroll through hotbar slots is often unsuccessful now. Scrolling in the creative inventory is now very fine-grained, to the extent that it is now possible to change item lines without changing the position of the slider, see attached screenshots.
Scrolling, as observed in the creative menu, doesn't scale linearly with physical scrolling speed either.
I also attached a forced crash report for system info.
Note that this is different from
MC-122641, which was introduced in an earlier snapshot.Likely caused by the fix for
MC-122053.From the comments:
I have been doing some more testing on this issue. My setup is on MacOS 10.13.3 and a Logitech MX Master Mouse with the mouse wheel in "click-to-click" mode (i.e. you can move the mouse wheel one "notch" at a time with feedback.)
Prior to 18w01a, if you were to move the mouse wheel one notch on the hotbar, the selector would move across one slot for each notch.
Since 18w01a, it takes 10 individual notches to register the mouse moving across (it will move over on the 10th notch.) I have tested this by counting the number of individual notched scrolls before the selector will move across to the next slot in the hotbar. This effect happens in either direction.
As of 18w21a, the mouseWheelSensitivity option addresses the hotbar scroll speed, but inventory scroll speed is still too fast. However, it is no longer as fine-grained as shown off in the 2 attached screenshots.
18w01a changed how scrolling works. Trying to scroll through hotbar slots is often unsuccessful now. Scrolling in the creative inventory is now very fine-grained, to the extent that it is now possible to change item lines without changing the position of the slider, see attached screenshots.
Scrolling, as observed in the creative menu, doesn't scale linearly with physical scrolling speed either.
I also attached a forced crash report for system info.
Note that this is different from
MC-122641, which was introduced in an earlier snapshot.Likely caused by the fix for
MC-122053.From the comments:
I have been doing some more testing on this issue. My setup is on MacOS 10.13.3 and a Logitech MX Master Mouse with the mouse wheel in "click-to-click" mode (i.e. you can move the mouse wheel one "notch" at a time with feedback.)
Prior to 18w01a, if you were to move the mouse wheel one notch on the hotbar, the selector would move across one slot for each notch.
Since 18w01a, it takes 10 individual notches to register the mouse moving across (it will move over on the 10th notch.) I have tested this by counting the number of individual notched scrolls before the selector will move across to the next slot in the hotbar. This effect happens in either direction.
As of 18w21a, the mouseWheelSensitivity option addresses the hotbar scroll speed, but inventory scroll speed is still too fast. However, it is no longer as fine-grained as shown off in the 2 attached screenshots.
relates to
is duplicated by
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
Mod NoticeAdjust the new mouseWheelSensitivity option that has been added to .minecraft/options.txt
18w01a changed how scrolling works. Trying to scroll through hotbar slots is often unsuccessful now. Scrolling in the creative inventory is now very fine-grained, to the extent that it is now possible to change item lines without changing the position of the slider, see attached screenshots.
Scrolling, as observed in the creative menu, doesn't scale linearly with physical scrolling speed either.
I also attached a forced crash report for system info.
Note that this is different from
MC-122641, which was introduced in an earlier snapshot.Likely caused by the fix for
MC-122053.From the comments:
I have been doing some more testing on this issue. My setup is on MacOS 10.13.3 and a Logitech MX Master Mouse with the mouse wheel in "click-to-click" mode (i.e. you can move the mouse wheel one "notch" at a time with feedback.)
Prior to 18w01a, if you were to move the mouse wheel one notch on the hotbar, the selector would move across one slot for each notch.
Since 18w01a, it takes 10 individual notches to register the mouse moving across (it will move over on the 10th notch.) I have tested this by counting the number of individual notched scrolls before the selector will move across to the next slot in the hotbar. This effect happens in either direction.
is duplicated by
is duplicated by
![[Mod] Pokechu22](../../../data/avatars/users/92931.png){kind=small}
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
Same OS as Dustin. (macOS High Sierra 10.13.6)
My Mouse is a Mad Catz Rat 5 (From before they went out of business). I did not have this issue on 1.12.2 and I am unable to fix this issue the way most people have because I do not have a logitech mouse, and in options.txt mousescrollwheel is already set to 1. For my scroll wheel every click counts as a scroll (Click Mode)
relates to
![[Mod] Asteraoth](../../../data/avatars/users/92886.png){kind=small}
is duplicated by
MacOS only
Weird scrollingbehaviorstarting in 18w01aScrolling the hotbar on mac behaves weirdly starting in 18w01a
Mod NoticeAdjust 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.
18w01a changed how scrolling works. Trying to scroll through hotbar slots is often unsuccessful now. Scrolling in the creative inventory is now very fine-grained, to the extent that it is now possible to change item lines without changing the position of the slider, see attached screenshots.
Scrolling, as observed in the creative menu, doesn't scale linearly with physical scrolling speed either.
I also attached a forced crash report for system info.
Note that this is different from
MC-122641, which was introduced in an earlier snapshot.Likely caused by the fix for
MC-122053.From the comments:
I have been doing some more testing on this issue. My setup is on MacOS 10.13.3 and a Logitech MX Master Mouse with the mouse wheel in "click-to-click" mode (i.e. you can move the mouse wheel one "notch" at a time with feedback.)
Prior to 18w01a, if you were to move the mouse wheel one notch on the hotbar, the selector would move across one slot for each notch.
Since 18w01a, it takes 10 individual notches to register the mouse moving across (it will move over on the 10th notch.) I have tested this by counting the number of individual notched scrolls before the selector will move across to the next slot in the hotbar. This effect happens in either direction.
Analysis
See this comment and this longer write-up.
is duplicated by
is duplicated by
relates to
is duplicated by
is duplicated by
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
[Mojang] Grum (Erik Broes)![[Bot] Piston](../../../data/avatars/users/31202.png){kind=small}
Mod NoticeIn 1.14 (starting in Pre-Release 2)
In Mouse Settings, toggle "Discrete Scrolling" and set the sensitivity back to 1.
In 1.13 (starting in 18w21a)
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.
18w01a changed how scrolling works. Trying to scroll through hotbar slots is often unsuccessful now. Scrolling in the creative inventory is now very fine-grained, to the extent that it is now possible to change item lines without changing the position of the slider, see attached screenshots.
Scrolling, as observed in the creative menu, doesn't scale linearly with physical scrolling speed either.
I also attached a forced crash report for system info.
Note that this is different from
MC-122641, which was introduced in an earlier snapshot.Likely caused by the fix for
MC-122053.From the comments:
I have been doing some more testing on this issue. My setup is on MacOS 10.13.3 and a Logitech MX Master Mouse with the mouse wheel in "click-to-click" mode (i.e. you can move the mouse wheel one "notch" at a time with feedback.)
Prior to 18w01a, if you were to move the mouse wheel one notch on the hotbar, the selector would move across one slot for each notch.
Since 18w01a, it takes 10 individual notches to register the mouse moving across (it will move over on the 10th notch.) I have tested this by counting the number of individual notched scrolls before the selector will move across to the next slot in the hotbar. This effect happens in either direction.
Analysis
See this comment and this longer write-up.
relates to
is duplicated by
Duplicate of MC-123773
See MC-123773.
Duplicate of MC-123773. Due to 1.13 updating to LWJGL3, Minecraft receives mouse input differently. There is a setting in options.txt you can use to adjust the sensitivity of the scroll wheel.
Thank you for your report!
However, this issue has been closed as a Duplicate of MC-123773.
Please search before reporting, as it's likely that one exists already.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – ?☃DCD6 Game Wiki
Thank you for your report!
However, this issue has been closed as a Duplicate of MC-123773.
Please search before reporting, as it's likely that one exists already.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – 📖 Game Wiki
Please check if adjusting the new mouseWheelSensitivity option that has been added to .minecraft/options.txt fixes the issue, see MC-123773
Thank you for your report!
However, this issue is a Duplicate of MC-123773.
If you have additional information, please add it to that report.
Please search before reporting, as it's likely that one exists already.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – 📖 Game Wiki
See MC-123773.
It is a known issue see MC-123773.
See MC-123773.
![[Helper] Lord_Quadrato](../../../data/avatars/users/26105.png){kind=small}
Thank you for answering, Jeremy Clouse. This issue has already been reported as MC-123773.
![[Mod] bemoty](../../../data/avatars/users/50554.png){kind=small}
Code analysis:
I assume that macOS automatically changes from vertical scrolling to horizontal scrolling while shift is held (which I have not investigated, but presume to be the case). I also assume that it just does that by putting data in scrollingDeltaX instead of scrollingDeltaY (again unconfirmed but plausible), without indicating it any other way (I looked at the documentation and don't see anything about this). (I don't see any code in GLFW that manually implements shift swapping it, and from what I've heard this is normal behavior in other applications). Someone who actually uses a mac should confirm this.
LWJGL 3
GLFW takes a mouse event and sends it to the callback without doing any special processing (related to vertial/horizontal scrolling, at least). LWJGL 3 simply directly passes this data to the game (via a GLFWScrollCallbackI), which the game then uses like this (based on the 1.14-pre2 code where MC-123773 is fixed with the addition of discrete scrolling, and obviously code abbreviated):
private void scrollCallback(long handle, double xoffset, double yoffset) { if (handle == Minecraft.getInstance().mainWindow.getHandle()) { double delta = (this.minecraft.gameSettings.discreteScroll ? Math.signum(yoffset) : yoffset) * this.minecraft.gameSettings.mouseWheelSensitivity; if (this.minecraft.currentScreen != null) { // Scroll GUIs this.minecraft.currentScreen.mouseScrolled(delta); } else if (this.minecraft.player != null) { // ... eventually use delta to scroll the hotbar or spectator stuff ... } } }
Note that this code only uses yoffset, not xoffset.
LWJGL 2
LWJGL 2 only provided a single interface for mouse events (and it did not use callbacks). LWJGL only exposes a Mouse.getEventDWheel function (and a separate non-event version, which MC did not use). Note that it does not distinguish between horizontal and vertical scrolling at all. MC interacted with actual scroll events in a very similar way (though it did not care about the magnitude at all at that time).
The actual code LWJGL 2 uses to get scroll data is not pleasant. The code it uses to get native scroll events is fairly sane, though note the parameters [event deltaX], [event deltaY], 1.0f. Those are passed to MacOSXNativeMouse.mouseMoved, where dx is deltaX, dy is deltaY, and dz is 1.0f. This function checks if dz is nonzero, and then treats it as a scroll event (basically, dz really should be a boolean isWheelEvent or something instead of the chaos it is now). That function then decides which value to use as the scroll magnitude; it uses dy (vertical scroll) normally, but if that's 0 it instead uses dx (horizontal scroll). That value is then converted to the same scale used on windows, and queued for access via the mouse event system. This workaround was specifically added to handle scrolling while shift is held on mac.
In comparison, other OSs do not have such a workaround. Linux mouse wheel input works by treating wheel up and wheel down as additional buttons (see XCB_BUTTON_INDEX_4 and XCB_BUTTON_INDEX_5 in xcb_grab_button(3), and doesn't do anything with horizontal motion. Windows mouse input only listens for WM_MOUSEWHEEL and not WM_MOUSEHWHEEL, which again means it only gets vertical scrolls. (I can say empirically that windows does not randomly decide to start sending hwheel messages for vertical scrolls when shift is held, and I'm pretty sure it's the same for linux but I haven't confirmed it).
Fix
The LWJGL 2 code could simply be replicated in the callback, only applying to macs:
private void scrollCallback(long handle, double xoffset, double yoffset) { if (handle == Minecraft.getInstance().mainWindow.getHandle()) { double offset = yoffset; if (Minecraft.IS_RUNNING_ON_MAC && yoffset == 0) { offset = xoffset; } // ... same as before, using offset ... } }
However, it probably would be better to only do this when being used to control the hotbar or such, and not for GUIs (which possibly could make separate use of the horizontal scroll).
The one danger of this is picking up incorrect horizontal scrolls (e.g. if the mouse wheel is just brushed sideways). I don't think that's likely to cause much of a problem, though, since it worked that way in 1.12 and earlier without much issue.
EDIT: Amended to note differences in LWJGL 2 on other platforms; only mac had this weird horizontal scroll workaround. (I guess apple just likes weird scrolling logic...)
By the way, for the fun I tried a random alpha build and this bug isn't in alpha v1.2.1_01. MC-123773 isn't even there either. So the « because of Apple » BS could really be dropped.
I've been busy lately, which is why I haven't replied. Thanks for looking into those. Quartz in particular seems interesting, though it sounds like it's primarily intended for writing accessibility software, e.g. on-screen keyboards (in that it looks like it can be used to send key events as well as receive them); that doesn't mean it won't be usable though. I'll have to look into it further when I have time and access to a mac.
And I guess I should clarify: it's not only an apple issue, but more a "apple does something different, and code that makes some assumptions about input doesn't work right". Specifically for the alpha build you referenced: MC-123773 wouldn't apply since scroll input was only used for the hotbar and that ignored scroll amounts; I don't think there were any scrollable GUIs back then. (I might be wrong here.) The issue came along when during 1.13, mojang started using the scroll amount value, because that seems reasonable for scrollable GUIs – scrolling faster should jump further. But on macOS, the amounts have rather extreme acceleration (from all input sources I could find – and, there might be a better input source, but I don't know of it yet and haven't looked into the things you mentioned).
For this issue: it doesn't exist in Alpha 1.2.1_01 not because it didn't exist when that version was released back in November 2010, but instead because Mojang uses LWJGL 2.9.1-nightly-20130708-debug3 (July 2013) or 2.9.0 (April 2013) for it in the launcher, and those have a workaround for the issue in it. I'm not completely sure why they use that version of LWJGL, but it was a semi-common practice to manually update LWJGL back in the day (info on this is still partially on the wiki) so presumably Mojang grabbed a more recent version to work around bugs like this.
When scrolling through the hotbar with the mouse I get a skipped slot every three slots like
so: 1-2-4-5-7-8...
According to MC-123773 this should be fixed with "Discrete Scrolling" enabled, but that option doesn't change anything.
Playing with the sensitivity leads to different results but nether one where one "click" of the wheel matches one move on the hotbar.
evtest reports the following consistent for each "click"::
Event: time 1568458547.186289, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
Event: time 1568458547.186289, type 2 (EV_REL), code 11 
, value -120
Event: time 1568458546.668323, type 2 (EV_REL), code 8 (REL_WHEEL), value 1
Event: time 1568458546.668323, type 2 (EV_REL), code 11 , value 120
Fn key issue: MC-121389
Scrolling issue: check moderator note in MC-123773
As for the rest, please make sure you have the software installed for your mouse, and see if changing the settings as outlined in AntVenom's video fixes the issue.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – ✍️ Feedback and Suggestions – 📖 Game Wiki
![[Bot] Arisa](../../../data/avatars/users/43007.png){kind=small}
Thank you for your report!
We're tracking this issue in MC-121772 and MC-123773, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – ✍️ Feedback and Suggestions – 📖 Game Wiki
– I am a bot. This action was performed automagically! Please report any issues in Discord or Reddit
I'm playing Minecraft 1.16.3 on MacOS and using a Logitech mouse with smooth scrolling enabled in Logitech Options.
When scrolling through the Hotbar, one "tick" of the scroll wheel will scroll through multiple items, instead of just one like the intended behavior.
This issue was reported before in MC-123773 and the described solution was to enable discrete scrolling and set scroll sensitivity to 1, but that solution no longer works.
Disabling smooth scrolling in Logitech Options will solve this issue, but the solution provided in MC-123773 should have fixed the scrolling issue without necessitating this approach. I also cannot set a custom profile for Minecraft in Logi Options because the instance of Minecraft does not run in .app format.
In short, the solution prescribed in MC-123773 to fix Hotbar scrolling to the correct "1-item-per-tick" behavior no longer works.
I have been doing some more testing on this issue. My setup is on MacOS 10.13.3 and a Logitech MX Master Mouse with the mouse wheel in "click-to-click" mode (i.e. you can move the mouse wheel one "notch" at a time with feedback.)
Prior to 18w01a, if you were to move the mouse wheel one notch on the hotbar, the selector would move across one slot for each notch.
Since 18w01a, it takes 10 individual notches to register the mouse moving across (it will move over on the 10th notch.) I have tested this by counting the number of individual notched scrolls before the selector will move across to the next slot in the hotbar. This effect happens in either direction.
Confirmed for 18w20b. This one is a real nuisance for Mac users.
Confirmed for 18w20c
Confirmed for 18w20c mac user, it starts since the first snapshot. It was fine in 1.12
Resolving as fixed and making a separate ticket for creative inventory non-linear scrolling.
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.txtGot 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.
Leonov, Like [Mod] Pokechu22 said above:
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-6436for 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) :
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:
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.
Timothy Miller'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:
MC-122053by 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)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.
Leonov: Great, thanks for checking. I'll update the mod note comment about it.
LogicalGeekBoy: 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).SeeMC-121772(which for some reason wasn't linked as related to this report; I've linked it now.)Issue of this ticket has been resolved perfectly.
About the "not able to scroll while sneaking issue": This is not related to sneaking, but to pressing any shift button. And it only occurs when scrolling using a mouse wheel, not when using a trackpad though.
Hi. I have this exact bug. I'm on MacOS Sierra. I have the issue in 1.13 and 1.14, but not in 1.12.2. I've tried the supposed fix but it doesn't work. I still have the bug, and the bug makes the game pretty much unplayable. I would really appreciate if there could be an actual fix for this bug. I feel like because it says it is fixed, the developers are no longer trying to fix it, when in fact it still needs to be fixed.
Same situation for me. In my opinion, this is not a "resolved" issue.
I don't find this as a resolved issue but only a hack. Also, if we play different versions of Minecraft, settings a reseted, therefore the scrolling sensitivity setting too.
Enabling "Discrete Scrolling" should match the behavior prior to 1.13 (of only using the magnitude of the scroll event, and ignoring the value). And this being a thing that can be toggled makes sense, as on most platforms this kind of scrolling works sanely.
Downgrading versions is not, and never has been, supported. If you want to use multiple versions, set up multiple game directories.
Just to verify: if you are still experiencing hotbar scrolling issues in current versions of the game, what is "Discrete Scrolling" set to, and what is "Scroll Sensitivity" set to?