Wormbo

@Tom The resolution (which apparently only is visible when you are not logged in!?) is “Works As Intended”.

Since my comments didn’t make it here: This issue was fixed already, but not mentioned in the snapshot where it happened. I don’t remember the snapshot when it happened, but there was a fix for another leaves-issue with pale oak, and the fix for that apparently also fixed this bug.

Has this been addressed? I just noticed a separate bunch of leaves around a pale oak tree's branch opposite to the direction of the main trunk's bend in 1.21.4, which suggests this was fixed.

[edit] Found some time to check the code, and it seems the error in the calculation of branch leaves attachment locations has indeed been fixed. Presumably that happened as part of the fix for MC-59308?

Pale oaks appear to have inherited this generation behavior.

Somewhat related, keeping the health during conversion seems like a bad change for lightning-based conversions, since the lightning strike itself usually deals a bunch of damage already, making survival of the converted mob less likely than it already is. The change should probably be restricted to non-damaging conversions like drowning zombies or freezing skeletons.

It should probably also be noted that MC-2714  is almost as old as the report about quasi-connectivity behavior for pistons, droppers, and dispensers. The confirmation of the bug status happened over 11 years ago. Consequently, players eventually expected the behavior to stay, regardless of the status of that issue report. This fix didn't seem particularly intentional, considering it was not mentioned anywhere.

Looking at IglooPieces.IglooPiece#postProcess in both 1.20.1 and 1.21, the template position handling feels wrong, but I can't say whether it's actually the cause:
this.templatePosition is being saved to a local variable, then adjusted with a vertical offset, then super.postProcess is called, and at the end of the method this.templatePosition is reset to the original value.

As far as I can tell, there only seem to be two other structure piece types (ocean ruin and shipwreck) that modify this.templatePosition within their postProcess method, but they both do that only before the super.postProcess call and without resetting it again afterwards. Maybe that reset causes the structure information to be serialized with the wrong Y value after placing the blocks.

Can confirm in 1.21.
Diagonal blocks have been a way to force oak saplings to only grow as "fancy oak", i.e. (usually) large oak trees. I'm reasonably sure this behavior has existed for a long time, and currently a very intentional-looking check in the TreeFeature class. The thing that might not be intentional is that trees that generate with vines or other blocks, that are neither leaves nor logs, don't necessarily ignore those block types.

This is specifically about a log blocking light and thus preventing random growth. MC-228758 explicitly excludes logs and also covers bonemeal growth, while MC-15224 is specifically about mismatched log types.
The case presented here causes the sapling to never even have failed growth attempts (which would be visible in F3 debug by its age property changing from 0 to 1), but not even attempting to grow in the first place.

All ores (stone, deepslate, and even nether quartz/gold) have a blast resistance value of 3. That seems wildly inconsistent with most stone variants, deepslate, netherrack, and the individual resource blocks, which all have blast resistance of 6, except netherrack at 0.4 and quartz blocks at 0.8. Even cobblestone and cobbled deepslate have blast resistance 6, so you can't really argue that the mix of ore and base material weakens the combination.

Not a duplicate of MC-266742. That one gives an incorrect description of the issue.

Copper bulbs now change state immediately, without any delay. They were more useful when they had 1 game tick of delay before the state change.

Still happening in 1.20.2 and current snapshots.

IMHO it only makes sense to default to upright placement if the box would "attach" to the block below (i.e. that one has a full top surface) and can be opened. Next best thing would be "attaching" to the dispenser, if that orientation allows opening. And since dispensing a shulker box isn't even a very frequent thing, I don't see why there wouldn't be a more thorough attachment check, similar to what the shulker mob does. Upright placement without being able to open the box should only be a fallback option if it can't reasonably be rotated any other way.

Another example not involving commands: Wither roses apply damage every tick (actual damage every 10 ticks, due to damage immunity) instead of the expected 2 seconds interval for Wither effect level 1. (Tested on 1.20.1, but likely didn't change in newer versions.)

I appear to be getting this on a 1.20.1 server.

Still happens in 1.20.1.

Some additional thoughts on this bug: Fleeing uses pathfinding, and that won't work if the mobs don't have solid full blocks available as potential target locations.

The screenshots by Leo and Alex show a setup where the creepers have nowhere to go beyond the trapdoors, since they can't fit into the 1-high area there or there isn't even a reachable area in the first place. The screenshots by Matthew and Marco shows a similar issue in that there's no solid full block beyond the trapdoor, so while creepers could pathfind towards the trapdoor, they have no incentive to actually go there, since there's no pathfinding target that would make them do so.

From my own tests it looks like creepers flee from cats eventually, and assuming they have somewhere to go, they will also cross trapdoors when doing so. However, it sometimes takes quite a long time until they realize they should flee in the first place, and it seems related to how easily they can find a place to flee to. The same also is true for (wither) skeletons fleeing from dogs. I've seen them sometimes starting to walking to a place beyond the trapdoors instead of running, suggesting they have an easier time to find a random movement goal than to find a place to flee to. (I attached a setup I tested with in 1.18.1.)

Confirmed to still happen in 1.18.1.

It is generally advisable to not use the same game directory for vastly different versions of the game. Not only does the configuration file format change, but also early versions do not protect your worlds from downgrading, which basically destroys them.

Can confirm the behavior in 1.18.1, but I can't necessarily see a reason to call this a bug: Droppers never drop items into the world under any other circumstance when facing an inventory block, even if they can't deposit an item for whatever reason. For example, you can never push a shulker box into another shulker box this way from any side, and you can't push non-fuel items into furnaces from the bottom or sides, and in neither case does the item end up being dropped into the world instead.

Can confirm this still happens in 1.18.1: Nearby blazes get "group aggro" when one is hit, but if they can't see the player, they will just hover up and down in place without ever attempting to reposition in order to actually being able to attack the player. This is different from any other mob with the "group revenge" behavior, as those will still move around to attack.