Zwip-Zwap Zapony

Confirmed for 1.16 Release Candidate 1.

Confirmed for 1.16 Release Candidate 1.

A long instead of a float is not a perfect option either. That'd disallow fractional world border sizes, making it so that you can't use 10.5 as a world border size, only 10 or 11.

Confirmed for 1.14.4.

Confirmed for 1.14.4.

Additionally, this (things re-triggering on the keyboard and only triggering once on the mouse) also applies to every control in the "Gameplay" category, every control in the "Inventory" category, the "Open Chat" and "Open Command" controls (observable when setting them to Enter, as that then tries to send a message and re-closes the chat bar, allowing it to be re-opened), and the "Toggle Cinematic Camera" and "Toggle Perspective" controls. (Not "Toggle Fullscreen", though.)

It also sort of, but not fully, applies to opening the pause menu, as pressing Escape to close it and then holding it will soon re-open the pause menu, but holding Escape will not re-close the menu to let it re-re-open the menu.

In the case of the "Open Inventory" control (due to the background repeatedly dimming and un-dimming) and the "Toggle Perspective" control (due to the camera potentially flickering between looking at a dark floor and a bright sky), this can be epilepsy-inducing! That's bad (and doesn't really serve any positive purpose anyway)!

In the case of the other controls, it's still annoying that a control does different stuff based on whether it's bound to a keyboard key or a mouse button, and also whether or not a different (even if unbound) keyboard key was pressed while a control was held.

This did not happen in 1.12.2, which was the last version to use LWJGL 2. This started happening in 17w43a (the very first 1.13 snapshot), which was the first version to use LWJGL 3, so this is likely due to the upgrade from LWJGL 2 to LWJGL 3.

I'm guessing that this happens due to the game checking if a control is "pressed" (which an operating system re-triggers for keyboard keys, depending on how software checks it?), not if it's "held now when not held the previous frame".

TL;DR: Confirmed for 1.14.4 (and any other version using LWJGL 3), and this is not specific to "Use Item", but instead to almost any control for which it'd make sense to only allow a single input/action per press.

I'm already aware of MC-122532. I actually linked to it in the description of this issue report, even saying that that issue is considered "working as intended" myself. A bed being a tile entity being intentional does not make a bed not rendering past 64 blocks away being intentional, however.

Yes, beds being tile entities may be "working as intended", but the issues that are a result of that (including this one) are not, and beds don't really have to be tile entities anymore (even if that's currently "working as intended").

No, this does not work as intended. MC-3336 is about tile entities not rendering from 64 blocks away... but there really is no reason for beds to be tile entities anymore as of Minecraft 1.13, and they were not before Minecraft 1.12 (meaning that beds could be seen from over 64 blocks away before Minecraft 1.12, and I really don't think that beds were intentionally made to not be rendered from 64 blocks away in that version specifically for the purpose of not being rendered from 64 blocks away).

This is a regression (is that the right word?). Beds rendered past 64 blocks away before version 1.12. In version 1.12, a change was made to beds, which caused a side-effect of beds not being rendered past 64 blocks away. In version 1.13 and beyond, that change is not even necessary anymore, but is still present and has multiple issues as a result.

As beds being invisible past 64 blocks away is a side-effect of a change that's no longer necessary, this is not working as intended.

This issue has been considered a duplicate of a different issue. I see that that is actually correct, as when I searched for issues, I searched for stuff relating to beds being invisible from a distance, not beds being rendered as entities, as I did originally intend to only report that as an issue, but found/thought of the other issues that I mentioned while I was writing this report.

Should I instead separately report the first, third, and fourth issues that I mentioned? They are all clearly unintentional, but their cause ( MC-122532 ) is already reported and "working as intended". (The second issue that I mentioned has already been reported.)

It may be worth noting that I have launched snapshot 18w43c several times, and have not noticed the issue in that version yet. This might possibly be fixed for version 1.14, though I haven't tested whether I still experience it in version 1.13.1 (nor 1.13.2).

(Edit: I tried to show the issue to a friend, and) it seemed like it was fixed in Minecraft 1.13.1 for a brief moment, then I booted Minecraft 1.13, where the issue happened again, and then I tried Minecraft 1.13.1 again... and the issue happened once more, even though it didn't just a few minutes ago? It seems like rebooting Minecraft enough times and getting lucky might solve it, but only until rebooting Minecraft again. So ignore that I removed 1.13.1 as an affected version.

TL;DR: It seems that the issue might occasionally not happen, but it still usually does.

I also experience this with version 18w30b, the currently-latest snapshot. I have confirmed this to also happen for me with snapshot 17w43a, the very first 1.13 snapshot.

This leads me to believe that this might be related to LWJGL, as 1.12.2 uses LWJGL 2 (a "nightly" build of LWJGL 2.9.4), while 17w43a and beyond uses LWJGL 3 (LWJGL 3.1.2 for MC 17w43a, LWJGL 3.1.6 for MC 1.13).

If there's a way for me to make MC 1.13 use LWJGL 2 for me to confirm if LWJGL 3 is indeed the issue, please let me know. I can't seem to figure that out on my own.

Updated to graphic driver version 398.36 using NVIDIA GeForce Experience, rebooted my computer, and tested it again. I still have the issue.

Forced crash report has been attached.

Personally, I feel it's a bug (or rather, wrong and unintentional) that it now doesn't cause damage. Seriously, just standing on top of it without moving hurts you (and it should remain that way), but jumping up and down (while crouching) shouldn't?

This still happens in 1.10.2. The issue is that ladders are solid, and the hitbox detection upon being placed accounts for when it's facing north (or when it's facing south?), regardless of what direction it's actually going to be facing when placed. (I did not look at the code, this assumption is just from lots of testing.)

This means not only can you wind up being unable to place a ladder due to occupying the space of the north- (or south?-) facing hitbox, but also being able to place a ladder when you're right up against the wall you're placing it on, due to not occupying the space of the north(/south?) hitbox.

How is a pretty big inconsistency between glass (of a beacon) and glass (of a glass block) not a bug, and wanting glass and glass to be consistent is a feature request? All kinds of glass blocks (both normal glass blocks and all stained glass blocks) cull themself. Why should the glass of a beacon be any different?