pokechu22

Mojang is still using LWJGL 3.3.3 as of 1.21.4, so that makes sense.

The main cause of this behavior is MC-255057 (continuing to destroy a block only cares if the block that was last targetted is the same as the current block, not if you were still destroying a block).

This was introduced in 14w29a (a 1.8 snapshot), which changed MultiPlayerGameMode.stopDestroyBlock from

public void resetBlockRemoving()
    {
        if (this.isHittingBlock)
        {
            this.netClientHandler.addToSendQueue(new C07PacketPlayerDigging(1, this.currentBlockX, this.currentBlockY, this.currentblockZ, -1));
        }

        this.isHittingBlock = false;
        this.curBlockDamageMP = 0.0F;
        this.mc.theWorld.destroyBlockInWorldPartially(this.mc.thePlayer.getEntityId(), this.currentBlockX, this.currentBlockY, this.currentblockZ, -1);
    }

to

public void resetBlockRemoving()
    {
        if (this.isHittingBlock)
        {
            this.netClientHandler.addToSendQueue(new C07PacketPlayerDigging(C07PacketPlayerDigging.Action.ABORT_DESTROY_BLOCK, this.currentBlock, EnumFacing.DOWN));
            this.isHittingBlock = false;
            this.curBlockDamageMP = 0.0F;
            this.mc.theWorld.sendBlockBreakProgress(this.mc.thePlayer.getEntityId(), this.currentBlock, -1);
        }
    }

