MoJira is migrating! Ensure your account and info transfer by filling out the form here: aka.ms/MojiraMigration by 31st January
Uploaded image for project: 'Minecraft: Java Edition'
  1. Minecraft: Java Edition
  2. MC-133554

Conditional command blocks executing based on previous output of triggering block

    • Icon: Bug Bug
    • Resolution: Duplicate
    • None
    • Minecraft 1.13-pre8, Minecraft 1.13.1
    • None
    • Unconfirmed
    • (Unassigned)

      Command block A is set to "Impulse", "unconditional", "Needs redstone".  It has an execute that is a test returning pass or fail.

      Command block B is set to "Impulse", "Conditional", Needs redstone".  The block behind it is A.  The command is simply a "say"

      Let's say redstone is sent to "A" (a button click) and the execute test passes.  The execute previous output is "test passed". Yet command block B does execute it's "say".

      Click the button again to send redstone to "A" and now "B" fires. 

      Click the button to trigger "A" again, this time having the execute return "test failed".  B fires again!  Click the button again, now B doesn't fire.

      The "conditional" is either always using the test block's previous value to determine whether to fire or not, OR it is firing before the test block's evaluation occurs. One or the other. Either way the behavior is that a test has to be met TWO times in a row for a condition block to execute based on it. And also, if the test block evaluates to false, expect another execution of the conditional block anyway, even though its false.

      I wish others could comment on this. Seems like a very a serious issue. I opened this bug a month and half ago and still fight with it. I did find a way to force the test block to reset after an execution. Execute the "data" command on the command block updating the "SuccessCount" nbt tag to 0.

          Loading...
          MoJira is migrating! Ensure your account and info transfer by filling out the form here: aka.ms/MojiraMigration by 31st January
          Uploaded image for project: 'Minecraft: Java Edition'
          1. Minecraft: Java Edition
          2. MC-133554

          Conditional command blocks executing based on previous output of triggering block

            • Icon: Bug Bug
            • Resolution: Duplicate
            • None
            • Minecraft 1.13-pre8, Minecraft 1.13.1
            • None
            • Unconfirmed
            • (Unassigned)

              Command block A is set to "Impulse", "unconditional", "Needs redstone".  It has an execute that is a test returning pass or fail.

              Command block B is set to "Impulse", "Conditional", Needs redstone".  The block behind it is A.  The command is simply a "say"

              Let's say redstone is sent to "A" (a button click) and the execute test passes.  The execute previous output is "test passed". Yet command block B does execute it's "say".

              Click the button again to send redstone to "A" and now "B" fires. 

              Click the button to trigger "A" again, this time having the execute return "test failed".  B fires again!  Click the button again, now B doesn't fire.

              The "conditional" is either always using the test block's previous value to determine whether to fire or not, OR it is firing before the test block's evaluation occurs. One or the other. Either way the behavior is that a test has to be met TWO times in a row for a condition block to execute based on it. And also, if the test block evaluates to false, expect another execution of the conditional block anyway, even though its false.

              I wish others could comment on this. Seems like a very a serious issue. I opened this bug a month and half ago and still fight with it. I did find a way to force the test block to reset after an execution. Execute the "data" command on the command block updating the "SuccessCount" nbt tag to 0.

                    Unassigned Unassigned
                    MrChoke Adam
                    Votes:
                    0 Vote for this issue
                    Watchers:
                    1 Start watching this issue

                      Created:
                      Updated:
                      Resolved:

                        Unassigned Unassigned
                        MrChoke Adam
                        Votes:
                        0 Vote for this issue
                        Watchers:
                        1 Start watching this issue

                          Created:
                          Updated:
                          Resolved: