The Bug:
Falling sand creates invisible blocks.
Steps to Reproduce:
Run the following command whilst standing on a stone block.
/summon minecraft:falling_block ~ ~-1 ~ {Time:1,Motion:[0.0,1.0,0.0],BlockState:{Name:"minecraft:stone"}}
Take note as to whether or not falling sand creates invisible blocks.
Observed Behavior:
Falling sand creates invisible blocks.
Expected Behavior:
Falling sand would not be able to create invisible blocks.
Code Analysis:
Code analysis by @unknown can be found in this comment.
Related issues
relates to
Attachments
Comments


Confirmed in single player survival. Very interesting. However this appears to be a duplicate of MC-48476.

confirmed just if anyone misunderstands it, the block your standing on becomes invisible

Someone might double check me since I'm a newb. The dupe I mentioned above looks right for what he's reporting but it might be something slightly different. Apologies if I got it wrong.

it is diffrent, this is about the block below turning invisible, that was about the summoned falling sand turning invisible

"it is diffrent, this is about the block below turning invisible, that was about the summoned falling sand turning invisible"
True, I use this for a plugin that is how I found out.

The Tag TileID is deprecated, use the tag Block instead

it may be depreciated, but this bug also happens when using the Block tag

Confirmed for
1.8.2-pre4 The FallingSand doesn't need a velocity upwards
What is also strange, when you use
/summon FallingSand ~ ~-1 ~ {Time:1,Block:command_block,TileEntityData:{Command:/say Hi}}
And do this on top of a command block with a command in it, then place at the bugging block another block (like stone), all NBT data gets deleted.
This only happens when you try to "overwrite" the bugged block. When you reopen the world, the first command block has still its command.

This is dupe of MC-55106.

I believe I know the cause of this bug. FallingSand entities have a special behavior where they delete the block they are inside if it has the same ID and their Time = 0. You can see the 1.7 implementation of this behavior here:
https://github.com/Bukkit/mc-dev/blob/master/net/minecraft/server/EntityFallingBlock.java#L76
The isStatic check above makes this code only run on the server. In the 1.8 code (which is not online for me to link to) this was moved outside the isStatic check and so the client is running it too. Because the Time property is not sent to the client, FallingSand entities always spawn with Time 0 and thus always delete the block.

Confirmed for
15w37a
Duplicates indeed MC-55106, but as this one is more active I rather suggest marking the other report as duplicate

Confirmed for 15w47c

Still seeing it as of 1.9 pre 2, I get it using a fast shovel, beating up a mix of dirt and sand or gravel on a low-ping or local vanilla server, survival, no commands are needed.

@@unknown: MC-5694.


@unknown: Is 1.9-pre4 affected or not ?

Ugh, been too long out of a shop... 'verify' is usually for fixes. :/
Sadly, 1.9-pre4 is still affected by summoned falling sand creating invisible blocks.

The enviroment is supposed to contain pc details.

Confirmed for
16w21b
Please update the provided command. The Block
tag (String) is used now

Please link to this comment in the description
The following is based on a decompiled version of Minecraft 1.9 using MCP 9.24 beta.
It looks like @unknown was correct with his analysis (method net.minecraft.entity.item.EntityFallingBlock.onUpdate()
). Replacing an existing block should be done server-side only because the client receives the block update packets anyways.

Confirmed for 1.12-pre6
Can confirm for MC 1.12.1.

Can confirm for 19w39a.

Affects 20w13a.
Can confirm in 20w46a.
Can confirm in 20w51a.
Can confirm in 21w03a.
Can confirm in 21w05b.
Can confirm in 21w06a.
I am happy to take ownership of this ticket since the reporter has been inactive since 2014.
I was able to reproduce this in 1.18.1, but can no longer in 22w03a, therefore, this has been fixed in 22w03a.

I am also unable to reproduce this issue in 22w05a.
Just for clarification purposes, this was fixed in 22w03a as well and not just 22w05a. 🙂