clamlol

Can confirm with /give @s golden_apple[minecraft:use_effects={can_sprint:false,speed_multiplier:0.1}], but I agree that this seems like a duplicate.

I’m almost certain this is intended, the world keeps ticking until the player is fully dead.

Edit: I only tested with igniting the creeper with a flint and steel. I understand the argument that if a creeper hasn’t been forcibly ignited it should refrain from exploding if there are no living targets in range, so in that sense the classification of this as a valid bug makes sense.

To my knowledge this behavior is quite longstanding, but I reported it as a bug rather than as feedback because in my mind it goes against what sneaking is intended to do, namely allow players to move safely to the edge of a block and navigate along that edge. That said, I would understand if this is in the same boat as MC-929 where an issue is so longstanding that a fix request becomes a change request.

Can comfirm using the MC-302818 setup but with a single-biome plains world. For what it’s worth, I don’t really consider meadows a plains variant since they’re alpine in nature.

Can confirm, but your modded screenshots are invalid and will be removed.

The lack of this information is probably intended. Players arguably should not care about the number of in-game days that have passed on the server, since it is usually a large number and could be used as a proxy for server uptime. Additionally, given that local difficulty historically displayed inaccurately (MC-230732) or not at all (MC-265425) it would seem that Mojang does not feel it is important for server players to have access to this information, perhaps because local difficulty could be used as a proxy for chunk activity, although this arguably should not apply to server operators. Also, if they were to simply re-add the line, there would be flickering in the debug screen when crossing a chunk border due to MC-299755, which Mojang does not wish to fix.

I would suggest “Leaf Block Transparency” or, conversely, “Opaque Leaf Blocks”.

As far as solving the issue goes, first things first, check your Minecraft output and upload the log here if contains any errors. If not, the only thing I can recommend is to set up a new user for your computer, install Minecraft there and test it out. If it works, re-add your various utilities and such from your main user one by one until you find the culprit. If not, there is most likely nothing that can be done and this report will eventually be closed as Cannot Reproduce unless someone else can offer insight as to what the cause may be.

Please do not make duplicate reports. The reason no one responded to your previous one is because there is not enough information that would enable anyone to reproduce the issue and conclude that it is a bug with the game. These kinds of reports are often closed as invalid because they are apparently technical issues rather than bugs.

This report will be resolved as a duplicate of your previous one. See the linked report for how to proceed from here.

Can confirm. This was probably an intentional removal that they forgot to list in the changelog, since you can get all the needed information just by going to the key binds screen now.

I do not believe use_cooldown is intended to affect the time the shield is disabled for. If there is a bug is that the shield is not placed on cooldown after it is lowered, as the spyglass is (unless you switch away from it, which is another bug). Nevertheless I can reproduce this so I will confirm and retitle the issue.

This also affects the case where the player is attempting to sneak on the edge of a lava lake, possibly to hit a mob or interact with a block on the other side of it. Depending on how deep the lava they’re sneaking over is, the player may fall into it, and since they have no way of knowing for sure whether that will happen, they may be compelled to build a bridge or take an alternate path even when it was not necessary. This risk of death and modification of gameplay habits is very undesirable, since a higher step height is widely though of as a strict mobility buff.

The solution is to hardcode the “maximum step off when sneaking” height to 0.6. A gamerule, or even a client setting, to restore the current behavior could be interesting, but in practice I suspect hardly anyone would prefer to use it.

(The command for those boots is below. It requires a command block due to its length.)

/give @p diamond_boots[minecraft:custom_name="Diamond Boots of Superior Walking",minecraft:attribute_modifiers=[{type:"minecraft:armor",slot:"feet",id:"vanilla_armor",amount:3d,operation:"add_value"},{type:"minecraft:armor_toughness",slot:"feet",id:"vanilla_toughness",amount:2d,operation:"add_value"},{type:"minecraft:step_height",slot:"feet",id:"boots_modifier",amount:0.5d,operation:"add_value"}]]

Can confirm, added repro steps which avoid spamming the chat

This is already being tracked in MC-272769

I can’t reproduce this, although that may be because my display is quite high-resolution and I can’t actually get Minecraft to render with an odd horizontal resolution. You’re sure that this issue only occurs with such a resolution, and that it does not occur in 1.21.10?

This seems to be the result of the min_reach and max_reach fields for the kinetic_weapon component overriding the creative mode attack range buff (and generally, any deviation from the default entity_interaction_distance attribute). I wonder what the best way to structure a fix for this is…

This is already being tracked in MC-302672

This is already being tracked in MC-302672