Incorrect and Inconsistent Command Success Criteria breaks Command Block Comparator Behavior

I think MC-13236 should either be added as a related bug to this, or perhaps closed as a duplicate (it wouldn't be the first time an earlier report was closed as a duplicate of a later one).

This report is intended to cover the general bug of "command uses non-error-message to display failure, or uses error-message even if no failure occured", as that's the heart of the bug. While it's true that any fix to this bug (including redefining success to be independent of error messages) would require changes in several places in the code, I feel they should all be grouped together as a single report because they are all instances of the same bug.

I've uploaded my bugtesting world - the red carpet marks around a dozen units which can be used to easily test the various instances of this bug.

Feel free to ignore sections with other colors of carpet - those are for unrelated bugs.

Some of these issues are fixed in the next snapshot, but not all of them. As you've made one mega-ticket and not individual ones linked up together, I'm unable to mark it for the state it actually is.

Ah, sorry. I'll check which ones are fixed on the snapshot, and cross them off.

Dang, I hate how the enchantment bug was fixed. It was useful to adventure maps for seeing what the item is that players are holding!

Please resolve it as "Awaiting response" please, same goes for all other reports you closed as "Incomplete"

If there is no response for over a full year, they are not going to stay as awaiting response.

Those tickets are incomplete without the requested information, no response has been received within a reasonable time (1 full year) and we are assuming these issues has been resolved. If you are still experiencing these issues, we can reopen them at your request.

Confirmed for

• 1.9.1-pre3

Affected commands

/effect

• 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

/help

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]));
    }
    else
    {
        List<ICommand> list = this.func_184900_a(sender, server);
        int i = 7;
        int j = (list.size() - 1) / 7;
        int k = 0;

        try
        {
            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))});
                sender.addChatMessage(textComponentTranslation);
                return;
            }

            if (MathHelper.parseIntWithDefault(args[0], -1) != -1)
            {
                throw numberinvalidexception;
            }

            throw new CommandNotFoundException();
        }

        //...
    }
}

/pardon-ip

Always succeeds

/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

Unaffected command

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

/gamerule

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

Changed reporter to @unknown.

Is this still an issue in the most recent versions (currently that is 1.10.2, or 16w42a) of Minecraft? If so, please update the affected versions and help us keeping this ticket updated from time to time. If you are the owner/reporter of this ticket, you can modify the affected version(s) yourself.