Falling blocks can land on blocks they're not supposed to
Credit to _MethodZz_ for finding this bug.
The bug
When a falling block slides over a fence or cobblestone wall, it can land on blocks it is not supposed to.
Steps to reproduce
- Build the setup in 2019-02-08_20.04.44.png

- Place a sand block under the observer
→ Notice the sand will land on top of the torch
Furthermore, if there is no torch, the sand will just drop as an item.
Created Issue:
Falling blocks can land on blocks they're not supposed to
Credit to _MethodZz_ for finding this bug.
The bug
When a falling block slides over a fence or cobblestone wall, it can land on blocks it is not supposed to.
Steps to reproduce
- Build the setup in 2019-02-08_20.04.44.png
- Place a sand block under the observer
→ Notice the sand will land on top of the torchFurthermore, if there is no torch, the sand will just drop as an item.
relates to
relates to
In Minecraft 1.13.x a command such as the following would result in the summoning of a falling block, with a passenger of another falling block, with a passenger of another falling block, with the passenger of a minecart command block. When so summoned, the falling block would hit the ground and turn into a solid block (in this case, oak leaves), and it's passenger would land upon it, and also turn into a solid block on top of it (in this case, a redstone block), and it's passenger would land upon it and turn into a solid block (in this case an activator rail), and it's passenger would land upon it (the minecart would land on the activator rail, which is powered because it is on a redstone block, which would cause the command to run). I am testing by running the commands from a command block, so that the falling blocks land on the command block.
summon falling_block ~0 ~3 ~0 {BlockState:{Name:oak_leaves},Time:1,Passengers:[{id:falling_block,BlockState:{Name:redstone_block},Time:1,Passengers:[{id:falling_block,BlockState:{Name:activator_rail},Time:1,Passengers:[{id:command_block_minecart,Command:"say hi"}]}]}]}
Similar commands worked in 1.12 (and 1.11 if modified correctly):
summon falling_block ~0 ~1 ~0 {block:leaves,Time:1,Passengers:[{id:falling_block,Block:redstone_block,Time:1,Passengers:[{id:falling_block,Block:activator_rail,Time:1,Passengers:[{id:commandblock_minecart,Command:"say hi"}]}]}]}
It also worked as expected when entities used the 'riding' tag, a stack of falling sand (as it was called at that time) would correctly fall and stack into a pile of blocks when you summoned a falling sand ridding a falling sand riding a falling sand, etc.
In 1.14, this behavior has changed. The 1.13 command does work in 1.14, but the behavior is completely different. The oak leaves falling block does hit the ground and turn into a solid oak leaves block, however, it appears the the passenger blocks are now lower or are inside the newly landed oak leaves block, and so don't land on the oak leaves block, and don't turn into a solid block. In this case, the redstone block and the activator rail 'pop' off the group of falling blocks as items. Additionally, the command block minecart falls into the oak leaves, as if the oak leaves were pushed down into the mincart by a piston, without being broken by the piston (as would normally happen if a piston attempted to push leaves).
This command, or ones like it, are used by a few external utilities to pack multiple commands into a single command block, by spawing multiple command block minecarts as passengers of a falling block configuration such as the one above, with each minecart containing one of the command to be run. This one summon command can then be run from one command block, but result in the execution of multiple commands, usually with the last few commands deleting the placed blocks and command block minecarts. This can be done better with datapack functions now, but this technique existed and worked from before datapacks existed, and I don't see why it should have stopped working.
This seems to be the opposite of issue MC-143894

Affects 1.16 pre2
Confirmed in 1.16 Pre-release 8.
Affects 1.16.2 Pre-1
Affects 1.16.1
This ticket in progress ~500 days
Can confirm in 20w51a.
625 days and not still resolved.
Can confirm in 21w05a. Also, Iosiv Visokogorskiy, and Jakub Skoupý, please be patient when waiting for tickets to be handled/fixed. The team are very busy people are some issues are more important than others, meaning that some will not be dealt with after a long amount of time. I assure you that this will eventually be handled when the team feels that the time is appropriate.
Can confirm in 21w05b.
Can confirm in 21w06a.
Can confirm in 21w07a.
Can confirm in 21w11a. Video attached.
Can confirm in 21w17a.
Can confirm in 1.17.1 Release Candidate 1.
Attached a video with an alternate setup based on
MC-183171, if ever the first one stops working for some reason.