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

Incorrect and Inconsistent Command Success Criteria breaks Command Block Comparator Behavior



    • Bug
    • Status: Resolved
    • Resolution: Awaiting Response
    • Minecraft 1.5.1, Minecraft 1.5.2, Snapshot 13w19a, Snapshot 13w21a, Snapshot 13w24b, Snapshot 13w25a, Snapshot 13w25b, Snapshot 13w25c, Minecraft 1.6, Minecraft 1.6.1, Minecraft 1.6.2, Minecraft 13w37a, Minecraft 13w37b, Minecraft 1.7, Minecraft 1.7.1, Minecraft 1.7.2, Minecraft 1.7.4, Minecraft 14w04b, Minecraft 1.7.5, Minecraft 14w11b, Minecraft 1.7.6-pre1, Minecraft 1.7.6-pre2, Minecraft 14w32a, Minecraft 14w32b, Minecraft 14w32c, Minecraft 14w32d, Minecraft 1.9.1 Pre-Release 3
    • Snapshot 13w25a
    • Community Consensus


      EDIT: I have added a testing world for conveniently testing various instances of this bug. SMP commands not included.

      First, I would like to mention one thing: the proper acknowledged behavior of a Comparator's output from a Command Block is the number of successes of the last executed command. This isn't only derived from observations - the actual NBT tag name describing the value comparators output is "SuccessCount".

      This comes to the heart of the issue: the game has several commands which report "success" even when, ostensibly, they have failed. As a result, command block comparators will not output a reasonable expected value for these commands, and in fact, can output completely counter-intuitive values. This breaks various designs in command block circuits, as the comparator's output is simply incorrect for certain commands.

      The technical cause of this bug appears to be the messages returned when using a command: if a command returns an error message (typically formatted in red text in chat, when used by a player or console, but obviously never witnessed by anybody when used by a command block), comparators will not consider it successful. Otherwise, it is counted as a success.

      *TL;DR* The bug is that commands determine success/failure based on the messages they would send human users, and certain commands can fail while still being interpreted as successful, while others can succeed while being interpreted as failures, because of bugs in these messages. This breaks these commands' use in command block comparator output, and can also make the commands unintuitive for human users. The rest of this report is a list of commands which exhibit these bugs.

      Affected commands

      • Using lower amplifier
      • Using same amplifier but lower time

      In both cases the "show particles" argument may not change its value else it will update the effect


      The following is based on decompiled version of Minecraft 1.9 using MCP 9.24 beta. All method and class names are the names used in the decompiled version.

      The problem is that the method net.minecraft.command.CommandHelp.execute(MinecraftServer, ICommandSender, String[]) throws a WrongUsageException, instead is should probably only print the correct usage.

      public void execute(MinecraftServer server, ICommandSender sender, String[] args) throws CommandException
          if (sender instanceof CommandBlockBaseLogic)
              sender.addChatMessage((new TextComponentString("Searge says: ")).appendText(seargeSays[this.rand.nextInt(seargeSays.length) % seargeSays.length]));
              List<ICommand> list = this.func_184900_a(sender, server);
              int i = 7;
              int j = (list.size() - 1) / 7;
              int k = 0;
                  k = args.length == 0 ? 0 : parseInt(args[0], 1, j + 1) - 1;
              catch (NumberInvalidException numberinvalidexception)
                  Map<String, ICommand> map = this.func_184899_a(server);
                  ICommand icommand = (ICommand)map.get(args[0]);
                  if (icommand != null)
                      // Replaced this
                      //throw new WrongUsageException(icommand.getCommandUsage(sender), new Object[0]);
                      TextComponentTranslation textComponentTranslation = new TextComponentTranslation("commands.generic.usage", new Object[] {new TextComponentTranslation(icommand.getCommandUsage(sender))});
                  if (MathHelper.parseIntWithDefault(args[0], -1) != -1)
                      throw numberinvalidexception;
                  throw new CommandNotFoundException();
      /ban (and probably /ban-ip)

      Let you ban players multiple times, however only one ban list entry is created


      Always succeeds with a valid IP

      /whitelist on and /whitelist off

      Both always succeed, compared to /save-on and /save-off which fail when used if auto saving is already on respectively off this can be considered a bug

      /scoreboard objectives setdisplay
      • Clears an empty display slot
      • Sets a objective that is already display in the specified slot to be display in that slot
      /scoreboard players reset

      Succeeds even if the entity has no score

      /scoreboard teams join

      Entity which is already in a team can join the same team again

      /scoreboard players tag add

      See MC-87430

      Unaffected command

      These commands are unaffected so you do not have to include them. I just want to point out why they are unaffected.


      Only for MC-76044, however as it stores the incorrect value, the success is correct

      The fact that it saves non existing gamerules is either intended or a different bug


        1. 2013-06-14_16.55.55.png
          229 kB
        2. Gamerule 14w21b.png
          Gamerule 14w21b.png
          221 kB
        3. JIRA Bug Testing.zip
          430 kB

        Issue Links



              Unassigned Unassigned
              marcono1234 [Mod] Marcono1234
              7 Vote for this issue
              7 Start watching this issue