Uploaded image for project: 'Minecraft: Java Edition'
  1. Minecraft: Java Edition
  2. MC-88446

Unconditional impulse command blocks interact unexpectedly with conditionMet

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Resolution: Fixed
    • Affects Version/s: Minecraft 15w37a
    • Fix Version/s: Minecraft 15w38a
    • Labels:
      None
    • Confirmation Status:
      Unconfirmed

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                searge [Mojang] Searge (Michael Stoyke)
                Reporter:
                brianmcn Brian McNamara
              • Votes:
                1 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: