The Bug
If you set the block that is on top of a block that cannot produce soul fire if you use a flint and steel on it (i.e. Netherrack) to soul fire, it will still say that the block is changed even though nothing happens
Steps to Reproduce
Stand on top of a block that soul fire cannot exist on.
Summon some soul fire above the block you're standing on.
/setblock ~ ~ ~ minecraft:soul_fire
Take note as to whether or not using the "/setblock" command to summon soul fire on top of invalid blocks, prints a success message despite the operation failing.
Observed Behavior
Using the "/setblock" command to summon soul fire on top of invalid blocks, prints a success message despite the operation failing.
Expected Behavior
Using the "/setblock" command to summon soul fire on top of invalid blocks, would print an error message.
Linked issues
Attachments
Comments 13
For the issue here (the setblock sometimes gives a success message even if it fails) I cannot seem to find another report that this could duplicate
I believe that the soul fire is placed, but then disappears after a tick because the block beneath it is invalid for placing it on
Can confirm this behavior in 21w42a. Here are some extra details regarding this problem.
The Bug:
Using the "/setblock" command to summon soul fire on top of invalid blocks, prints a success message despite the operation failing.
Steps to Reproduce:
Stand on top of a block that soul fire cannot exist on.
Summon some soul fire above the block you're standing on.
/setblock ~ ~ ~ minecraft:soul_fire
Take note as to whether or not using the "/setblock" command to summon soul fire on top of invalid blocks, prints a success message despite the operation failing.
Observed Behavior:
Using the "/setblock" command to summon soul fire on top of invalid blocks, prints a success message despite the operation failing.
Expected Behavior:
Using the "/setblock" command to summon soul fire on top of invalid blocks, would print an error message.
The fact that you can only set soul fire on top of soul blocks is intended, see MC-173212
I guess the issue here is that the setblock sometimes gives a success message even if it fails, but that also affects a lot of other cases probably. There may be another ticket for that.