/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 Marcono1234 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 by29
MC-49788Comparators update when power is shutDuplicateMC-50045No block updates when deleting a command block with the setblock commandDuplicateMC-63831Command blocks placed on redstone block using /setblock with 'Command' datatag not activating command on placementDuplicateMC-64402Redstone blocks placed using /setblock not firing dispensers DuplicateMC-68879Sponges created with /setblock don't absorb waterDuplicateMC-69594Using /setblock to delete tile-entity block fails and succeeds at the same timeDuplicateMC-75426Redstone mechanisms only update when the block ID is changedDuplicateMC-76983Setblocking a daylight sensor to air doesn't update redstone next to itDuplicateMC-77180Setblock lever does not update all blocksDuplicateMC-95692Junction RailsDuplicateMC-117092Structure Blocks in load mode don't load when activated by a redstone source placed via /setblock or /fillDuplicateMC-124303Certain blocks do not update blockstates when placed via commandDuplicateMC-124495Redstone signals don't update when caused by commandDuplicateMC-127001/setblock ~ ~ ~ (colour)_coral Sets a land Coral BlockDuplicateMC-132561The collision box with /setblock vines (damage 0)DuplicateMC-144634When using /fill command with torches they can be stackedDuplicateMC-150051note blocks not matching block underneath after cloning themDuplicateMC-154061Fill command strange behaviourDuplicateMC-160516Noteblocks playing harp when filled or setblockDuplicateMC-190526/clone doesn't update cloned blocksDuplicateMC-190599THE COMMAND /setblock ~ ~ ~ minecraft:grass_block[snowy=true] destroy DuplicateMC-207084Floating Grass/Deadbush/Other non solid plantsDuplicateMC-209990/setblock or /fill does not allow block updatesDuplicateMC-225701/setblock does not update buttonsDuplicateMC-234077Incomplete fill of fill commandDuplicateMC-259438Big dripleaf - not correct model placeDuplicateMC-277277Placing an observer with "/setblock" or "/fill" will cause it to activateDuplicateMC-277278Placing a powered observer with a command only works on the second tryDuplicateMC-279559Using command place Sponge cannot absorb waterDuplicaterelates to12
MC-120790Redstone lamps and wire update whether they are lit or not when setblocked, but no other blocks doFixedMC-212766Suspended gravity-affected blocks fall if they recieve an update from the sides or aboveConfirmedMC-51340Certain blocks do not update when falling, placed or cloned next to a power source
LowMC-57507Items don't smelt when summoning furnaces with smeltable items and fuel already inside themConfirmedMC-120682Redstone power supplying blocks do not update all affected blocks when placed using commandsConfirmedMC-61475Using /setblock to set block entities with items in their inventory does not update comparators adjacent to the block entityFixedMC-117022/fill does not always send block updatesFixedMC-135288When use fill command, block does not updateAwaiting ResponseMC-171308Soul fire cannot activate nether portals via setblock commandWorks As IntendedMC-193315/setblock and /fill resets the instrument block state of note blocksFixedMC-216707Pointed dripstone does not shatter in mid-air when placed by a commandWon't Fix
MCPE-177523Fill command with repeaters (replacing other repeaters) is not working properly.Incomplete
- Unresolved
Meri Diana
Eric Zeiberg- 63
- 41
- Confirmed
- Low
- Platform
- 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
13w37b - 25w03a
13w37b 1.7.9 14w18b 14w20b 1.8.1 1.8.2-pre4 1.8.2-pre6 1.8.7 1.8.9 16w03a 1.10.2 16w43a 1.11.2 1.12-pre3 1.12-pre5 1.12-pre7 1.12 1.12.1-pre1 1.12.1 1.12.2-pre1 1.12.2-pre2 1.12.2 17w43a 17w43b 17w45b 17w46a 17w47a 17w47b 17w48a 17w49a 17w49b 18w01a 18w03b 18w05a 18w10d 18w16a 18w22a 1.13-pre1 1.13-pre2 1.13-pre6 1.13-pre7 1.13-pre8 1.13-pre9 1.13-pre10 1.13 18w30a 18w30b 18w31a 18w32a 18w33a 1.13.1-pre1 1.13.1 1.13.2-pre1 1.13.2-pre2 1.13.2 18w48a 18w48b 18w49a 19w03b 19w03c 19w05a 19w06a 19w07a 19w12b 19w13b 1.14.1 1.14.2-pre2 1.14.2-pre3 1.15.2-pre1 1.15.2 20w06a 20w13a 20w13b 20w14a 20w17a 20w19a 1.16-pre5 1.16-pre6 1.16-rc1 1.16 1.16.1 20w27a 1.16.2-pre3 1.16.2 1.16.3-rc1 1.16.3 1.16.4-pre1 1.16.4-pre2 1.16.4 20w45a 20w46a 20w48a 20w49a 20w51a 21w03a 1.16.5 21w05a 21w05b 21w06a 21w15a 21w16a 21w17a 21w18a 21w19a 21w20a 1.17-pre1 1.17-pre3 1.17-pre4 1.17 1.17.1-pre1 1.17.1 21w37a 21w41a 1.18-pre7 1.18.2 22w18a 1.19-pre5 1.19 1.19.1 1.19.2 22w45a 1.19.3 23w03a 23w04a 23w05a 23w06a 23w07a 1.19.4-pre3 1.19.4 23w13a 23w14a 1.20-pre1 1.20-pre2 1.20-pre4 1.20.1 23w31a 23w32a 23w33a 23w35a 1.20.2-pre1 1.20.2-pre2 1.20.2 23w40a 23w41a 23w42a 23w44a 1.20.4 24w03b 24w04a 24w05a 24w11a 24w12a 1.20.6 1.21 1.21.1 24w40a 1.21.2-pre1 1.21.2-pre2 1.21.3 25w03a
Created Issue:
If using /setblock with command blocks, they do not update
I made a redstone block flat world and when I try to do /setblock <x> <y> <z> 137
{command:"say hi"}the command block does not say hi unless it receives a block update. This only happens with command blocks and if they spawn on a redstone block. It is supposed to power them, but that only happens if they receive a block update.
Environment
Windows 8
Java 7
duplicates
If using /setblock with command blocks, they do not update if placed on restone block
is duplicated by
relates to
duplicates
is duplicated by
is duplicated by
relates to
is duplicated by
is duplicated by
![[Mod] Torabi](../../../data/assets/gravatar/torabi.png){kind=small}
is duplicated by
If using/setblockwith command blocks, they do not update if placed onrestoneblock/setblock does not trigger redstone updates
is duplicated by
relates to
relates to
I made a redstone block flat world and when I try to do
{command:"say hi"}/setblock <x> <y> <z> 137the command block does not say hi unless it receives a block update. This only happens with command blocks and if they spawn on a redstone block. It is supposed to power them, but that only happens if they receive a block update.
I made a redstone block flat world and when I try to do
/setblock <x> <y> <z> 137 {command:"say hi"}the command block does not say hi unless it receives a block update. This only happens with command blocks and if they spawn on a redstone block. It is supposed to power them, but that only happens if they receive a block update.
I made a redstone block flat world and when I try to do
/setblock <x> <y> <z>137{command:"sayhi"}the command block does not say hi unless it receives a block update. This only happens with command blocks and if they spawn on a redstone block. It is supposed to power them, but that only happens if they receive a block update.
I made a redstone block flat world and when I try to do
/setblock <x> <y> <z> command_block 0 destroy {Command:"say test"}the command block does not say hi unless it receives a block update. This only happens with command blocks and if they spawn on a redstone block. It is supposed to power them, but that only happens if they receive a block update.
is duplicated by
relates to
is duplicated by
/setblock does not triggerredstoneupdates/setblock does not trigger block updates
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
I made a redstone block flat world and when I try to do
/setblock <x> <y> <z> command_block 0 destroy {Command:"say test"}the command block does not say
hiunless it receives a block update. This only happens with command blocks and if they spawn on a redstone block. It is supposed to power them, but that only happens if they receive a block update.I made a redstone block flat world and when I try to do
/setblock <x> <y> <z> command_block 0 destroy {Command:"say test"}the command block does not say "test" unless it receives a block update. This only happens with command blocks and if they spawn on a redstone block. It is supposed to power them, but that only happens if they receive a block update.
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
is duplicated by
is duplicated by
is duplicated by
relates to
is duplicated by
is duplicated by
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
relates to
is duplicated by
I
made a redstone block flatworldand when I try to do/setblock <x> <y> <z> command_block 0 destroy {Command:"say test"}the command block does not say "test" unless it receives a block update. This only happens with command blocks and if they spawn on a redstone block. It is supposed to power them, but that only happens if they receive a block update.
If you setblock certain block entities where they would get powered (e.g. onto redstone torch or redstone block), e.g. with:
/setblock <x> <y> <z> command_block 0 destroy {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 place that manually next to a power source, as well as
MC-18631if you insert a command into a command block after having it placed next to a power source, as well asMC-80901as falling block.
If you setblock certain block entities where they would get powered (e.g. onto redstone torch or redstone block), e.g. with:
/setblock <x> <y> <z> command_block 0 destroy {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 place that manually next to a power source, as well as
MC-18631if you insert a command into a command block after having it placed next to a power source, as well asMC-80901as falling block.
Code analysis by Marcono1234 in this comment on bugpost
MC-18631.
If you setblock certain block entities where they would get powered (e.g. onto redstone torch or redstone block), e.g. with:
/setblock <x> <y> <z> command_block 0 destroy {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 place that manually next to a power source, as well as
MC-18631if you insert a command into a command block after having it placed next to a power source, as well asMC-80901as falling block.
Code analysis by Marcono1234 in this comment on bugpost
MC-18631.
Blocks that do not update when placed with setblock:
- doors
- dispensers
- droppers
- command blocks
- note blocks
- levers
- fence gates
- beds
- crops
- repeaters
- comparators
- mushrooms
- cactus
- cake
- carpet
- dead bush
- flowers
- tall grass
- ferns
- flower pots
- pressure plates
- buttons
- hopper
- trapdoors
- ladders
- piston extension
- piston heads
- nether portals
- sugar cane
- saplings
- snow layers
- banners
- signs
- structure blocks
- tripwire
- tripwire hooks
- vines
- lily pads
Blocks that do update:
- rails
- anvils
- sand
- dragon eggs
- gravel
- concrete powder
- redstone lamps
- farmland
- grass path
- fire
- observers
- pistons
- torches
- redstone wire
- sponges
- tnt
In short: blocks needing support of any kind remain (except for fire), powered states (or nbt) are not updated (except for observers(they are related to seeing a new block and as such changing powered state to true for a tick), redstone lamps, wire, torches, powered and detector rails), in-memory data/functions are updated (piston powering, sponge sucking up, tnt lighting, blocks falling).
Mineshafter-launcher.jar
![[Bot] Arisa](../../../data/assets/gravatar/mustek2.png){kind=small}
/setblock does nottrigger block updates/setblock does not update blocks needing support and certain powered states
If you setblock certain block entities where they would get powered (e.g. onto redstone torch or redstone block), e.g. with:
/setblock <x> <y> <z> command_block 0 destroy {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 place that manually next to a power source, as well as
MC-18631if you insert a command into a command block after having it placed next to a power source, as well asMC-80901as falling block.
Code analysis by Marcono1234 in this comment on bugpost
MC-18631.
Blocks that do not update when placed with setblock:
- doors
- dispensers
- droppers
- command blocks
- note blocks
- levers
- fence gates
- beds
- crops
- repeaters
- comparators
- mushrooms
- cactus
- cake
- carpet
- dead bush
- flowers
- tall grass
- ferns
- flower pots
- pressure plates
- buttons
- hopper
- trapdoors
- ladders
- piston extension
- piston heads
- nether portals
- sugar cane
- saplings
- snow layers
- banners
- signs
- structure blocks
- tripwire
- tripwire hooks
- vines
- lily pads
Blocks that do update:
- rails
- anvils
- sand
- dragon eggs
- gravel
- concrete powder
- redstone lamps
- farmland
- grass path
- fire
- observers
- pistons
- torches
- redstone wire
- sponges
- tnt
In short: blocks needing support of any kind remain (except for fire), powered states (or nbt) are not updated (except for observers(they are related to seeing a new block and as such changing powered state to true for a tick), redstone lamps, wire, torches, powered and detector rails), in-memory data/functions are updated (piston powering, sponge sucking up, tnt lighting, blocks falling).
If you setblock certain block entities where they would get powered (e.g. onto redstone torch or redstone block), e.g. with:
/setblock <x> <y> <z> command_block 0 destroy {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 place that manually next to a power source, as well as
MC-18631if you insert a command into a command block after having it placed next to a power source, as well asMC-80901as falling block.
Code analysis by Marcono1234 in this comment on bugpost
MC-18631.
Blocks that do not update when placed with setblock:
- doors
- dispensers
- droppers
- command blocks
- note blocks
- levers
- fence gates
- beds
- crops
- repeaters
- comparators
- mushrooms
- cactus
- cake
- carpet
- dead bush
- flowers
- tall grass
- ferns
- flower pots
- pressure plates
- buttons
- hopper
- trapdoors
- ladders
- piston extension
- piston heads
- nether portals
- sugar cane
- saplings
- snow layers
- banners
- signs
- structure blocks
- tripwire
- tripwire hooks
- vines
- lily pads
- unlit redstone torch
Blocks that do update:
- rails
- anvils
- sand
- dragon eggs
- gravel
- concrete powder
- redstone lamps
- farmland
- grass path
- fire
- observers
- pistons
- torches (lit redstone torches)
- redstone wire
- sponges
- tnt
In short: blocks needing support of any kind remain (except for fire), powered states (or nbt) are not updated (except for observers(they are related to seeing a new block and as such changing powered state to true for a tick), redstone lamps, wire, torches, powered and detector rails), in-memory data/functions are updated (piston powering, sponge sucking up, tnt lighting, blocks falling).
relates to
If you setblock certain block entities where they would get powered (e.g. onto redstone torch or redstone block), e.g. with:
/setblock <x> <y> <z> command_block 0 destroy {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
place that manuallynext to a power source, as well asMC-18631if you insert a command into a command block after having it placed next to a power source, as well asMC-80901as falling block.
Code analysis by Marcono1234 in this comment on bugpost
MC-18631.
Blocks that do not update when placed with setblock:
- doors
- dispensers
- droppers
- command blocks
- note blocks
- levers
- fence gates
- beds
- crops
- repeaters
- comparators
- mushrooms
- cactus
- cake
- carpet
- dead bush
- flowers
- tall grass
- ferns
- flower pots
- pressure plates
- buttons
- hopper
- trapdoors
- ladders
- piston extension
- piston heads
- nether portals
- sugar cane
- saplings
- snow layers
- banners
- signs
- structure blocks
- tripwire
- tripwire hooks
- vines
- lily pads
- unlit redstone torch
Blocks that do update:
- rails
- anvils
- sand
- dragon eggs
- gravel
- concrete powder
- redstone lamps
- farmland
- grass path
- fire
- observers
- pistons
- torches (lit redstone torches)
- redstone wire
- sponges
- tnt
In short: blocks needing support of any kind remain (except for fire), powered states (or nbt) are not updated (except for observers(they are related to seeing a new block and as such changing powered state to true for a tick), redstone lamps, wire, torches, powered and detector rails), in-memory data/functions are updated (piston powering, sponge sucking up, tnt lighting, blocks falling).
If you setblock certain block entities where they would get powered (e.g. onto redstone torch or redstone block), e.g. with:
/setblock <x> <y> <z> command_block 0 destroy {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 Marcono1234 in this comment on bugpost
MC-18631.
Blocks that do not update when placed with setblock:
- doors
- dispensers
- droppers
- command blocks
- note blocks
- levers
- fence gates
- beds
- crops
- repeaters
- comparators
- mushrooms
- cactus
- cake
- carpet
- dead bush
- flowers
- tall grass
- ferns
- flower pots
- pressure plates
- buttons
- hopper
- trapdoors
- ladders
- piston extension
- piston heads
- nether portals
- sugar cane
- saplings
- snow layers
- banners
- signs
- structure blocks
- tripwire
- tripwire hooks
- vines
- lily pads
- unlit redstone torch
Blocks that do update:
- rails
- anvils
- sand
- dragon eggs
- gravel
- concrete powder
- redstone lamps
- farmland
- grass path
- fire
- observers
- pistons
- torches (lit redstone torches)
- redstone wire
- sponges
- tnt
In short: blocks needing support of any kind remain (except for fire), powered states (or nbt) are not updated (except for observers(they are related to seeing a new block and as such changing powered state to true for a tick), redstone lamps, wire, torches, powered and detector rails), in-memory data/functions are updated (piston powering, sponge sucking up, tnt lighting, blocks falling).
relates to
If you setblock certain block entities where they would get powered (e.g. onto redstone torch or redstone block), e.g. with:
/setblock <x> <y> <z> command_block0 destroy{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 Marcono1234 in this comment on bugpost
MC-18631.
Blocks that do not update when placed with setblock:
- doors
- dispensers
- droppers
- command blocks
- note blocks
- levers
- fence gates
- beds
- crops
- repeaters
- comparators
- mushrooms
- cactus
- cake
- carpet
- dead bush
- flowers
- tall grass
- ferns
- flower pots
- pressure plates
- buttons
- hopper
- trapdoors
- ladders
- piston extension
- piston heads
- nether portals
- sugar cane
- saplings
- snow layers
- banners
- signs
- structure blocks
- tripwire
- tripwire hooks
- vines
- lily pads
- unlit redstone torch
Blocks that do update:
- rails
- anvils
- sand
- dragon eggs
- gravel
- concrete powder
- redstone lamps
- farmland
- grass path
- fire
- observers
- pistons
- torches (lit redstone torches)
- redstone wire
- sponges
- tnt
In short: blocks needing support of any kind remain (except for fire), powered states (or nbt) are not updated (except for observers(they are related to seeing a new block and as such changing powered state to true for a tick), redstone lamps, wire, torches, powered and detector rails), in-memory data/functions are updated (piston powering, sponge sucking up, tnt lighting, blocks falling).
If you setblock certain block entities 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 Marcono1234 in this comment on bugpost
MC-18631.
Blocks that do not update when placed with setblock:
- doors
- dispensers
- droppers
- command blocks
- note blocks
- levers
- fence gates
- beds
- crops
- repeaters
- comparators
- mushrooms
- cactus
- cake
- carpet
- dead bush
- flowers
- tall grass
- ferns
- flower pots
- pressure plates
- buttons
- hopper
- trapdoors
- ladders
- piston extension
- piston heads
- nether portals
- sugar cane
- saplings
- snow layers
- banners
- signs
- structure blocks
- tripwire
- tripwire hooks
- vines
- lily pads
unlitredstonetorchBlocks that do update:
rails- an
vilssanddragon eggs- gravel
- concrete powder
redstone lampsfarmland- grass path
- fire
- observers
- pistons
torches (litredstone torches)redstone wiresponges- tnt
In short: blocks needing support of any kind remain (except for fire), powered states (or nbt) are not updated (except for observers(they are related to seeing a new block and as such changing powered state to true for a tick), redstone lamps, wire, torches, powered and detector rails), in-memory data/functions are updated (piston powering, sponge sucking up, tnt lighting, blocks falling).
If you setblock certain block entities 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 Marcono1234 in this comment on bugpost
MC-18631.
Blocks that do not update when placed with setblock:
- doors
- dispensers
- droppers
- command blocks
- note blocks
- levers
- fence gates
- beds
- crops
- repeaters
- comparators
- mushrooms
- cactus
- cake
- carpet
- dead bush
- flowers
- tall grass
- ferns
- flower pots
- pressure plates
- buttons
- hopper
- trapdoors
- ladders
- piston extension
- piston heads
- nether portals
- sugar cane
- saplings
- snow layers
- banners
- signs
- structure blocks
- tripwire
- tripwire hooks
- vines
- lily pads
- rails
- redstone lamps
- torches
Blocks that do update:
- anvils
- sand
- dragon eggs
- gravel
- concrete powder
- farmland
- grass path
- fire
- observers
- pistons
- redstone torches (lit state)
- redstone wire (power state and supporting block)
- sponges
- tnt
In short:
- Everything that needs support to exist stays aside from redstone wire and fire.
- Gravity affected blocks fall.
- Farmland and grass path stay as they are when there's a block above them
- Powered/lit/etc state stays the same except for pistons, redstone torches, redstone wire and tnt
- sponges still soak up water
/setblock does not updateblocks needing support and certain powered states/setblock does not update the placed block consistently
If you setblock certain block entities 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 Marcono1234 in this comment on bugpost
MC-18631.
Blocks that do not update when placed with setblock:
- doors
- dispensers
- droppers
- command blocks
- note blocks
- levers
- fence gates
- beds
- crops
- repeaters
- comparators
- mushrooms
- cactus
- cake
- carpet
- dead bush
- flowers
- tall grass
- ferns
- flower pots
- pressure plates
- buttons
- hopper
- trapdoors
- ladders
- piston extension
- piston heads
- nether portals
- sugar cane
- saplings
- snow layers
- banners
- signs
- structure blocks
- tripwire
- tripwire hooks
- vines
- lily pads
- rails
- redstone lamps
- torches
Blocks that do update:
- anvils
- sand
- dragon eggs
- gravel
- concrete powder
- farmland
- grass path
- fire
- observers
- pistons
- redstone torches (lit state)
- redstone wire (power state and supporting block)
- sponges
- tnt
- stairs
In short:
- Everything that needs support to exist stays aside from redstone wire and fire.
- Gravity affected blocks fall.
- Farmland and grass path stay as they are when there's a block above them
- Powered/lit/etc state stays the same except for pistons, redstone torches, redstone wire and tnt
- sponges still soak up water
is duplicated by
If you setblock certain block
entities 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 Marcono1234 in this comment on bugpost
MC-18631.
Blocks that do not update when placed with setblock:
- doors
- dispensers
- droppers
- command blocks
- note blocks
- levers
- fence gates
- beds
- crops
- repeaters
- comparators
- mushrooms
- cactus
- cake
- carpet
- dead bush
- flowers
- tall grass
- ferns
- flower pots
- pressure plates
- buttons
- hopper
- trapdoors
- ladders
- piston extension
- piston heads
- nether portals
- sugar cane
- saplings
- snow layers
- banners
- signs
- structure blocks
- tripwire
- tripwire hooks
- vines
- lily pads
- rails
- redstone lamps
- torches
Blocks that do update:
- anvils
- sand
- dragon eggs
- gravel
- concrete powder
- farmland
- grass path
- fire
- observers
- pistons
- redstone torches (lit state)
- redstone wire (power state and supporting block)
- sponges
tntstairsIn short:
- Everything that needs support to exist stays aside from redstone wire and fire.
- Gravity affected blocks fall.
- Farmland and grass path stay as they are when there's a block above them
- Powered/lit/etc state stays the same except for pistons, redstone torches, redstone wire and tnt
- sponges still soak up water
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 Marcono1234 in this comment on bugpost
MC-18631.
Blocks that do not update when placed with setblock:
- doors
- dispensers
- droppers
- command blocks
- note blocks
- levers
- fence gates
- beds
- crops
- repeaters
- comparators
- mushrooms
- cactus
- cake
- carpet
- dead bush
- flowers
- tall grass
- ferns
- flower pots
- pressure plates
- buttons
- hopper
- trapdoors
- ladders
- piston extension
- piston heads
- nether portals
- sugar cane
- saplings
- snow layers
- banners
- signs
- structure blocks
- tripwire
- tripwire hooks
- vines
- lily pads
- rails
- redstone lamps
- torches
- stairs
Blocks that do update:
- anvils
- sand
- dragon eggs
- gravel
- concrete powder
- farmland
- grass path
- fire
- observers
- pistons
- redstone torches (lit state)
- redstone wire (power state and supporting block)
- sponges
- tnt
In short:
- Everything that needs support to exist stays aside from redstone wire and fire.
- Gravity affected blocks fall.
- Farmland and grass path stay as they are when there's a block above them
- Powered/lit/etc state stays the same except for pistons, redstone torches, redstone wire and tnt
- sponges still soak up water
is duplicated by
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 Marcono1234 in this comment on bugpost
MC-18631.
Blocks that do not update when placed with setblock:
- doors
- dispensers
- droppers
- command blocks
- note blocks
- levers
- fence gates
- beds
- crops
- repeaters
- comparators
- mushrooms
- cactus
- cake
- carpet
- dead bush
- flowers
tallgrass- ferns
- flower pots
- pressure plates
- buttons
- hopper
- trapdoors
- ladders
- piston extension
- piston heads
- nether portals
- sugar cane
- saplings
- snow layers
- banners
- signs
- structure blocks
- tripwire
- tripwire hooks
- vines
- lily pads
- rails
- redstone lamps
- torches
- stairs
Blocks that do update:
- anvils
- sand
- dragon eggs
- gravel
- concrete powder
- farmland
- grass path
- fire
- observers
- pistons
- redstone torches (lit state)
- redstone wire (power state and supporting block)
- sponges
- tnt
In short:
- Everything that needs support to exist stays aside from redstone wire and fire.
- Gravity affected blocks fall.
- Farmland and grass path stay as they are when there's a block above them
- Powered/lit/etc state stays the same except for pistons, redstone torches, redstone wire and tnt
- sponges still soak up water
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 Marcono1234 in this comment on bugpost
MC-18631.
Blocks that do not update when placed with setblock:
(
- doors
- dispensers
- droppers
- command blocks
- note blocks
- levers
- fence gates
- beds
- crops
- repeaters
- comparators
- mushrooms
- cactus
- cake
- carpet
- dead bush
- flowers
- grass path
- tall grass
- ferns
- flower pots
- pressure plates
- buttons
- hopper
- trapdoors
- ladders
- piston extension
- piston heads
- nether portals
- sugar cane
- saplings
- snow layers
- banners
- signs
- structure blocks
- tripwire
- tripwire hooks
- vines
- lily pads
- rails
- redstone lamps
- torches
- stairs
Blocks that do update:
- anvils
- sand
- dragon eggs
- gravel
- concrete powder
- farmland
- fire
- observers
- pistons
- redstone torches (lit state)
- redstone wire (power state and supporting block)
- sponges
- tnt
In short:
- Everything that needs support to exist stays aside from redstone wire and fire.
- Gravity affected blocks fall.
- Farmland and grass path stay as they are when there's a block above them
- Powered/lit/etc state stays the same except for pistons, redstone torches, redstone wire and tnt
- sponges still soak up water
is duplicated by
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 Marcono1234 in this comment on bugpost
MC-18631.
Blocks that do not update when placed with setblock:
(
- doors
- dispensers
- droppers
- command blocks
- note blocks
- levers
- fence gates
- beds
- crops
- repeaters
- comparators
- mushrooms
- cactus
- cake
- carpet
- dead bush
- flowers
- grass path
- tall grass
- ferns
- flower pots
- pressure plates
- buttons
- hopper
- trapdoors
- ladders
- piston extension
- piston heads
- nether portals
- sugar cane
- saplings
- snow layers
- banners
- signs
- structure blocks
- tripwire
- tripwire hooks
- vines
- lily pads
- rails
- redstone lamps
- torches
- stairs
- coral blocks
Blocks that do update:
- anvils
- sand
- dragon eggs
- gravel
- concrete powder
- farmland
- fire
- observers
- pistons
- redstone torches (lit state)
- redstone wire (power state and supporting block)
- sponges
- tnt
In short:
- Everything that needs support to exist stays aside from redstone wire and fire.
- Gravity affected blocks fall.
- Farmland and grass path stay as they are when there's a block above them
- Powered/lit/etc state stays the same except for pistons, redstone torches, redstone wire and tnt
- sponges still soak up water
is duplicated by
is duplicated by
is duplicated by
Confirmed for 1.12 pre-3.
Confirmed for 1.12 pre-5.
Confirmed for 1.12 pre-7.
Confirmed for 1.12 release.
([Mod] Michael Wobst Thank you
)
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
is duplicated by
![[Helper] Lord_Quadrato](../../../data/avatars/users/26105.png){kind=small}
relates to
is duplicated by
is duplicated by
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
is duplicated by
is duplicated by
is duplicated by
relates to
relates to
is duplicated by
![[Bot] Arisa](../../../data/avatars/users/43007.png){kind=small}
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 Marcono1234 in this comment on bugpost
MC-18631.
Blocks that do not update when placed with setblock:
(
- doors
- dispensers
- droppers
- command blocks
- note blocks
- levers
- fence gates
- beds
- crops
- repeaters
- comparators
- mushrooms
- cactus
- cake
- carpet
- dead bush
- flowers
- grass path
- tall grass
- ferns
- flower pots
- pressure plates
- buttons
- hopper
- trapdoors
- ladders
- piston extension
- piston heads
- nether portals
- sugar cane
- saplings
- snow layers
- banners
- signs
- structure blocks
- tripwire
- tripwire hooks
- vines
- lily pads
- rails
- redstone lamps
- torches
- stairs
- coral blocks
Blocks that do update:
- anvils
- sand
- dragon eggs
- gravel
- concrete powder
- farmland
- fire
- observers
- pistons
- redstone torches (lit state)
- redstone wire (power state and supporting block)
- sponges
- tnt
In short:
- Everything that needs support to exist stays aside from redstone wire and fire.
- Gravity affected blocks fall.
- Farmland and grass path stay as they are when there's a block above them
- Powered/lit/etc state stays the same except for pistons, redstone torches, redstone wire and tnt
- sponges still soak up water
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 Marcono1234 in this comment on bugpost
MC-18631.
Blocks that do not update when placed with setblock:
(
- doors
- dispensers
- droppers
- command blocks
- note blocks
- levers
- fence gates
- beds
- crops
- repeaters
- comparators
- mushrooms
- cactus
- cake
- carpet
- dead bush
- flowers
- grass path
- tall grass
- ferns
- flower pots
- pressure plates
- buttons
- hopper
- trapdoors
- ladders
- piston extension
- piston heads
- nether portals
- sugar cane
- saplings
- snow layers
- banners
- signs
- structure blocks
- tripwire
- tripwire hooks
- vines
- lily pads
- rails
- redstone lamps
- torches
- stairs
- coral blocks
Blocks that do update:
- anvils
- sand
- dragon eggs
- gravel
- concrete powder
- farmland
- fire
- observers
- pistons
- redstone torches (lit state)
- redstone wire (power state and supporting block)
- sponges
- tnt
In short:
- Everything that needs support to exist stays aside from redstone wire and fire.
- Gravity affected blocks fall.
- Farmland and grass path stay as they are when there's a block above them
- Powered/lit/etc state stays the same except for pistons, redstone torches, redstone wire and tnt
- sponges still soak up water
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 in that very blockstated block. In order to toggle that, if desired, it could be considered to add another cloneMode for this (see *
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 Marcono1234 in this comment on bugpost
MC-18631.
Blocks that do not update when placed with setblock:
(
- doors
- dispensers
- droppers
- command blocks
- note blocks
- levers
- fence gates
- beds
- crops
- repeaters
- comparators
- mushrooms
- cactus
- cake
- carpet
- dead bush
- flowers
- grass path
- tall grass
- ferns
- flower pots
- pressure plates
- buttons
- hopper
- trapdoors
- ladders
- piston extension
- piston heads
- nether portals
- sugar cane
- saplings
- snow layers
- banners
- signs
- structure blocks
- tripwire
- tripwire hooks
- vines
- lily pads
- rails
- redstone lamps
- torches
- stairs
- coral blocks
Blocks that do update:
- anvils
- sand
- dragon eggs
- gravel
- concrete powder
- farmland
- fire
- observers
- pistons
- redstone torches (lit state)
- redstone wire (power state and supporting block)
- sponges
- tnt
In short:
- Everything that needs support to exist stays aside from redstone wire and fire.
- Gravity affected blocks fall.
- Farmland and grass path stay as they are when there's a block above them
- Powered/lit/etc state stays the same except for pistons, redstone torches, redstone wire and tnt
- sponges still soak up water
*: Decorative things like flowers, dead_bush, fern, grass and similar would be in my personal opinion better to be left not updating, 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 in that very blockstated block. In order to toggle that, if desired, it could be considered to add another cloneMode for this (see *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 Marcono1234 in this comment on bugpost
MC-18631.
Blocks that do not update when placed with setblock:
(
- doors
- dispensers
- droppers
- command blocks
- note blocks
- levers
- fence gates
- beds
- crops
- repeaters
- comparators
- mushrooms
- cactus
- cake
- carpet
- dead bush
- flowers
- grass path
- tall grass
- ferns
- flower pots
- pressure plates
- buttons
- hopper
- trapdoors
- ladders
- piston extension
- piston heads
- nether portals
- sugar cane
- saplings
- snow layers
- banners
- signs
- structure blocks
- tripwire
- tripwire hooks
- vines
- lily pads
- rails
- redstone lamps
- torches
- stairs
- coral blocks
Blocks that do update:
- anvils
- sand
- dragon eggs
- gravel
- concrete powder
- farmland
- fire
- observers
- pistons
- redstone torches (lit state)
- redstone wire (power state and supporting block)
- sponges
- tnt
In short:
- Everything that needs support to exist stays aside from redstone wire and fire.
- Gravity affected blocks fall.
- Farmland and grass path stay as they are when there's a block above them
- Powered/lit/etc state stays the same except for pistons, redstone torches, redstone wire and tnt
- sponges still soak up water
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 in that very blockstated block. In order to toggle that, if desired, it could be considered to add another cloneMode for this (seeMC-190526, which was closed as duplicate of this bugpost).
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 Marcono1234 in this comment on bugpost
MC-18631.
Blocks that do not update when placed with setblock:
(
- doors
- dispensers
- droppers
- command blocks
- note blocks
- levers
- fence gates
- beds
- crops
- repeaters
- comparators
- mushrooms
- cactus
- cake
- carpet
- dead bush
- flowers
- grass path
- tall grass
- ferns
- flower pots
- pressure plates
- buttons
- hopper
- trapdoors
- ladders
- piston extension
- piston heads
- nether portals
- sugar cane
- saplings
- snow layers
- banners
- signs
- structure blocks
- tripwire
- tripwire hooks
- vines
- lily pads
- rails
- redstone lamps
- torches
- stairs
- coral blocks
Blocks that do update:
- anvils
- sand
- dragon eggs
- gravel
- concrete powder
- farmland
- fire
- observers
- pistons
- redstone torches (lit state)
- redstone wire (power state and supporting block)
- sponges
- tnt
In short:
- Everything that needs support to exist stays aside from redstone wire and fire.
- Gravity affected blocks fall.
- Farmland and grass path stay as they are when there's a block above them
- Powered/lit/etc state stays the same except for pistons, redstone torches, redstone wire and tnt
- sponges still soak up water
Furthermore, when using the /clone-command, the cloned blocks should probably be cloned as-is, so, if you clone blockstated blocks, they should be clonedinthat very blockstated block. In order to toggle that, if desired, it could be considered to add another cloneMode for this (seeMC-190526, which was closed as duplicate of this bugpost).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 Marcono1234 in this comment on bugpost
MC-18631.
Blocks that do not update when placed with setblock:
(
- doors
- dispensers
- droppers
- command blocks
- note blocks
- levers
- fence gates
- beds
- crops
- repeaters
- comparators
- mushrooms
- cactus
- cake
- carpet
- dead bush
- flowers
- grass path
- tall grass
- ferns
- flower pots
- pressure plates
- buttons
- hopper
- trapdoors
- ladders
- piston extension
- piston heads
- nether portals
- sugar cane
- saplings
- snow layers
- banners
- signs
- structure blocks
- tripwire
- tripwire hooks
- vines
- lily pads
- rails
- redstone lamps
- torches
- stairs
- coral blocks
Blocks that do update:
- anvils
- sand
- dragon eggs
- gravel
- concrete powder
- farmland
- fire
- observers
- pistons
- redstone torches (lit state)
- redstone wire (power state and supporting block)
- sponges
- tnt
In short:
- Everything that needs support to exist stays aside from redstone wire and fire.
- Gravity affected blocks fall.
- Farmland and grass path stay as they are when there's a block above them
- Powered/lit/etc state stays the same except for pistons, redstone torches, redstone wire and tnt
- sponges still soak up water
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 inMC-190526, which was closed as duplicate of this bugpost). A fill-command with intentionally blockstated blocks should not lead to updated blocks as well.
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 without the same type of mushroom blocks updating, if placed next to each other.
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 Marcono1234 in this comment on bugpost
MC-18631.
Blocks that do not update when placed with setblock:
(
- doors
- dispensers
- droppers
- command blocks
- note blocks
- levers
- fence gates
- beds
- crops
- repeaters
- comparators
- mushrooms
- cactus
- cake
- carpet
- dead bush
- flowers
- grass path
- tall grass
- ferns
- flower pots
- pressure plates
- buttons
- hopper
- trapdoors
- ladders
- piston extension
- piston heads
- nether portals
- sugar cane
- saplings
- snow layers
- banners
- signs
- structure blocks
- tripwire
- tripwire hooks
- vines
- lily pads
- rails
- redstone lamps
- torches
- stairs
- coral blocks
Blocks that do update:
- anvils
- sand
- dragon eggs
- gravel
- concrete powder
- farmland
- fire
- observers
- pistons
- redstone torches (lit state)
- redstone wire (power state and supporting block)
- sponges
- tnt
In short:
- Everything that needs support to exist stays aside from redstone wire and fire.
- Gravity affected blocks fall.
- Farmland and grass path stay as they are when there's a block above them
- Powered/lit/etc state stays the same except for pistons, redstone torches, redstone wire and tnt
- sponges still soak up water
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 inMC-190526, which was closed as duplicate of this bugpost). A fill-command with intentionally blockstated blocks should not lead to updated blocks as well.
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 without the same type of mushroom blocks updating, if placed next to each other also manually.
is duplicated by
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 Marcono1234 in this comment on bugpost
MC-18631.
Blocks that do not update when placed with setblock:
(
- doors
- dispensers
- droppers
- command blocks
- note blocks
- levers
- fence gates
- beds
- crops
- repeaters
- comparators
- mushrooms
- cactus
- cake
- carpet
- dead bush
- flowers
- grass path
- tall grass
- ferns
- flower pots
- pressure plates
- buttons
- hopper
- trapdoors
- ladders
- piston extension
- piston heads
- nether portals
- sugar cane
- saplings
- snow layers
- banners
- signs
- structure blocks
- tripwire
- tripwire hooks
- vines
- lily pads
- rails
- redstone lamps
- torches
- stairs
- coral blocks
Blocks that do update:
- anvils
- sand
- dragon eggs
- gravel
- concrete powder
- farmland
- fire
- observers
- pistons
- redstone torches (lit state)
- redstone wire (power state and supporting block)
- sponges
- tnt
In short:
- Everything that needs support to exist stays aside from redstone wire and fire.
- Gravity affected blocks fall.
- Farmland and grass path stay as they are when there's a block above them
- Powered/lit/etc state stays the same except for pistons, redstone torches, redstone wire and tnt
- sponges still soak up water
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 inMC-190526, which was closed as duplicate of this bugpost). A fill-command with intentionally blockstated blocks should not lead to updated blocks as well.
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 without the same type of mushroom blocks updating, if placed next to each other also manually.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 Marcono1234 in this comment on bugpost
MC-18631.
Blocks that do not update when placed with setblock:
(
- doors
- dispensers
- droppers
- command blocks
- note blocks
- levers
- fence gates
- beds
- crops
- repeaters
- comparators
- mushrooms
- cactus
- cake
- carpet
- dead bush
- flowers
- grass path
- tall grass
- ferns
- flower pots
- pressure plates
- buttons
- hopper
- trapdoors
- ladders
- piston extension
- piston heads
- nether portals
- sugar cane
- saplings
- snow layers
- banners
- signs
- structure blocks
- tripwire
- tripwire hooks
- vines
- lily pads
- rails
- redstone lamps
- torches
- stairs
- coral blocks
Blocks that do update:
- anvils
- sand
- dragon eggs
- gravel
- concrete powder
- farmland
- fire
- observers
- pistons
- redstone torches (lit state)
- redstone wire (power state and supporting block)
- sponges
- tnt
In short:
- Everything that needs support to exist stays aside from redstone wire and fire.
- Gravity affected blocks fall.
- Farmland and grass path stay as they are when there's a block above them
- Powered/lit/etc state stays the same except for pistons, redstone torches, redstone wire and tnt
- sponges still soak up water
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 inMC-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).
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.
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 Marcono1234 in this comment on bugpost
MC-18631.
Blocks that do not update when placed with setblock:
(
- doors
- dispensers
- droppers
- command blocks
- note blocks
- levers
- fence gates
- beds
- crops
- repeaters
- comparators
- mushrooms
- cactus
- cake
- carpet
- dead bush
- flowers
- grass path
- tall grass
- ferns
- flower pots
- pressure plates
- buttons
- hopper
- trapdoors
- ladders
- piston extension
- piston heads
- nether portals
- sugar cane
- saplings
- snow layers
- banners
- signs
- structure blocks
- tripwire
- tripwire hooks
- vines
- lily pads
- rails
- redstone lamps
- torches
- stairs
- coral blocks
Blocks that do update:
- anvils
- sand
- dragon eggs
- gravel
- concrete powder
- farmland
- fire
- observers
- pistons
- redstone torches (lit state)
- redstone wire (power state and supporting block)
- sponges
- tnt
In short:
- Everything that needs support to exist stays aside from redstone wire and fire.
- Gravity affected blocks fall.
- Farmland and grass path stay as they are when there's a block above them
- Powered/lit/etc state stays the same except for pistons, redstone torches, redstone wire and tnt
- sponges still soak up water
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 inMC-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.
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 Marcono1234
in this commenton bugpostMC-18631.
Blocks that do not update when placed with setblock:
(
- doors
- dispensers
- droppers
- command blocks
- note blocks
- levers
- fence gates
- beds
- crops
- repeaters
- comparators
- mushrooms
- cactus
- cake
- carpet
- dead bush
- flowers
- grass path
- tall grass
- ferns
- flower pots
- pressure plates
- buttons
- hopper
- trapdoors
- ladders
- piston extension
- piston heads
- nether portals
- sugar cane
- saplings
- snow layers
- banners
- signs
- structure blocks
- tripwire
- tripwire hooks
- vines
- lily pads
- rails
- redstone lamps
- torches
- stairs
- coral blocks
Blocks that do update:
- anvils
- sand
- dragon eggs
- gravel
- concrete powder
- farmland
- fire
- observers
- pistons
- redstone torches (lit state)
- redstone wire (power state and supporting block)
- sponges
- tnt
In short:
- Everything that needs support to exist stays aside from redstone wire and fire.
- Gravity affected blocks fall.
- Farmland and grass path stay as they are when there's a block above them
- Powered/lit/etc state stays the same except for pistons, redstone torches, redstone wire and tnt
- sponges still soak up water
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 inMC-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.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 Marcono1234 in this comment on bugpost
MC-18631.
Blocks that do not update when placed with setblock:
(
- doors
- dispensers
- droppers
- command blocks
- note blocks
- levers
- fence gates
- beds
- crops
- repeaters
- comparators
- mushrooms
- cactus
- cake
- carpet
- dead bush
- flowers
- grass path
- tall grass
- ferns
- flower pots
- pressure plates
- buttons
- hopper
- trapdoors
- ladders
- piston extension
- piston heads
- nether portals
- sugar cane
- saplings
- snow layers
- banners
- signs
- structure blocks
- tripwire
- tripwire hooks
- vines
- lily pads
- rails
- redstone lamps
- torches
- stairs
- coral blocks
Blocks that do update:
- anvils
- sand
- dragon eggs
- gravel
- concrete powder
- farmland
- fire
- observers
- pistons
- redstone torches (lit state)
- redstone wire (power state and supporting block)
- sponges
- tnt
In short:
- Everything that needs support to exist stays aside from redstone wire and fire.
- Gravity affected blocks fall.
- Farmland and grass path stay as they are when there's a block above them
- Powered/lit/etc state stays the same except for pistons, redstone torches, redstone wire and tnt
- sponges still soak up water
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 inMC-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.
relates to
![[Mod] j_p_smith](../../../data/avatars/users/92851.png){kind=small}
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 Marcono1234 in this comment on bugpost
MC-18631.
Blocks that do not update when placed with setblock:
(
- doors
- dispensers
- droppers
- command blocks
- note blocks
- levers
- fence gates
- beds
- crops
- repeaters
- comparators
- mushrooms
- ca
ctus- ca
ke- carpet
- dead bush
- flowers
- grass
path- tall grass
- ferns
- flower pots
- pressure plates
- buttons
- hopper
- trapdoors
- ladders
- piston extension
- piston heads
- nether portals
- s
ugar cane- s
aplingssnow layersbanners- signs
- structure blocks
- tripwire
- tripwire hooks
- vines
- lily pads
- rails
- redstone lamps
- torches
stairs- coral blocks
Blocks that do update:
- anvils
- sand
- dragon eggs
- gra
vel- concrete powder
- farmland
- fire
- observers
- pistons
- redstone torches (lit state)
- redstone wire (power state and supporting block)
- sponges
tntIn short:
- Everything that needs support to exist stays aside from redstone wire and fire.
- Gravity affected blocks fall.
- Farmland and grass path stay as they are when there's a block above them
- Powered/lit/etc state stays the same except for pistons, redstone torches, redstone wire and
tnt- sponges still soak up water
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 inMC-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.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 Marcono1234 in this comment on bugpost
MC-18631.
Blocks that do not update when placed with setblock:
(
- 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
- 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)
- sponges
- 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 still soak up water
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 inMC-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.
Windows 8
Java 7
![[Mojang] Adrian Östergård](../../../data/assets/gravatar/nighter.jpeg){kind=small}
![[Helper] Johnibur](../../../data/avatars/users/28381.png){kind=small}
![[Mod] Greymagic27](../../../data/avatars/users/92875.png){kind=small}
is duplicated by
![[Helper] Jack McKalling](../../../data/avatars/users/92859.png){kind=small}
is duplicated by
![[Mod] Chandler](../../../data/assets/gravatar/triwonder81.png){kind=small}
relates to
relates to
![[Mod] markderickson](../../../data/avatars/users/18946.svg){kind=small}
[Mod] Anthony Cicinelli why you don't close reports even you are a moderator?
is duplicated by
is duplicated by
![[Mod] ampolive](../../../data/avatars/users/18949.svg){kind=small}
is duplicated by
is duplicated by
is duplicated by
relates to
/setblock and /fill do not update the placed block(s) consistently
is duplicated by
![[Mojang] slicedlime](../../../data/assets/gravatar/slicedlime.jpeg){kind=small}
Certain block entities, when newly placed next to a power source, won't activate until they receive a block update.
Steps To Reproduce:
1. Place a command block to where it will be powered as soon as it is placed.
2. Type a command into the command block, e.g.: "say test".
> Notice the command block won't output "test" although it's powered.
3. Cause a block update next to the command block.
> Notice the command block now outputs "test".
This also occurs with dispensers, droppers, and note blocks.
See also:
MC-51340, it also happens if you got certain block entities with NBT data (e.g. a command block with an inserted command) and place that manually next to a power source, as well as
MC-31100 if you setblock certain block entities with NBT data where they would get powered, as well as
MC-80901 as falling block.
Code analysis by Marcono1234 in this comment.
The bug
When certain block entities such as a dropper/dispenser or a command block that contain NBT data for items or a command is either placed manually on a power source or cloned on a power source it will receive power because a repeater gets power from the side of it but the dispenser will not place/drop anything and the command block will not run the command.
How to reproduce
- Place down a dispenser or dropper or command block
- Put items or a command into the block, depending what it is
- Control and middle-click the block to get the block with NBT data
- Place this on a power source such as a redstone torch or a redstone block
→ It should run the command or drop/place something but it does not
Note: this also affects note blocks, they won't play a note until they received a block update.
Test command for falling block, insert into a command block and trigger:
summon falling_block ~ ~2 ~ {
BlockState:{Name:"minecraft:stone"},
Time:1s,
Passengers:
[
{
id:"falling_block",
BlockState:{Name:"minecraft:redstone_block"},
Time:1s,
Passengers:
[
{
id:"falling_block",
BlockState:{Name:"minecraft:command_block"},
TileEntityData:{Command:"say Test"},
Time:1s
}
]
}
]
}
Related issue
MC-31100 when using /setblock to place the block it does not update (and more)
Code analysis
Code analysis by Marcono1234 can be found in this comment on bug report MC-18631.
Resolving this ticket as invalid, but reopening MC-31100 since placing a command block on a restone block won't trigger the command block
Duplicate of Relates to MC-31100
Steps to reproduce
1. Place any block with tile entity (Chest, Furnace, Command block, etc)
2. Place attachable blocks like ladder, button, torch, etc (or setup a BUD switch)
3. Delete the block with tile entity using the command /setblock x y z air [0 replace] (x y z being coordinate of the block)
4. The command output (or chat screen) says "The block couldn't be placed" but block gets deleted anyways, and adjacent blocks are not updated at all. (for example, a BUD switch would not activate).
Note : This only happens specifically with setblock air replace.
Comment : This is NOT a duplicate of MC-31100. See it yourselves.
I am not sure how this ticket is dupe of MC-31100. Please read the description and explain why do you think so.
I got "1 2" from both your examples. I'm not sure, but it seemed to work for me.
EDIT: I think the issue is actually this MC-31100
Duplicated by:
First of all this whole block placing updating blocks thing is really complicated and confusing with Minecraft. Because of that the provided fix might cause other problems but I hope I got that right and currently it does not cause other problems.
The method setBlockState(BlockPos p_177436_1_, IBlockState p_177436_2_) in the class /Client/src/net/minecraft/world/chunk/Chunk.java (MCP 1.8 names) which is called at some point after a block was placed or destroyed used to call only var15.updateContainingBlockInfo(); however I am unsure what this method actually does...
For TileEntities the onNeighborBlockChange(World worldIn, BlockPos pos, IBlockState state, Block neighborBlock) method must be called to update them. This method is called by the notifyBlockOfStateChange(BlockPos pos, final Block blockIn) method.
The reason why this did not affect basic redstone powered blocks is that they update themselves when the onBlockAdded(World worldIn, BlockPos pos, IBlockState state) is called (and this method is called).
public IBlockState setBlockState(BlockPos p_177436_1_, IBlockState p_177436_2_) { //... if (var8 == p_177436_2_) { return null; } else { //... if (var11.getBlockByExtId(var3, var4 & 15, var5) != var9) { return null; } else { if (var9 instanceof ITileEntityProvider) { var15 = this.func_177424_a(p_177436_1_, Chunk.EnumCreateEntityType.CHECK); if (var15 == null) { var15 = ((ITileEntityProvider)var9).createNewTileEntity(this.worldObj, var9.getMetaFromState(p_177436_2_)); this.worldObj.setTileEntity(p_177436_1_, var15); } if (var15 != null) { // Added the following line worldObj.notifyBlockOfStateChange(var15.getPos(), var15.getBlockType()); var15.updateContainingBlockInfo(); } } } } }
FYI: MC-31100 and related tickets.
Thank you for your report!
However, this issue has been closed as a Duplicate of MC-117022 and MC-31100.
It has been linked to these reports. If you have additional information, please add it to that report.
Please search before reporting, as it's likely that one exists already.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – 📖 Game Wiki
![[Mod] NeunEinser](../../../data/avatars/users/39263.png){kind=small}
Preliminary remark
Despite sounding similar to MC-31100, this report is not a duplicate. MC-31100 covers redstone components which do not notice that they should be powered, this report here covers special cases in which redstone power supplying blocks do not update all required blocks.
The bug
Redstone power supplying blocks do not update all affected blocks when placed using commands. Mainly the do not update blocks which are currently receiving or should receive power through a block.
This affects commands like /setblock as well as falling block entities.
How to reproduce
- Build a setup as shown in Setup.png
- Stand on the lapis block and use a command to place a lever
/setblock ~ ~ ~ lever[face=floor,powered=true]→
The redstone wire which should be powered through the block was not updated
Code analysis
MCP 9.40-pre1 names
In order to resolve the issue for placing a new block, the method net.minecraft.block.Block.onBlockAdded(World, BlockPos, IBlockState) needs to be overridden in the classes of power supplying blocks (lever, button and similar):
@Override public void onBlockAdded(World worldIn, BlockPos pos, IBlockState state) { if(state.getValue(POWERED)) worldIn.notifyNeighborsOfStateChange(pos.offset(state.getValue(FACING).getFacing().getOpposite()), this, false); }
This method is however not called by net.minecraft.world.chunk.Chunk.setBlockState(BlockPos, IBlockState), when the block type it is placing is the same that was there previously.
One possibility would obviously be to remove the check, but that might have side effects elsewhere that I am not aware of. Some code would become redundant at the very least.
Another, probably more clean way of fixing it would be to add an additional method to Block, like onStateChange that gets called in this case. With this soloution some of the code of net.minecraft.block.BlockLever.onBlockActivated(World, BlockPos, IBlockState, EntityPlayer, EnumHand, EnumFacing, float, float, float) would become redundant as it is already changing the state in there and the new onStateChange method would take care of that anyways.
Not really. MC-31100 is not about missing block updates or a lack of them. It is more about a block getting placed and the placed block not checking if it should be powered and thus do stuff.
This is about a block getting placed and not causing other blocks to update. Also in MC-31100 this will always happen, no matter what block has been at the position before. This will only happen if you replace the block with the same block, but different state.
Besides that, I created the report to provide code analysis. I cannot do that in MC-31100 since that is also codewise a totally different problem which my code analysis will have no effect on.
Also, to clarify a bit here, the issue description of MC-31100 is actually wrong. /setblock does cause block updates. And the issue also does not describe, as I said before, missing block updates. It doesn't even have to do anything with /setblock. If you have a command block with data in your inventory and place it, the command also does not get executed. This bug is really just describing a bug with command blocks only. It probably is just the command block not checking if it is powered when placed.
And yes, a block update on the command block will result in the command block executing, but that does not mean that the code should have caused a block update here. Blocks do not update themselves when placed in general.
At first glance, this may look like a duplicate of MC-31100. However, please take the following into consideration before closing this:
- This issue started occurring in this snapshot, 18w30b.
- MC-31100 says that the affected block(s) will not respond until they receive a block update; however, setting a command block in prior versions with
/setblock ~ ~ ~1 repeating_command_block{auto:1,Command:"say Success!"}would cause the command block to start running the command on its own.
If the mods decide to close this as duplicate anyway please give me a detailed reason why - it may sound like I'm asking for a lot, but it would mean so much to me. Thanks!
Duplicate of MC-31100
Duplicate of MC-31100
Thank you for your report!
We're actually already tracking this issue in MC-31100, so I resolved and linked this ticket as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature in the future to see if the issue has already been reported.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – 📖 Game Wiki
The bug
Container blocks, unlike any other block entity, can contain items. This is linked to nbt data, named also Items, that updates when items are added/removed (e.g. the Chest).
So, I put it to the test to see if some block entities had the same update effect after being set with the same block state, and I discovered that certain block entities (such as containers) replace their content only in their nbt (unless they are linked to these items) and could possibly cause issues.
One example can be replicated with the Campfire during its cooking state; replacing it with identical state values result in the appearance of an error message although the food items in its nbt have been updated, the food items are still visible (which pauses the cooking process)... Here are some experiments to prove my point on this issue:
- Replacing any interactable container with the same state values removes its contents completely (despite the error message showing up). This applies to:
- Chests
- Hoppers
- Droppers/Dispensers
- Shulker boxes
- Furnaces
- Barrels
- Blast furnaces
- Smokers
- Replacing a Lectern (wielding a book) with the same state values however, doesn't lose its content but results in the book GUI to instantly close when opened.
- Replacing a Campfire with another (during its cooking process) comes back with the error message (if all its states match the previous), resulting in the cooking process to pause with its food items still displayed.
EDIT: Related issue in MC-31100
Reproduction steps
- Place a campfire containing raw food items
- Replace that block with the same state values using the command:
/setblock [campfire location] campfire[states of target block]
(now occurs the error message)
- Execute the command:
/data get block [campfire location] Items
Thank you for your report!
We're tracking this issue in MC-31100, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature in the future to see if the issue has already been reported.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – ✍️ Feedback and Suggestions – 📖 Game Wiki
Thank you for your report!
However, we are already tracking this issue, and this report is a Duplicate of MC-31100, which is a report that has not been resolved yet.
If you want, you can upvote the parent ticket, and enable watching to receive any updates about it - if you believe you have any information that may be important for this issue, please leave a comment on the parent. Please also use the search function in the future to prevent duplicate reports.
Quick Links:
📓 Issue Guidelines – 🛠 Community Support – 📧 Customer Support – ✍️ Feedback and Suggestions – 📖 Game Wiki
💬 Mojira Subreddit – 💬 Mojira Discord
Sounds more like MC-31100.
Thank you for your report!
We're tracking this issue in MC-31100, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
The bug
When configuring debug settings for carvers, and setting the block's name to a block that updates with /setblock (see list in MC-31100), an acacia button is placed instead of the desired block.
In the screenshot attached, although I configured the settings with redstone wire, acacia buttons were placed instead.
How to reproduce
If these reproduction steps are more complicated than needed, sorry – I am not good with datapacks!
I was able to reproduce this issue by setting up a datapack using [Mojang] slicedlime's example worldgen settings (here). I added "debug_mode": true, to the cave carver file under "debug_settings": {, and changed the default block placed to redstone wire (minecraft:redstone_wire) instead of crimson button. I then created a world using the datapack.
Seems like a duplicate of MC-31100.
Relates to MC-31100.
Seagrass and sea pickle not flowing is the actual bug here caused by MC-31100
I prefer closing this as a duplicate of MC-31100
Thank you for your report!
We're tracking this issue in MC-31100, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
Thank you for your report!
We're tracking this issue in MC-31100, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
This phenomenon can also be achieved using \clone. While most blocks are designed to remain in their original state after being cloned, accepting a block update returns to normal ( MC-31100 ). But here we get a repeater that is displayed abnormally, the point is that its state is not notified to the client, not whether it remains in the wrong state.
I'll add \clone to the description.
Seems like MC-31100. (it even explicitly lists torches as not updating)
I don't see how this is any different from MC-31100; additionally, if you re-run the command on an already existing note block, it will stay the same, just like most of the blocks listed in that report.
This should be marked as duplicate, and the instrument state added to the list, rather than related.
Thank you for your report!
We're tracking this issue in MC-31100, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
Big dripleafs turn themselves into big dripleaf stems when another is right above them. You did not providea facing state, so it is the default value, which is not the same value as you placed.
Duplicate of MC-31100.
Relates to MC-31100.
related to MC-246909.
normally, if there's a liquid that's one block above the cactus, the cactus will break, which is intended due to the fix of MC-123051. however, it's only affects water, lava and bubble column. any other liquid block (seagrass, tall seagrass, kelp, kelp plant and waterlogged blocks) won't break cactus.
step to reproduce:
step 1: place a sand, then place a cactus on top of the sand, after that place water on top of the cactus -> the cactus breaks.
step 2: remove the water, then place a cactus on top of the sand, now place the any block that can be waterlogged (in this case it's iron bar) on top of the cactus, now waterlogged that block -> the cactus doesn't break.
note: the same thing happens to segrass, tall seagrass, kelp and kelp plant, but it's harder to reproduce. the way to reproduce is by MC-190526. however, that doesn't means that this bug is a dupe of MC-190526 or MC-31100.
Duplicate of MC-31100.
Closed as a duplicate of MC-31100, as this issue seems to be contained in that. 
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
![[Mod] Jiingy](../../../data/avatars/users/91802.png){kind=small}
Would MC-31100 possibly describe your issue? The button seems to not be sending a block update when it's replaced via command block.
Thank you for your report!
We're tracking this issue in MC-31100, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
– I am a bot. This action was performed automatically! The ticket was resolved by one of our moderators, and I left this message to give more information to you.
Thank you for your report!
We're tracking this issue in MC-31100, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
– I am a bot. This action was performed automatically! The ticket was resolved by one of our moderators, and I left this message to give more information to you.
Duplicates MC-31100
![[Mod] Jarl-Penguin](../../../data/avatars/users/92849.png){kind=small}
Thank you for your report!
We're tracking this issue in MC-31100, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
Duplicate ofMC-30949Reopened because
MC-30949is 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.
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.
Can confirm for 17w49b
There is no version 17w19b. Can you please look at the window title for the real version name?
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
Confirmed for 1.13-pre6.
Confirmed for 1.13-pre7.
Confirmed for 1.13-pre8.
Confirmed for 1.13-pre9.
Confirmed for 1.13-pre10.
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!
Can confirm in 21w05b.
Still happening in 1.17 snapshots. Is this going to be fixed at some point? It has been a while.
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.