Denver Leman

While it may be that framework that is causing it, Every single app, every single browser, every single event on mac, regardless of the program or use converts Shift and Vertical Scroll to Horizontal Scroll, sem Minecraft. As this isn't a forum, and I just confirmed this fix, I won't be comment further, unless it relates to my confirmed fix.

After building, and testing, the suggested code above, I can comfirm that it does in fact work with the game. Now, that is of course assuming that Mojang have not changed the way scrollCallback is coded since 1.16.4.

It is not related to LWJGL at all. I can run an instance of minecraft creating a new GLFWscrollCallBack(), and both the x and y offsets perfectly record, even if both are used at the exact same time. It is not LWJGL that stops mac users from shifting and scrolling, it is Apple, themselves. Apple, quite simply, says that when Shift+MainScroll happen at the same time, HScroll instead, which is the input that Java is receiving. Java gets the right input, it is the OS that it sending that input incorrectly/no intuitively. Weather or not it adds the xoffset to the y offset, or it replaces it, either way, it will fix it, and both would require almost the exact same amount of code to fix.

I believe this has a very quick fix. Minecraft code is ignoring the scrollCallback xoffset completely in its MouseHelper file, naturally, so, there is no reason why the following can not be done ...

It is currently like this ...

private void scrollCallback(long handle, double xoffset, double yoffset) {
...
double d0 = (this.minecraft.gameSettings.discreteMouseScroll ? Math.signum(yoffset) : yoffset) * this.minecraft.gameSettings.mouseWheelSensitivity;

and could look like this, which would affect no one at all except for mac users, and changes 0 functionality in game that I can see.

...
+ import net.minecraft.util.Util;
...
+ public static final boolean IS_RUNNING_ON_MAC = Util.getOSType() == Util.OS.OSX;
...
private void scrollCallback(long handle, double xoffset, double yoffset) {
...
+ if (IS_RUNNING_ON_MAC) {
+ double d0 = (this.minecraft.gameSettings.discreteMouseScroll ? Math.signum(xpffset + yoffset) : (xoffset + yoffset)) * this.minecraft.gameSettings.mouseWheelSensitivity;
+ } else {
double d0 = (this.minecraft.gameSettings.discreteMouseScroll ? Math.signum(yoffset) : yoffset) * this.minecraft.gameSettings.mouseWheelSensitivity;
+ }
...

Essentially, the code does an extremely quick check on whether or not the play / client is on a MAC, and then if the client is on a MAC, it adds together both the x and y offsets generated from the glfwSetScrollback.

As there is literally 0 use for the xoffset when tied specifically to d0 on scrollCallback
, and thus is an easy and non game changing/ruining fix.

For those wonderng why this works, it is because Shift and xoffset work together, the scroll horizontally, on all macs, which is hard coded, with not configuration available.

Does minecraft still use LWJGL3? Would a solution not be to take create a GLFW callback for the scroll, and detect/convert the xoffset into the yoffset?

glfwSetScrollCallback(window, scroll_callback);
void scroll_callback(GLFWwindow* window, double xoffset, double yoffset){}

Can they not just add the two doubles together to produce the correct yoffset, and have that set to be the value of their scroll event? Seems like it would take only a very small handful of code to fix this issue. Even if they are not using this library, but are using their own, it would be just as easy to implement this.

This would also allow users with horizontal scrolls on their mouse to use that to switch inventory slots, which might be a nice addition as well.

This is a bit more detailed of a description of what is happening.

When gravity affect blocks fall on player, player falls through blocks under them. If there is no cave under the player, this means that they will fall through the world, and die in the void. This can happen in all dimensions, and in all world types.

Important note, the player does not have to be directly beneath the gravity affect block, they simply have to be touched by it. Also, the falling block only needs to be 1 high, and can be at eye level.

To recreate, stand under a stone floor with sand on top, and remove the stone, letting the sand or other block fall. You can also walk into a falling sand block or other block, and the same thing happens.

What is expected: player remains in position if block can not push them out of the way, and the plater will take suffocation damage.

Attachments

Thank you. I did search, and looked through over 100 different titles, with keywords, and nothing showed. I used to be able to sort by snapshot, and could not. I was unable to say it was in a snapshot, as it only gave two options, otherwise, I would have posted it in the correct snapshot.

Today I witnessed a creeper magically appear in the middle of the day with full sun and no obstructions.

One is in full screen and one is in a window.

in 14w20b this still happens in fullscreen when accessing multiplayer server. I am also attaching a screen shot!

It would make sense that a daylight sensor would not work at midnight as there would be 0 light coming from the sun.

I guess you are right, it could be a lot more code, but in aall seriousness, it can not be that much to make one texture read as one direction compared to the other. And, it is not listed as a bug. Based on this page RIGHT HERE as you put it, this page is marked as invalid meaning thay are not pursuing it at all. They do not consider it a bug are therefore all resource packs are required to conform.

Yeah, they did, and rather than correcting it, they said that is the way it is supposed to be. So every single resource pack broke because of it. And I guess it is easier to change every single resource pack rather than changing one line of code.

Seems funny that all of a sudden, all the redstone would change like this. It is not just his resource pack, to call it invalid is like saying we changed something and don't want to admit to it. Sorry Mojang, but this is true across multiple resource packs, how much of a difference really did changing the rotation of the image make. Seems silly.

This picture shows my setup, piston will not push at all. Likewise, the second set up will not pull at all. Note even a single block for either.

I have a slime block in front of a piston in a world covered by half slabs, so 1/2 block between slimeblock and slabs. Piston will not attach at all to slime block. It will not push, it will not pull.

Sorry, I tried searching before posting and found nothing, this would appear to be a dup for item frames, but my error is not limited to them, it shows something else as an error as well.

This bug is still accurate. I had created an issue myself for 14w11b. It is still not fixed.

Then you have a bug on your site. My apologies, perhaps the "improvement" type should be removed then from your list of types on your help page presented by clicking the ?. As it is misleading. I will add it to the suggestions page.

The file marked Other.zip is the Main world's internal directory without the region folder, the Region.zip is the region folder and needs to be added back into the main directory. They world folder is not in the uplaods so these archives will need to be uncompressed into a folder to make a world.