mojira.dev
MC-31100

/setblock and /fill do not update the placed block(s) consistently

Reopened
64

If you setblock certain blocks where they would get powered (e.g. onto redstone torch or redstone block), e.g. with:

/setblock <x> <y> <z> command_block{Command:"say test"}

the command block does not say "test", unless it receives a block update.

This occurs also with e.g. dispensers, droppers, note blocks.

See also:

  • MC-51340, it also happens if you got a block entity with NBT data (e.g. a command block with an inserted command) and make it fall, place it or clone it next to a power source, as well as

Code analysis by @unknown in this comment on bugpost MC-18631.

Blocks that do not update when placed with setblock:

(⚠️ Some of those would be useful for mapmakers to be left not updating, see #Note below)

  • doors

  • dispensers

  • droppers

  • command blocks

  • note blocks

  • levers

  • fence gates

  • beds

  • crops

  • repeaters

  • comparators

  • mushrooms

  • cake

  • carpet

  • dead bush

  • flowers

  • tall grass

  • ferns

  • flower pots

  • pressure plates

  • buttons

  • hopper

  • trapdoors

  • ladders

  • piston extension

  • piston heads

  • nether portals

  • saplings

  • snow layers

  • banners

  • signs

  • sponges

  • structure blocks

  • tripwire

  • tripwire hooks

  • vines

  • lily pads

  • rails

  • redstone lamps

  • torches

  • coral blocks

Blocks that do update:

  • anvils

  • sand

  • cactus

  • dragon eggs

  • grass path

  • gravel

  • concrete powder

  • farmland

  • fire

  • observers

  • pistons

  • redstone torches (lit state)

  • redstone wire (power state and supporting block)

  • stairs

  • sugar cane

  • TNT

In short:

  • Everything that needs support to exist stays aside from redstone wire, cactus, sugar cane and fire.

  • Gravity affected blocks fall.

  • Powered/lit/etc state stays the same except for pistons, redstone torches, redstone wire and TNT

  • sponges don't soak up water

⚠️ Decorative things like flowers, dead_bush, fern, grass, portals (anything that would naturally require a supporting block) would be in my personal opinion better to be left not updating by usage of commands, so mapmakers can still use it as decorative means for their maps.
Furthermore, when using the /clone-command, the cloned blocks should probably be cloned as-is, so, if you clone blockstated blocks, they should be cloned as that very blockstated block. In order to toggle that, if desired, it could be considered to add another cloneMode for this (see opposing opinion in MC-190526, which was closed as duplicate of this bugpost). A fill-command with intentionally blockstated blocks should not lead to updated blocks as well (unless specified command-wise); the same should also go for e.g. a structure block, as well as worldgen structure.
TLDR: It seems it could be great for mapmakers to be able to toggle blockstate updates, if possible also per-block; this would open up the ability to use blocks such as for example the 159 currently unused (naturally not generated automatically) blockstates giant mushroom blocks as retextured blocks for individual resource packs easily, without the same type of mushroom blocks updating, if placed next to each other also manually and thus have to e.g. alternate the block types, which lowers and complicates the amount of usable blocks.

Linked issues

is duplicated by 27

MC-49788 Comparators update when power is shut Resolved MC-50045 No block updates when deleting a command block with the setblock command Resolved MC-63831 Command blocks placed on redstone block using /setblock with 'Command' datatag not activating command on placement Resolved MC-64402 Redstone blocks placed using /setblock not firing dispensers Resolved MC-68879 Sponges created with /setblock don't absorb water Resolved
22 more links

relates to 10

MC-120790 Redstone lamps and wire update whether they are lit or not when setblocked, but no other blocks do Resolved MC-212766 Suspended gravity-affected blocks fall if they recieve an update from the sides or above Open MC-51340 Certain blocks do not update when falling, placed or cloned next to a power source Reopened MC-57507 Items don't smelt when summoning furnaces with smeltable items and fuel already inside them Reopened MC-120682 Redstone power supplying blocks do not update all affected blocks when placed using commands Reopened
5 more links

Attachments

2017-10-27_13.06.14.png 2018-03-09_18.40.12.png
noteblock bug.mp4

Comments 38

Duplicate of MC-30949

Reopened because MC-30949 is not an issue.

MC-31100, MC-48804, MC-75426, MC-76983, and many others should really all be part of the same report. It doesn't make sense to have a different issue for each block, as the underlying issue is the same- The setblock command doesn't always cause a block update at the affected blocks.

This is still a problem in 16w03a

Technically, setblock does trigger block updates, so the title is a bit incorrect. It's specific to nbt tag "states" (states saved in nbt rather than block states)...

Edit:
That's not also fully true, for example levers remain, but sand falls.

28 more comments

Can confirm in 21w41a.

I suggest mentioning /fill in this report as well.

Can confirm in 1.19.2.

Can confirm in 1.19.4

Due to the addition of the "strict" argument, I'd say make all blocks update fully when initially placed, unless strict.

Eric Zeiberg

Meri Diana

(Unassigned)

Confirmed

Platform

Low

Commands

/fill, /setblock, banner, bed, block-state, block-update, button, cactus, cake, carpet, command_block, comparator, crop, dead_bush, dispenser, door, dropper, fence_gate, fern, flower, flower_pot, hopper, ladder, lever, lily_pad, moving_piston, mushroom, nether_portal, note_block, piston_head, pressure-plate, repeater, sapling, sign, snow, structure_block, sugar_cane, tall_grass, trapdoor, tripwire, tripwire_hook, vine

Minecraft 13w37b, Minecraft 1.7.9, Minecraft 14w18b, Minecraft 14w20b, Minecraft 1.8.1, ..., 25w03a, 1.21.5, 1.21.6, 1.21.7, 1.21.8

Retrieved