Wormbo

Still persists in 26.4 snapshot 2.

Funny thing, though: The nether roof mushrooms are not affected by this bug.

Can confirm the values for these slabs still don’t match their base block values. In fact, the 26.3 snapshot code rework for the Blocks class created special methods to retain the “wrong” values.

I’d honestly expect item frames to act more like blocks in that regard rather than cushions not doing so.

Same as sitting in a minecart or riding a horse, really.

F3 should probably show entity data, but until then expect any intentional item frame behavior to also apply to cushions – including not showing up in F3.

Mojang will incur the wrath of the community if they remove this. Also, this seems like an intentional feature, considering this is how you place them inside stairs.

Cushions are essentially mountable item frames. That behavior is to be expected, and definitely better than the alternative this “bug” report implies.

Why would this work as intended? If you breed hoglins (another monster-mobcap mob that despawns by default) the offspring is immediately flagged as persistent as well. It doesn’t make sense the equivalent action for sulfur cubes (i.e. splitting them) would result in a despawn.

Expanding this further, even the witch a villager converts to when struck by lightning is persistent! And that’s not even necessarily a player-caused conversion.

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.