Wormbo

Maybe as a general advice: If you test something that has only a 1 in 200 chance to pass a random tick test, use multiple instances of the thing you are trying to test. Even high random tick rates can hit random blocks very infrequently.

I just tested in the nether and confirm eggs do advance their hatching progress, it’s just very slow. This is after a couple of minutes at random tick speed 1000.

This is not related to game difficulty, the same spawn egg spawned the adult mod I attempted to use the spawn egg on afterwards.

@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.