mojira.dev

Lukeonia1

Assigned

No issues.

Reported

MC-127474 Waterloggable blocks retain their waterlogged state when moved with pistons or slime blocks Fixed

Comments

Can confirm. Also works on leaves, grass blocks, melons, and glass, but not stone. Seems any block that drops something when broken by hand will drop its silk-touch equivalent when broken using a Silk Touch book.

Confirmed for 1.14.2, except: Opening and closing a shulker box now triggers an observer twice, once at the beginning of the opening/closing animation and once when it ends. Not sure this is intended.

 

Also need to add to the list, observers do not detect when a solid block becomes powered (or unpowered) by a redstone power source.

Not sure if this is related or a separate bug: I noticed in 18w21a, "natural" water source blocks will not spread horizontally more than one block.

"Natural" sources being those generated with the world, or formed by normal source-block-on-two-sides water mechanics. Source blocks from water buckets, or those containing sea grass, waterlogged blocks, etc are not affected and behave normally. I did a little other testing, and found that a single-block source in a cave was unaffected, but water in a subterranean lake was.

 

[media]

As of 18w21a this appears to be fixed. Cheers!

 

I suspect it also relates to MC-125212.

Confirmed for 1.12.2.

Confirmed for release 1.12. Issue first occurs in snapshot 1.12-pre1 and affects every version after that.

The issue affects any transparent or non-full block placed above vines, such as glass, stairs, torches, ladders, string, chests, etc. Interestingly, it does NOT affect top half slabs or upside-down stairs.

Vines normally attempt to "connect" with the underside of full solid blocks above them (changing the block state "up" to True). If that's not a full block, rather than remaining "unconnected" (block state "up" set to False), the vines are instead deleted and cannot be placed.

The vines CAN be placed below fences, etc. using the /setblock command, but they are immediately deleted when they receive a block update.

I looked more into Fabian's comment above... I guess the problem is "fixed" in that these leaves don't spontaneously decay on world generation, if that's what the original bug report is describing. But the root problem remains, and the leaves will still decay if they receive a leaf-related update.

I'm not entirely sure what "check_decay" is supposed to do? I'm seeing leaves decay with "check_decay" set to False, so it seems to have no effect on whether or not a particular block decays on receiving a block tick.

Assuming this is referring to the same effect, can confirm for 1.10.2. Steps to reproduce:

1) Generate a jungle giant tree, either naturally or from saplings and bonemeal.
2) Place a wood block at the edge of the canopy leaves.
3) Remove the wood block.
4) Wait a few minutes.

The canopy leaves will rapidly decay from the original round shape to a smaller diamond-shaped configuration. I've attached before-and-after pictures of a naturally-generated tree to which I've done the above steps.

EDIT: Fire (such as from lightning) will do the same thing, as will manually breaking a leaf block. Other types of block updates don't seem to have any effect, as Fabian pointed out above.

It appears to be due to the decay rules for leaf blocks. They decay if they aren't connected within 4 blocks of a wood block, but jungle giants naturally generate with canopies larger than that. Hence, they remain in a sort of natural BUD state until they receive a suitable block update that triggers them to decay. Large oak trees are also be subject to this effect, but it's less noticeable due to their irregular shape.

A simple workaround could be to modify jungle giants to generate with wood block "branches" embedded in their canopies. Otherwise, I don't know... Have separate decay rules for jungle leaves?

Confirmed for 1.8.9 as well. Also works on boats, pigs, and horses. I discovered the latter the hard way, lost my favorite horse!