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

SuccessCount of command blocks use the "result" return value of a command instead of "success"


    • Confirmed

      The bug

      In 1.12, when a command block runs a command, its SuccessCount will (typically) be dependent on the number of targets affected, otherwise a simple 1 for success and 0 for failure.

      Now in 1.13, SuccessCount will be the "result" return value rather than a simple 1 or 0 of "success". I'm assuming that a separate return value based on the number of affected targets is not feasible, but result behaves much differently than the old SuccessCount equivalent.

      This has some obscure consequences depending on the command being run, particularly when it comes to the "conditional" setting of a command block, which relies on the previous command's SuccessCount being 1+. Such conditional command blocks will fail to run if the command block behind them succeeded, but had a "result" return value of 0.


      /scoreboard players set will provide a "result" value of playerCount * score. If score was 0, the return value for "result" will be 0. At the same time, the return value of "success" will be 1 since the command did succeed. But a conditional command block will fail due to the use of "result".

      Some example commands to put into an unconditional command block that prevents a conditional command block from running, despite being successful:

      At all times (standard score reset):

      /scoreboard players set @a[scores={OBJ=1..}] OBJ 0

      At all times:

      /weather clear 0

      Only if it's day 0:

      /time query day

      Only if it's Peaceful difficulty:


      Only if the player is in the Overworld:

      /execute as @p[distance=..3] store result score @s OBJ run data get entity @s Dimension

            boq [Mojang] Bartosz Bok
            skylinerw [Mod] Skylinerw
            27 Vote for this issue
            6 Start watching this issue