mojira.dev
MC-31100

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

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

MC-277277 Placing an observer with "/setblock" or "/fill" will cause it to activate Resolved MC-277278 Placing a powered observer with a command only works on the second try Resolved MC-279559 Using command place Sponge cannot absorb water Resolved MC-144634 When using /fill command with torches they can be stacked Resolved MC-259438 Big dripleaf - not correct model place Resolved
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

Attachments

Comments 40

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.

30 more comments

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.

Based on the minecraft wiki stating that only using “strict” does not perform block updates, all other modes for clone should perform block updates. If this is the case, this is still a bug for all 1.21.X versions, including the latest 1.21.10-rc1

Specifically I noticed cloning fences from next to a block to nothing next to it leaves the connector on the side

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, ..., 1.21.6, 1.21.7, 1.21.8, 1.21.9, 1.21.10

Retrieved