Relates to:
The bug
When an FallingSand entity replaces an existing block with nbt data (tile entity), it does not use the nbt data of the block.
How to reproduce
Place a command block and enter something in the command text field
Stand on top of the command block an run the following command
/summon FallingSand ~ ~-1 ~ {Time:0b,Block:"command_block"}Look inside the command block
The command text field is empty
Possible fix
When the game transforms the block into an FallingSand entity, it could copy all specific tags (unspecific tags are id, x, y and z) into the TileEntityData tag of the FallingSand:
FallingSand command
/summon FallingSand ~ ~-1 ~ {Time:0b,Block:"command_block",TileEntityData:{Command:"Some commands",LastOutput:"{\"text\":\"No Output here\"}",TrackOutput:0b}}Linked issues
Comments 10
Why an ugly hack? That is the expected behaviour. FallingSand with a Time of 0 is intended to replace a block and let it fall so the only logic conclusion would be that it also uses the same data
Else it at least relates to the bugs where placed items / broken entities lose their name and other data
Why should it copy the tags? It has never done this.
For feature suggestions go to the reddit page
Falling sand with a Time of 0 is intended to despawn, this effect was an attempt to fix a bug with the falling sand entity, somewhere in the beta versions of the game (I think).
Yes I know about the suggestion subreddit.
But FallingSand with a time of 0 is intended to cause an already existing block to fall.
Just test it:
/setblock ~ ~2 ~ stone
/summon FallingSand ~ ~2 ~ {Block:"stone",Time:0b}FallingSand with time 0 destroys the block it is inside to attempt preventing sand duplication. It does not replace the block, it destroys it.
Are you sure that is what it is meant to do? Because the case that a FallingSand entity with Time:0b is at the same type as block is very unlikely.
The original purpose of the FallingSand entity should be apparent from its name, but in case it isn't: Because of how blocks are stored, manipulated, and rendered, they can only exist on a grid, and cannot smoothly move between points on that grid. The FallingSand entity exists to create the illusion that they can, and was originally only used for sand and gravel. Its data and flexibility were expanded for anvils. The Time tag is just a failsafe, to prevent corner cases where the entity wouldn't get removed, and to fix several block duplication exploits. With the right timing, it was possible to have a block of sand create a FallingSand entity, then quickly pull the sand block away so that it wouldn't get deleted by the FallingSand entity. Repeat for infinite sand/gravel.
When sand or gravel starts falling is exactly the case where you will have a block and a FallingSand entity with Time:0b and the same block ID in the same place, and actually the most common case, rather than "very unlikely". When the IDs match, and Time is 0, then the block is deleted. When the IDs don't match, and Time is 0, the FallingSand entity is deleted instead.
Other uses people have found for FallingSand by manipulating its data and using the summon command are mostly unintended. They're neither bugs nor intentional behavior that can necessarily be depended upon to exist in future versions. Mojang will sometimes take that unintentional behavior and make it an intentional feature, but you cannot assume any particular behavior is intentional just by examining the behavior or even the code of the game. Without an explicit statement from the developer, you can at best only make an educated guess.
Invalid. This is a feature request for something that's an ugly hack in the first place.