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
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.
- 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.
Let you ban players multiple times, however only one ban list entry is created
Always succeeds with a valid IP
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
- Clears an empty display slot
- Sets a objective that is already display in the specified slot to be display in that slot
Succeeds even if the entity has no score
Entity which is already in a team can join the same team again
These commands are unaffected so you do not have to include them. I just want to point out why they are unaffected.
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