i.e. prior to that version, if a block was no longer targetted, then the break progress would be reset to 0, making things mostly behave normally (though it still would fail to tell the server that it started breaking the block, and redstone ore wouldn't begin to glow in this case).

I'm not sure why this change was made. The only relevant issue fixed in 14w29a is MC-676, but I don't think this change was directly part of that fix. So perhaps it was an intentional change, but it wasn't included in the changelog and is implemented fairly awkwardly.

Based on a discussion in #mcdevs on around September 11 2024, this was probably fixed in 1.19.4/23w03a due to the packet bundle feature (mentioned on https://www.minecraft.net/en-us/article/minecraft-snapshot-23w03a), which should eliminate the chance of an item spawning and then the entity metadata getting processed on the next tick. I haven't had any time to do any testing, though, so I'm marking this issue as Awaiting Response for now.

(The issue in #mcdevs was with someone who was implementing a custom server from scratch, and having items always disappear when dropped from breaking a block. They determined that their issue started happening in 1.19.4, and the issue went away when they implemented packet bundles. So presumably the code that removes items that have no entity metadata still exists, but hopefully packet bundles prevent it from being an issue with the official server software.)

The issue as I understand it is that individual letters don't show up depending on where they are even when there's direct line of sight to the player. The whole name tag not being visible when the player is behind blocks is separate behavior (which seems unlikely to be changed by this fix).

Perhaps there's a situation where part of the nametag is visible but other parts are behind blocks that might be affected (or a long name tag peeks through the corner of two blocks, revealing a player that otherwise is hidden), but those seem like much more niche situations.

I don't have any good method of reproducing this. The issue still exists in 1.20.2 as it still used a VarInt instead of an OptVarInt then (see https://pokechu22.github.io/Burger/1.20.2.html#entities:guardian), but entity metadata broke in Burger for 1.21 (see https://pokechu22.github.io/Burger/1.21.html#entities:guardian) due to other internal changes so I can't directly confirm it.

I believe even in 1.15.2 this was not directly reproducible due to entity IDs starting at 1, and entity IDs would need to overflow for that to happen. That used to be a much bigger issue as mob spawning would use up an entity ID for each attempt at spawning an entity, even if it was rejected, so it was possible for it to go through all 4 billion values eventually on a long-running server, but I believe that was changed a while back (I don't remember when) and no longer happens. Otherwise it's mostly an easily avoidable gotcha with the protocol that would come up with e.g. custom servers.

GLFW merged the change to fix RDP at https://github.com/glfw/glfw/pull/2431 (I'm pretty sure it's included in the GLFW 3.4 release). LWJGL hasn't yet updated to the new GLFW version as far as I can tell though, so Mojang can't update to a new LWJGL version to fix it just yet.

I'm pretty sure the that this was fixed in 1.12 (in that I tested it and confirmed that "Kicked for Spamming" shows up). I also can confirm that there is a disconnect.spam translation key (and I'm pretty sure if that existed in the past too, it just wasn't being translated).

If this has started occurring again in more recent versions, it'd be better to create a new ticket, as it probably regressed due to something else. If I instead messed up with my testing and it also occurs in 1.12, I can reopen this ticket.

Can confirm, seems to be present in 1.20.1 and fixed in 23w31a looking at code (I haven't attempted to do anything with wireshark or similar to verify that way though)

hopper.minecraft.net as a service no longer exists, so this issue no longer applies. It used to be a crash report analysis system, and loading the given link would show more info about a specific crash. However, it was retired a long time ago, and the troubleshooting documentation that was also hosted on it was relocated to the third-party site https://minecrafthopper.net/.

Here's an archived example. It turns out that this one is also an example of this bug, although this report was in multiplayer instead of singleplayer so it is less obvious if the server was modded or not.

In any case, hopper itself is long gone, so this issue no longer applies.

My thought on this is that it is stupid behavior on OSX that scrolling while shift is held is always reported as horizontal scrolling, rather than this being application-defined behavior (that would be part of the standard UI widgets that applications use). From what I remember from my research several years ago, there isn't any way to opt out of that (and, if I recall correctly, it applies even if you have a mouse that also has horizontal scrolling built in, where the shift behavior is redundant). (I'm also not an apple developer, so maybe there's some advanced/poorly documented API that can be used for this. But I wasn't able to find one when I looked for it back then.)

On the other hand, you definitely can work around the issue; older versions of Minecraft used LWJGL 2, which didn't expose horizontal scrolling to games, and also converted horizontal scrolls to vertical scrolls which worked around the issue. 1.13 switched to LWJGL 3, which does separately report horizontal and vertical scrolling. The issue could still be worked around by still using the same horizontal-to-vertical conversion (at least for the hotbar), but that also means that actual horizontal scrolling would scroll the hotbar. (I also vaguely recall that there was some oddness with horizontally scrolling left and right being backwards compared to scrolling up and down, i.e. it wouldn't be possible to have scrolling left select the item to the left but scrolling up having the same result as scrolling up while holding shift. I'm not 100% sure that's actually the case, though; please do let me know if that's not an issue with the previously mentioned workarounds.)

Duplicate of MC-71750 - the glowing effect is implemented with a shader (and that shader isn't special compared to the shaders that are used when spectating mobs (creepers/spiders/endermen)). That issue is resolved as invalid because the fboEnable option was removed in Minecraft 18w44a (a 1.14 snapshot), so both it and this issue no longer apply to current versions.

The wiki is referring to the falling block entity and what happens when you use /summon with one for a cactus (e.g. /summon minecraft:falling_block ~ ~40 ~ {BlockState:{Name:"minecraft:cactus"},Time:1}), not a dropped item. That said, the information on the wiki was wrong; sand and gravel convert to items (which are then often destroyed) which is the same as a summoned falling cactus. I've edited it to make it clearer.

The behavior with items (which is what you'd get with the setup in the screenshot) being destroyed by cactus is different, and is covered by MC-3532.

This issue seems to have been introduced in 1.16-pre5 when MC-180867 was fixed. That version added the following code to JukeboxBlock.setPlacedBy (as noted by @unknown):

CompoundTag tag = stack.getOrCreateTag();
if (tag.contains("BlockEntityTag")) {
  CompoundTag tag2 = tag.getCompound("BlockEntityTag");
  if (tag.contains("RecordItem")) {
    // Update has_record state
  }
}

21w37a replaced that code with this:

CompoundTag tag = item.getBlockEntityData(stack);
// above is equivalent to stack.getTagElement("BlockEntityTag"), which doesn't create tag if there is no tag
if (tag != null && tag.contains("RecordItem")) {
  // Update has_record state
}

I also am able to reproduce the issue in 1.17.1 but not in 21w37a, so I'm marking it as fixed. (MC-180867 also remains fixed.)

The URL-shortened link points to install.sh in https://github.com/GameParrot/minecraft-mac-window-fix/releases/ . Here's the actual script:

curl -L 'https://github.com/GameParrot/minecraft-mac-window-fix/blob/main/mac-runtime-patch.zip?raw=true' > /tmp/mac-runtime-patch.zip
unzip -o /tmp/mac-runtime-patch.zip -d ~/Library/Application\ Support/minecraft/
rm /tmp/mac-runtime-patch.zip
echo 'Successfully installed. To complete installation, set the Java executable to "'"$HOME"'/Library/Application Support/minecraft/mac-runtime-patch/java-runtime-beta/mclaunch" for Java 17, "'"$HOME"'/Library/Application Support/minecraft/mac-runtime-patch/java-runtime-alpha/mclaunch" for Java 16, or "'"$HOME"'/Library/Application Support/minecraft/mac-runtime-patch/jre-legacy/mclaunch" for Java 8.'

which modifies the JRE configuration used by Minecraft (apparently to fix other issues), and also adds a modified ("mofified") version of libglfw.dylib, based on this code apparently, which makes sense for fixing this issue.

However, I haven't done any further auditing or testing (I don't have a mac), so I can't say with 100% certainty that this is a safe fix. On the other hand, this looks like the steps I would take if I were to make and distribute a fix involving a patched library myself (though when I've done that before, the process was slightly more jank, partially because I was targeting windows which didn't come with curl by default at the time).

@Eric Grimes: if you want to test further, try running each line of the script above one at a time, to determine which one is failing.

I'm not speaking on behalf of Mojang here, but I'm guessing it's because the ender dragon has a complex hitbox compared to most entities (look at it with F3+B). With most entities, the bounding box can work the same if the entity is flipped or not. With the ender dragon, they'd need to flip the sub-entities as well so that the bounding boxes are in the right place, which adds a fair bit of complexity, maybe too much for an easter egg feature. (Again, this is just my guess, though.)

If I recall correctly, Mojang reworked some of the SRV record logic in 1.17 for unrelated reasons (I don't know if there's a public report for it), so it seems plausible that it's fixed in 1.17. I don't know the exact version this was changed in, so I'm resolving as "cannot reproduce". (I haven't attempted to test it myself.)

See this comment for more info; it ignores things that change the FOV modifier, but does look at the FOV option value. Judging only from the duplicates, there was also once an issue where it ignored the FOV option value, but I don't know when/if that changed (and I don't want to separate out that behavior into a new issue because I'm not 100% sure it did change).

The sneaking animation is its own issue (MC-148088). I think the aspect ratio problem should also be created as a separate issue (that should be linked to this one).

The experimental snapshots aren't supported on the tracker (the snapshot is only for testing world generation, and I don't think it has any more general bugfixes in it; feedback for world generation can be posted here though), but thanks for checking.

If you no longer wish to receive emails, click "stop watching this issue" near the top right of the report. People commenting on an issue that they are still running into is normal behavior, and 4 comments over over 4 years is not an excessive number.

Note that there is a second ticket that tracks issues with held item models (though there is some overlap): MC-73186