/testfor, /testforblock, and /testforblocks are all part of the same group of commands and are similar in what they do after their test. They are only useful when their output is measured using redstone comparators (not recommended) or when combined in a chain with other commands (most often way)
It's quite simple. If the test returns TRUE, any conditional command blocks later in the chain will run (unless stopped by a different failed command in between). If the test returns FALSE, the conditional command blocks won't run.

I would like to invert the check, so that if the entity does not exist /testfor, or if the block is not what is specified /testforblock, or if the block regions don't match/testforblocks, then the subsequent commands in the chain will run, and if the check passes, they will not run. How can I do this?

(I suspect that for /testforblock, it's as simple as placing a ! before the block name, but I'm not sure if the ! operator existed in 1.12. For /testfor and /testforblocks, absolutely no idea.)

Please also consider viewing my other, identical question for Minecraft Bedrock Edition.

  • I'm pretty sure you didn't need testfor in 1.12 either. But it's so long ago that I don't fully remember all alternatives anymore. Sep 16, 2020 at 21:25

2 Answers 2


The way to accomplish this is to use a second (chain, unconditional) command block checking with the command /testforblock <coordinates of first command block> command_block * {SuccessCount:0}, which makes it succeed if the first command block fails (because it's SuccessCount is 0), and fail if the first command block suceeded, allowing you to properly condition things off of the inverse.

If the first command block (that you want to fail) is a repeating or chain command block, then you have to use repeating_command_block or chain_command_block (respectively) instead of just command_block, but the command otherwise works the same.

  • Sorry, I'm not understanding you. The second command block runs regardless of whether the first one suceeds or fails, because it's not conditional. The third command block shouldn't interact with the first one at all.
    – pppery
    Jun 27, 2020 at 23:24
  • Everything that checks if the first command fails should be a conditional chain command block configured to run only if the second command block (with SuccessCount:0) succeeds (and thus not even touching the command block containing the original testfor)
    – pppery
    Jun 27, 2020 at 23:33
  • If I understand what you are saying correctly, then yes. Feel free to edit this answer to clarify whatever you thought was unclear about it.
    – pppery
    Jun 27, 2020 at 23:40

Adding onto @pppery's answer, you should place the second and third commands in a different chain. If you place them in one chain, this will happen when the /say was supposed to run:

REPEAT, UNCONDITIONAL: /testfor @e[type=MyEntity] || FAILS: The entity was not found.
CHAIN, UNCONDITIONAL: /testforblock x y z command_block * {SuccessCount:0} || PASSES: The first command block did not pass.
CHAIN, CONDITIONAL: /say The first command block failed. || Does not run. The first command failed, and for this to run, both previous ones had to pass, which is impossible since at least one command is bound to fail.

If you change it into two chains, this happens:

REPEAT, UNCONDITIONAL: /testfor @e[type=MyEntity]
REPEAT, UNCONDITIONAL: /testforblock x y z command_block * {SuccessCount:0} || PASSES: The first command block did not pass.
CHAIN, CONDITIONAL: /say The first command block failed. || RUNS: All previous commands passed.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .