MC-88446Unconditional impulse command blocks interact unexpectedly with conditionMet
Here is a very simple bug in impulse command blocks. Go stand in a new superflat world and type this
/setblock ~1 ~ ~ command_block 3 replace {Command:"say 1"}
/setblock ~1 ~ ~1 chain_command_block 3 replace {Command:"say 2",auto:1b}
/blockdata ~1 ~ ~ {auto:1b}
Expected: "1 2" Actual: "2"
Compare:
/setblock ~1 ~ ~ command_block 3 replace {Command:"say 1"}
/setblock ~1 ~ ~1 chain_command_block 3 replace {Command:"say 2",auto:1b}
/setblock ~1 ~ ~-1 redstone_block
Expected: "1 2" Actual: "1 2"
The reason for the difference is that even UNconditional ICBs respect the 'conditionMet' flag, and conditionMet defaults to 0. A block update will change it to 1, but auto:1b activation doesn't cause the update the first time.
You can witness this more directly by doing
/setblock ~1 ~ ~-1 air
/setblock ~1 ~ ~ command_block 3 replace {Command:"say 1"}
/setblock ~1 ~ ~1 chain_command_block 3 replace {Command:"say 2",auto:1b}
/blockdata ~1 ~ ~ {conditionMet:1b}
/blockdata ~1 ~ ~ {auto:1b}
to show that conditionMet is the culprit.
There are two ways this could be fixed. One is to have conditionMet default to 1. That is the wrong fix, in my opinion, because after that fix,
/setblock ~1 ~ ~ command_block 3 replace {Command:"say 1"}
/setblock ~1 ~ ~1 chain_command_block 3 replace {Command:"say 2",auto:1b}
/blockdata ~1 ~ ~ {conditionMet:0b}
/blockdata ~1 ~ ~ {auto:1b}
would probably still print "2" instead of the expected "1 2".
The correct fix is to change the behavior of orange blocks, so that UNconditional oranges are completely ignoring the conditionMet flag.
Overall, my expectation is that
- UNconditional blocks ought not be affected by conditionMet, and
- in general, redstone activation and auto:1b activation should behave similarly (principle of least surprise), modulo block updates caused by the former
Note: the repro steps in this bug use 'setblock', but it is easier to simply /give yourself the blocks, place them, and set the 'say' commands. I just wanted to make things completely unambiguous.
Created Issue:
Unconditional impulse command blocks interact unexpectedly with conditionMet
Here is a very simple bug in impulse command blocks.
/setblock ~1 ~ ~ command_block 3 replace
{Command:"say 1"}/setblock ~1 ~ ~1 chain_command_block 3 replace
{Command:"say 2",auto:1b}/blockdata ~1 ~ ~
{auto:1b}Expected: "1 2" Actual: "2"
Compare:
/setblock ~1 ~ ~ command_block 3 replace
{Command:"say 1"}/setblock ~1 ~ ~1 chain_command_block 3 replace
{Command:"say 2",auto:1b}/setblock ~1 ~ ~-1 redstone_block
Expected: "1 2" Actual: "1 2"
The reason for the difference is that even UNconditional ICBs respect the 'conditionMet' flag, and conditionMet defaults to 0. A block update will change it to 1, but auto:1b activation doesn't cause the update the first time.
You can witness this more directly by doing
/setblock ~1 ~ ~-1 air
{Command:"say 1"}
/setblock ~1 ~ ~ command_block 3 replace/setblock ~1 ~ ~1 chain_command_block 3 replace
{Command:"say 2",auto:1b}/blockdata ~1 ~ ~
{conditionMet:1b}/blockdata ~1 ~ ~
{auto:1b}to show that conditionMet is the culprit.
There are two ways this could be fixed. One is to have conditionMet default to 1. That is the wrong fix, in my opinion, because after that fix,
/setblock ~1 ~ ~ command_block 3 replace
{Command:"say 1"}/setblock ~1 ~ ~1 chain_command_block 3 replace
{Command:"say 2",auto:1b}/blockdata ~1 ~ ~
{conditionMet:0b}/blockdata ~1 ~ ~
{auto:1b}would probably still print "2" instead of the expected "1 2".
The correct fix is to change the behavior of orange blocks, so that UNconditional oranges are completely ignoring the conditionMet flag.
Overall, my expectation is that
- UNconditional blocks ought not be affected by conditionMet, and
- in general, redstone activation and auto:1b activation should behave similarly (principle of least surprise), modulo block updates caused by the former
Note: the repro steps in this bug use 'setblock', but it is easier to simply /give yourself the blocks, place them, and set the 'say' commands. I just wanted to make things completely unambiguous.
Here is a very simple bug in impulse command blocks.
/setblock ~1 ~ ~ command_block 3 replace
{Command:"say 1"}/setblock ~1 ~ ~1 chain_command_block 3 replace
{Command:"say 2",auto:1b}/blockdata ~1 ~ ~
{auto:1b}Expected: "1 2" Actual: "2"
Compare:
/setblock ~1 ~ ~ command_block 3 replace
{Command:"say 1"}/setblock ~1 ~ ~1 chain_command_block 3 replace
{Command:"say 2",auto:1b}/setblock ~1 ~ ~-1 redstone_block
Expected: "1 2" Actual: "1 2"
The reason for the difference is that even UNconditional ICBs respect the 'conditionMet' flag, and conditionMet defaults to 0. A block update will change it to 1, but auto:1b activation doesn't cause the update the first time.
You can witness this more directly by doing
/setblock ~1 ~ ~-1 air
{Command:"say 1"}
/setblock ~1 ~ ~ command_block 3 replace/setblock ~1 ~ ~1 chain_command_block 3 replace
{Command:"say 2",auto:1b}/blockdata ~1 ~ ~
{conditionMet:1b}/blockdata ~1 ~ ~
{auto:1b}to show that conditionMet is the culprit.
There are two ways this could be fixed. One is to have conditionMet default to 1. That is the wrong fix, in my opinion, because after that fix,
/setblock ~1 ~ ~ command_block 3 replace
{Command:"say 1"}/setblock ~1 ~ ~1 chain_command_block 3 replace
{Command:"say 2",auto:1b}/blockdata ~1 ~ ~
{conditionMet:0b}/blockdata ~1 ~ ~
{auto:1b}would probably still print "2" instead of the expected "1 2".
The correct fix is to change the behavior of orange blocks, so that UNconditional oranges are completely ignoring the conditionMet flag.
Overall, my expectation is that
- UNconditional blocks ought not be affected by conditionMet, and
- in general, redstone activation and auto:1b activation should behave similarly (principle of least surprise), modulo block updates caused by the former
Note: the repro steps in this bug use 'setblock', but it is easier to simply /give yourself the blocks, place them, and set the 'say' commands. I just wanted to make things completely unambiguous.
Here is a very simple bug in impulse command blocks.
{Command:"say 1"}
{{
/setblock ~1 ~ ~ command_block 3 replace/setblock ~1 ~ ~1 chain_command_block 3 replace
{Command:"say 2",auto:1b}/blockdata ~1 ~ ~
{auto:1b}}}
Expected: "1 2" Actual: "2"Compare:
/setblock ~1 ~ ~ command_block 3 replace
{Command:"say 1"}/setblock ~1 ~ ~1 chain_command_block 3 replace
{Command:"say 2",auto:1b}/setblock ~1 ~ ~-1 redstone_block
Expected: "1 2" Actual: "1 2"
The reason for the difference is that even UNconditional ICBs respect the 'conditionMet' flag, and conditionMet defaults to 0. A block update will change it to 1, but auto:1b activation doesn't cause the update the first time.
You can witness this more directly by doing
/setblock ~1 ~ ~-1 air
{Command:"say 1"}
/setblock ~1 ~ ~ command_block 3 replace/setblock ~1 ~ ~1 chain_command_block 3 replace
{Command:"say 2",auto:1b}/blockdata ~1 ~ ~
{conditionMet:1b}/blockdata ~1 ~ ~
{auto:1b}to show that conditionMet is the culprit.
There are two ways this could be fixed. One is to have conditionMet default to 1. That is the wrong fix, in my opinion, because after that fix,
/setblock ~1 ~ ~ command_block 3 replace
{Command:"say 1"}/setblock ~1 ~ ~1 chain_command_block 3 replace
{Command:"say 2",auto:1b}/blockdata ~1 ~ ~
{conditionMet:0b}/blockdata ~1 ~ ~
{auto:1b}would probably still print "2" instead of the expected "1 2".
The correct fix is to change the behavior of orange blocks, so that UNconditional oranges are completely ignoring the conditionMet flag.
Overall, my expectation is that
- UNconditional blocks ought not be affected by conditionMet, and
- in general, redstone activation and auto:1b activation should behave similarly (principle of least surprise), modulo block updates caused by the former
Note: the repro steps in this bug use 'setblock', but it is easier to simply /give yourself the blocks, place them, and set the 'say' commands. I just wanted to make things completely unambiguous.
Here is a very simple bug in impulse command blocks.
{Command:"say 1"}
{{
/setblock ~1 ~ ~ command_block 3 replace/setblock ~1 ~ ~1 chain_command_block 3 replace
{Command:"say 2",auto:1b}/blockdata ~1 ~ ~
{auto:1b}}}
Expected: "1 2" Actual: "2"Compare:
/setblock ~1 ~ ~ command_block 3 replace
{Command:"say 1"}/setblock ~1 ~ ~1 chain_command_block 3 replace
{Command:"say 2",auto:1b}/setblock ~1 ~ ~-1 redstone_block
Expected: "1 2" Actual: "1 2"
The reason for the difference is that even UNconditional ICBs respect the 'conditionMet' flag, and conditionMet defaults to 0. A block update will change it to 1, but auto:1b activation doesn't cause the update the first time.
You can witness this more directly by doing
/setblock ~1 ~ ~-1 air
{Command:"say 1"}
/setblock ~1 ~ ~ command_block 3 replace/setblock ~1 ~ ~1 chain_command_block 3 replace
{Command:"say 2",auto:1b}/blockdata ~1 ~ ~
{conditionMet:1b}/blockdata ~1 ~ ~
{auto:1b}to show that conditionMet is the culprit.
There are two ways this could be fixed. One is to have conditionMet default to 1. That is the wrong fix, in my opinion, because after that fix,
/setblock ~1 ~ ~ command_block 3 replace
{Command:"say 1"}/setblock ~1 ~ ~1 chain_command_block 3 replace
{Command:"say 2",auto:1b}/blockdata ~1 ~ ~
{conditionMet:0b}/blockdata ~1 ~ ~
{auto:1b}would probably still print "2" instead of the expected "1 2".
The correct fix is to change the behavior of orange blocks, so that UNconditional oranges are completely ignoring the conditionMet flag.
Overall, my expectation is that
- UNconditional blocks ought not be affected by conditionMet, and
- in general, redstone activation and auto:1b activation should behave similarly (principle of least surprise), modulo block updates caused by the former
Note: the repro steps in this bug use 'setblock', but it is easier to simply /give yourself the blocks, place them, and set the 'say' commands. I just wanted to make things completely unambiguous.
Here is a very simple bug in impulse command blocks.
/setblock ~1 ~ ~ command_block 3 replace
{Command:"say 1"}/setblock ~1 ~ ~1 chain_command_block 3 replace
{Command:"say 2",auto:1b}/blockdata ~1 ~ ~
{auto:1b}Expected: "1 2" Actual: "2"
Compare:
/setblock ~1 ~ ~ command_block 3 replace
{Command:"say 1"}/setblock ~1 ~ ~1 chain_command_block 3 replace
{Command:"say 2",auto:1b}/setblock ~1 ~ ~-1 redstone_block
Expected: "1 2" Actual: "1 2"
The reason for the difference is that even UNconditional ICBs respect the 'conditionMet' flag, and conditionMet defaults to 0. A block update will change it to 1, but auto:1b activation doesn't cause the update the first time.
You can witness this more directly by doing
/setblock ~1 ~ ~-1 air
{Command:"say 1"}
/setblock ~1 ~ ~ command_block 3 replace/setblock ~1 ~ ~1 chain_command_block 3 replace
{Command:"say 2",auto:1b}/blockdata ~1 ~ ~
{conditionMet:1b}/blockdata ~1 ~ ~
{auto:1b}to show that conditionMet is the culprit.
There are two ways this could be fixed. One is to have conditionMet default to 1. That is the wrong fix, in my opinion, because after that fix,
/setblock ~1 ~ ~ command_block 3 replace
{Command:"say 1"}/setblock ~1 ~ ~1 chain_command_block 3 replace
{Command:"say 2",auto:1b}/blockdata ~1 ~ ~
{conditionMet:0b}/blockdata ~1 ~ ~
{auto:1b}would probably still print "2" instead of the expected "1 2".
The correct fix is to change the behavior of orange blocks, so that UNconditional oranges are completely ignoring the conditionMet flag.
Overall, my expectation is that
- UNconditional blocks ought not be affected by conditionMet, and
- in general, redstone activation and auto:1b activation should behave similarly (principle of least surprise), modulo block updates caused by the former
Note: the repro steps in this bug use 'setblock', but it is easier to simply /give yourself the blocks, place them, and set the 'say' commands. I just wanted to make things completely unambiguous.
Here is a very simple bug in impulse command blocks.
/setblock ~1 ~ ~ command_block 3 replace
{Command:"say 1"}/setblock ~1 ~ ~1 chain_command_block 3 replace
{Command:"say 2",auto:1b}/blockdata ~1 ~ ~
{auto:1b}Expected: "1 2" Actual: "2"
Compare:
/setblock ~1 ~ ~ command_block 3 replace
{Command:"say 1"}/setblock ~1 ~ ~1 chain_command_block 3 replace
{Command:"say 2",auto:1b}/setblock ~1 ~ ~-1 redstone_block
Expected: "1 2" Actual: "1 2"
The reason for the difference is that even UNconditional ICBs respect the 'conditionMet' flag, and conditionMet defaults to 0. A block update will change it to 1, but auto:1b activation doesn't cause the update the first time.
You can witness this more directly by doing
/setblock ~1 ~ ~-1 air
{Command:"say 1"}
/setblock ~1 ~ ~ command_block 3 replace/setblock ~1 ~ ~1 chain_command_block 3 replace
{Command:"say 2",auto:1b}/blockdata ~1 ~ ~
{conditionMet:1b}/blockdata ~1 ~ ~
{auto:1b}to show that conditionMet is the culprit.
There are two ways this could be fixed. One is to have conditionMet default to 1. That is the wrong fix, in my opinion, because after that fix,
/setblock ~1 ~ ~ command_block 3 replace
{Command:"say 1"}/setblock ~1 ~ ~1 chain_command_block 3 replace
{Command:"say 2",auto:1b}/blockdata ~1 ~ ~
{conditionMet:0b}/blockdata ~1 ~ ~
{auto:1b}would probably still print "2" instead of the expected "1 2".
The correct fix is to change the behavior of orange blocks, so that UNconditional oranges are completely ignoring the conditionMet flag.
Overall, my expectation is that
- UNconditional blocks ought not be affected by conditionMet, and
- in general, redstone activation and auto:1b activation should behave similarly (principle of least surprise), modulo block updates caused by the former
Note: the repro steps in this bug use 'setblock', but it is easier to simply /give yourself the blocks, place them, and set the 'say' commands. I just wanted to make things completely unambiguous.
Here is a very simple bug in impulse command blocks.
/setblock ~1 ~ ~ command_block 3 replace {Command:"say 1"} /setblock ~1 ~ ~1 chain_command_block 3 replace {Command:"say 2",auto:1b} /blockdata ~1 ~ ~ {auto:1b}Expected: "1 2" Actual: "2"
Compare:
/setblock ~1 ~ ~ command_block 3 replace
{Command:"say 1"}/setblock ~1 ~ ~1 chain_command_block 3 replace
{Command:"say 2",auto:1b}/setblock ~1 ~ ~-1 redstone_block
Expected: "1 2" Actual: "1 2"
The reason for the difference is that even UNconditional ICBs respect the 'conditionMet' flag, and conditionMet defaults to 0. A block update will change it to 1, but auto:1b activation doesn't cause the update the first time.
You can witness this more directly by doing
/setblock ~1 ~ ~-1 air
{Command:"say 1"}
/setblock ~1 ~ ~ command_block 3 replace/setblock ~1 ~ ~1 chain_command_block 3 replace
{Command:"say 2",auto:1b}/blockdata ~1 ~ ~
{conditionMet:1b}/blockdata ~1 ~ ~
{auto:1b}to show that conditionMet is the culprit.
There are two ways this could be fixed. One is to have conditionMet default to 1. That is the wrong fix, in my opinion, because after that fix,
/setblock ~1 ~ ~ command_block 3 replace
{Command:"say 1"}/setblock ~1 ~ ~1 chain_command_block 3 replace
{Command:"say 2",auto:1b}/blockdata ~1 ~ ~
{conditionMet:0b}/blockdata ~1 ~ ~
{auto:1b}would probably still print "2" instead of the expected "1 2".
The correct fix is to change the behavior of orange blocks, so that UNconditional oranges are completely ignoring the conditionMet flag.
Overall, my expectation is that
- UNconditional blocks ought not be affected by conditionMet, and
- in general, redstone activation and auto:1b activation should behave similarly (principle of least surprise), modulo block updates caused by the former
Note: the repro steps in this bug use 'setblock', but it is easier to simply /give yourself the blocks, place them, and set the 'say' commands. I just wanted to make things completely unambiguous.
Here is a very simple bug in impulse command blocks.
/setblock ~1 ~ ~ command_block 3 replace {Command:"say 1"} /setblock ~1 ~ ~1 chain_command_block 3 replace {Command:"say 2",auto:1b} /blockdata ~1 ~ ~ {auto:1b}Expected: "1 2" Actual: "2"
Compare:
/setblock ~1 ~ ~ command_block 3 replace
{Command:"say 1"}/setblock ~1 ~ ~1 chain_command_block 3 replace
{Command:"say 2",auto:1b}/setblock ~1 ~ ~-1 redstone_block
Expected: "1 2" Actual: "1 2"
The reason for the difference is that even UNconditional ICBs respect the 'conditionMet' flag, and conditionMet defaults to 0. A block update will change it to 1, but auto:1b activation doesn't cause the update the first time.
You can witness this more directly by doing
/setblock ~1 ~ ~-1 air
{Command:"say 1"}
/setblock ~1 ~ ~ command_block 3 replace/setblock ~1 ~ ~1 chain_command_block 3 replace
{Command:"say 2",auto:1b}/blockdata ~1 ~ ~
{conditionMet:1b}/blockdata ~1 ~ ~
{auto:1b}to show that conditionMet is the culprit.
There are two ways this could be fixed. One is to have conditionMet default to 1. That is the wrong fix, in my opinion, because after that fix,
{Command:"say 1"}
/setblock ~1 ~ ~ command_block 3 replace/setblock ~1 ~ ~1 chain_command_block 3 replace
{Command:"say 2",auto:1b}/blockdata ~1 ~ ~
{conditionMet:0b}/blockdata ~1 ~ ~
{auto:1b}would probably still print "2" instead of the expected "1 2".
The correct fix is to change the behavior of orange blocks, so that UNconditional oranges are completely ignoring the conditionMet flag.
Overall, my expectation is that
- UNconditional blocks ought not be affected by conditionMet, and
- in general, redstone activation and auto:1b activation should behave similarly (principle of least surprise), modulo block updates caused by the former
Note: the repro steps in this bug use 'setblock', but it is easier to simply /give yourself the blocks, place them, and set the 'say' commands. I just wanted to make things completely unambiguous.
Here is a very simple bug in impulse command blocks.
/setblock ~1 ~ ~ command_block 3 replace {Command:"say 1"} /setblock ~1 ~ ~1 chain_command_block 3 replace {Command:"say 2",auto:1b} /blockdata ~1 ~ ~ {auto:1b}Expected: "1 2" Actual: "2"
Compare:
/setblock ~1 ~ ~ command_block 3 replace {Command:"say 1"} /setblock ~1 ~ ~1 chain_command_block 3 replace {Command:"say 2",auto:1b} /setblock ~1 ~ ~-1 redstone_blockExpected: "1 2" Actual: "1 2"
The reason for the difference is that even UNconditional ICBs respect the 'conditionMet' flag, and conditionMet defaults to 0. A block update will change it to 1, but auto:1b activation doesn't cause the update the first time.
You can witness this more directly by doing
/setblock ~1 ~ ~-1 air /setblock ~1 ~ ~ command_block 3 replace {Command:"say 1"} /setblock ~1 ~ ~1 chain_command_block 3 replace {Command:"say 2",auto:1b} /blockdata ~1 ~ ~ {conditionMet:1b} /blockdata ~1 ~ ~ {auto:1b}to show that conditionMet is the culprit.
There are two ways this could be fixed. One is to have conditionMet default to 1. That is the wrong fix, in my opinion, because after that fix,
/setblock ~1 ~ ~ command_block 3 replace {Command:"say 1"} /setblock ~1 ~ ~1 chain_command_block 3 replace {Command:"say 2",auto:1b} /blockdata ~1 ~ ~ {conditionMet:0b} /blockdata ~1 ~ ~ {auto:1b}would probably still print "2" instead of the expected "1 2".
The correct fix is to change the behavior of orange blocks, so that UNconditional oranges are completely ignoring the conditionMet flag.
Overall, my expectation is that
- UNconditional blocks ought not be affected by conditionMet, and
- in general, redstone activation and auto:1b activation should behave similarly (principle of least surprise), modulo block updates caused by the former
Note: the repro steps in this bug use 'setblock', but it is easier to simply /give yourself the blocks, place them, and set the 'say' commands. I just wanted to make things completely unambiguous.
Here is a very simple bug in impulse command blocks. Go stand in a new superflat world and type this
/setblock ~1 ~ ~ command_block 3 replace {Command:"say 1"} /setblock ~1 ~ ~1 chain_command_block 3 replace {Command:"say 2",auto:1b} /blockdata ~1 ~ ~ {auto:1b}Expected: "1 2" Actual: "2"
Compare:
/setblock ~1 ~ ~ command_block 3 replace {Command:"say 1"} /setblock ~1 ~ ~1 chain_command_block 3 replace {Command:"say 2",auto:1b} /setblock ~1 ~ ~-1 redstone_blockExpected: "1 2" Actual: "1 2"
The reason for the difference is that even UNconditional ICBs respect the 'conditionMet' flag, and conditionMet defaults to 0. A block update will change it to 1, but auto:1b activation doesn't cause the update the first time.
You can witness this more directly by doing
/setblock ~1 ~ ~-1 air /setblock ~1 ~ ~ command_block 3 replace {Command:"say 1"} /setblock ~1 ~ ~1 chain_command_block 3 replace {Command:"say 2",auto:1b} /blockdata ~1 ~ ~ {conditionMet:1b} /blockdata ~1 ~ ~ {auto:1b}to show that conditionMet is the culprit.
There are two ways this could be fixed. One is to have conditionMet default to 1. That is the wrong fix, in my opinion, because after that fix,
/setblock ~1 ~ ~ command_block 3 replace {Command:"say 1"} /setblock ~1 ~ ~1 chain_command_block 3 replace {Command:"say 2",auto:1b} /blockdata ~1 ~ ~ {conditionMet:0b} /blockdata ~1 ~ ~ {auto:1b}would probably still print "2" instead of the expected "1 2".
The correct fix is to change the behavior of orange blocks, so that UNconditional oranges are completely ignoring the conditionMet flag.
Overall, my expectation is that
- UNconditional blocks ought not be affected by conditionMet, and
- in general, redstone activation and auto:1b activation should behave similarly (principle of least surprise), modulo block updates caused by the former
Note: the repro steps in this bug use 'setblock', but it is easier to simply /give yourself the blocks, place them, and set the 'say' commands. I just wanted to make things completely unambiguous.
![[Mojang] Searge (Michael Stoyke)](../../../data/assets/gravatar/searge.png){kind=small}
[Mojang] Searge (Michael Stoyke)![[Mod] redstonehelper](../../../data/avatars/users/10122.svg){kind=small}
is duplicated by
relates to
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
No, the issue is not block updates, it's definitely conditionMet.
In
MC-87639I wrote also other strang behavioursSo this bug is maybe rather caused by the fact that changing the auto tag acts different than powering a command block