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.
Related issues
is duplicated by
MC-49788
Comparators update when power is shut
MC-50045
No block updates when deleting a command block with the setblock command
MC-63831
Command blocks placed on redstone block using /setblock with 'Command' datatag not activating command on placement
MC-64402
Redstone blocks placed using /setblock not firing dispensers
MC-68879
Sponges created with /setblock don't absorb water
MC-75426
Redstone mechanisms only update when the block ID is changed
MC-76983
Setblocking a daylight sensor to air doesn't update redstone next to it
MC-77180
Setblock lever does not update all blocks
MC-95692
Junction Rails
MC-124303
Certain blocks do not update blockstates when placed via command
MC-124495
Redstone signals don't update when caused by command
MC-127001
/setblock ~ ~ ~ (colour)_coral Sets a land Coral Block
MC-132561
The collision box with /setblock vines (damage 0)
MC-144634
When using /fill command with torches they can be stacked
MC-150051
note blocks not matching block underneath after cloning them
MC-154061
Fill command strange behaviour
MC-160516
Noteblocks playing harp when filled or setblock
MC-190526
/clone doesn't update cloned blocks
MC-190599
THE COMMAND /setblock ~ ~ ~ minecraft:grass_block[snowy=true] destroy
MC-207084
Floating Grass/Deadbush/Other non solid plants
MC-209990
/setblock or /fill does not allow block updates
MC-225701
/setblock does not update buttons
MC-234077
Incomplete fill of fill command
MC-259438
Big dripleaf - not correct model place
MC-277277
Placing an observer with "/setblock" or "/fill" will cause it to activate
MC-277278
Placing a powered observer with a command only works on the second try
MC-279559
Using command place Sponge cannot absorb water
relates to
MC-120790
Redstone lamps and wire update whether they are lit or not when setblocked, but no other blocks do
MC-212766
Suspended gravity-affected blocks fall if they recieve an update from the sides or above
MC-51340
Certain blocks do not update when falling, placed or cloned next to a power source
MC-57507
Items don't smelt when summoning furnaces with smeltable items and fuel already inside them
MC-120682
Redstone power supplying blocks do not update all affected blocks when placed using commands
MC-61475
Using /setblock to set block entities with items in their inventory does not update comparators adjacent to the block entity
MC-135288
When use fill command, block does not update
MC-171308
Soul fire cannot activate nether portals via setblock command
MC-193315
/setblock and /fill resets the instrument block state of note blocks
MC-216707
Pointed dripstone does not shatter in mid-air when placed by a command
Attachments
Comments
migrated
kumasasa
Duplicate of MC-30949
kumasasa
Reopened because MC-30949 is not an issue.
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.
yep agreed about the title, if you setblock something next to it, it does trigger a block update, I wanted to already change the title when I was working on that bugpost, but I'm not sure how to phrase it yet and am still in the middle to update the other 2 related bugposts I own. If you mods/helpers got any idea how to word it best as title, please feel more than invited to change my bugposts 🙂
Added a list of all blocks that update and don't; it's rather inconsistent.
I'm thinking of a title based on this list.
This may be better.
Resolving as fixed, it's now consistent: no blocks update.
After further examination, this is not fixed for everything yet.
JUE13
Can confirm for 17w49b
FaRo1
There is no version 17w19b. Can you please look at the window title for the real version name?
AlexMCool
Confirmed for 18w05a, however farm_land, grass_path, and pistons (and tnt?) aren't updated anymore
Hello Alex³, TNT, pistons and farm_land does update for me (for farmland, set the randomTickSpeed to e.g. 30000, it will nearly immediately update), however grass_path doesn't for me either. I recall there was something like that mentioned in an older bugpost when grass path was started to be used in the villages.. iirc it didn't update underneath stairs, e.g. in front of the village houses, but I currently don't recall if it got fixed back then, maybe someone can find it.
Thanks for your help, have a nice weekend 🙂
Edit, @Mods: Grass path doesn't update if it's setblock'ed underneath an already-existing/-placed block, however it will update if you place the block above it after the grass path was set.
I don't know now if this is WaI now, and where to list grass path in the above table?
Other things like e.g. flowers also immediately update/pop off if you place a block at them/they receive a block update.
Because some !!! added coral blocks before me, i will help him. ticks in the eye
[media]
Panda4994
Confirmed for 1.13-pre6.
Panda4994
Confirmed for 1.13-pre7.
Confirmed for 1.13-pre8.
Confirmed for 1.13-pre9.
Confirmed for 1.13-pre10.
Panda4994
Confirmed for 1.13.
Confirmed for 18w30a.
Confirmed for 18w30b.
Confirmed for 18w31a.
Confirmed for 18w32a.
Confirmed for 18w33a.
Confirmed for 1.13.1.
Confirmed for 1.13.2-pre1.
Confirmed for 1.13.2-pre2.
Confirmed in 1.16-pre6.
Still happens in 20w27a
When try to open a trapdoor with the setblock command (/setblock ~ ~ ~ minecraft:spruce_trapdoor[facing=west,half=bottom,open=false,powered=true,waterlogged=false]) the trapdoor will open. 1.16.3
When try to open a door with the command in 1.15.2 (/setblock ~ ~ ~ minecraft:oak_door[facing=west,half=lower,hinge=left,open=true,powered=false]) the door will open.
When try to open a door in 1.16.3 with the ** same command (/setblock ~ ~ ~ minecraft:oak_door[facing=south,half=lower,hinge=left,open=true,powered=false]) nothing will happend and the game shows an error!
Avoma
Can confirm in 21w05b.
Still happening in 1.17 snapshots. Is this going to be fixed at some point? It has been a while.
ampolive
Can confirm in 21w41a.
I suggest mentioning /fill in this report as well.
Avoma
Can confirm in 1.19.2.
Brain81505
Can confirm in 1.19.4
Dhranios
Due to the addition of the "strict" argument, I'd say make all blocks update fully when initially placed, unless strict.