Incorrect and Inconsistent Command Success Criteria breaks Command Block Comparator Behavior
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
/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(); } //... } }
/ban (and probably /ban-ip)
Let you ban players multiple times, however only one ban list entry is created
/pardon-ip
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.
/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
Linked Issues
is duplicated by5
MC-13236Command block enchant command reports success DuplicateMC-17565The /clear command always give out signal with comparaor only on server! (read all)DuplicateMC-17607/enchant command block isueDuplicateMC-47347Command blocks with /playsound always give out positive redstone signal even when no sound is played or no player is fround.DuplicateMC-66655Command block returns true when it shouldn'tDuplicate
Created Issue:
Incorrect and Inconsistent Command Success Criteria breaks Command Block Comparator Behavior
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.
I have created two lists of commands which are effected by (or cause, depending on your interpretation) this bug. This first list contains the "true bug" commands, where the behavior is clearly incorrect and should likely be fixed.
- effect: This command reports success even if an effect was not successfully given. If a player has an effect at a higher level or duration than the command attempts to apply, the effect will not be applied (as is expected by standard status effect behavior), and yet the command will report its success (which is not expected; after all, it reports an error when it fails to remove an effect).
- enchant: This command will report its failure only if it cannot find a player, the enchantment ID is nonexistent, or the enchantment level is invalid for this enchantment and the enchantment is valid for this item and this item does not have conflicting enchantments. It's unusual, but this command will report success when attempting to enchant an item which does not support the given enchantment - even if the given enchantment also does not support the specified level! This behavior is rather counter-intuitive: if you specify an enchantment with an invalid level, it returns a failure if the player is holding an item which otherwise can accept this enchantment, and it returns a success if the player is holding an item which cannot accept it. Also, in case you missed it in my first sentence, yes, the command will also "succeed" if there is a conflicting enchantment and thus the enchantment could not be applied. This is likely the most "backwards" command in this entire report.
- gamerule: The little engine that couldn't fail. You can pass this command nonexistent gamerules. You can pass it values other than true and false. Regardless of your parameters, it always succeeds. It will actually even store these invalid values in the level.dat if your gamerule is valid - the resulting behavior, however, isn't defined. Needless to say, it also succeeds if you set a gamerule to its current value, despite the fact that this results in no change - shame, as it means you can't test for the value of a gamerule, but that's probably the least of this command's problems.
- weather: I'm sure many a player is disappointed to see that, although "/weather snow", "/weather tornado 10000", etc. succeed, nothing actually happens. That's right; this command actually doesn't give the user any message whatsoever when a nonexistent weather condition is used - and thus, it is considered successful.
- scoreboard objectives add: Some commands erronously report failure when they've succeeded, and this is one of them. If you give the command a Display Name that's longer than 32 characters, the game will give an error and act like the objective was not created. Nevertheless, the objective is created, and its Display Name is its internal name instead. This certainly goes beyond just command block comparator output; it's unintuitive when typing the command in chat as well.
- scoreboard teams add: See above; this command is plagued by exactly the same behavior.
- scoreboard teams leave: This command won't settle for anything less than 100%. If at least one player it attempts to remove is not on a team, it will output 0, as though it completely failed, rather than outputting the number of players which it did successfully remove. Even if it doesn't fail to remove anybody, the highest it will output is 1 success regardless of the actual number of players removed.
This second list contains cases where it's debatable whether or not there is any bug (essentially, the ones where my idea of "correct behavior" may just be some else's idea of "feature request"). I'm fine with moving this second list down to the comments if this becomes an issue to anybody - I just figured this was the best place to list them if they indeed are also part of this bug. I suppose moderators (and myself) can also move items between these two lists.
- help: Counter-intuitively fails if commandname is a valid command. Also fails if commandname is not valid, but that would be proper behavior. The only reason I am including this command in the second list is because its use with comparators would be limited: at most, you could determine which commands are available if this is fixed. If we ignore mods, plugins, and other non-vanilla content, this is only helpful in determining what game version a map is running on (e.g. to tell the player they need to upgrade to a version with the desired command), or whether or not the map is running on a server (and server-specific commands themselves offer an alternate way to do this anyhow).
- give: Far from the biggest issue, but it seems that the command won't give an error when invalid damage values are used, even if the resulting items ignore these damage values. For example, it won't complain about negative armor damage; it merely spawns the item with zero damage instead.
- deop: I always found it funny that deop works on non-ops. This barely applies to this bug, as command blocks can't use the command anyhow, which is why I put it in the second list.
- pardon: See above, it works on non-banned players.
- pardon-ip: See above, it works on non-banned IPs.
- whitelist remove: See above, players don't have to be on the whitelist to be removed.
- save-off and save-on: Again, not a big deal, but I find it strange that you can disable world saving when it's already disabled, and enable it when it's already enabled. OPs could tell if this setting has been changed, if the command would give an error when using it has no effect. Once again, I realize this command can't be used in command blocks, hence its inclusion in the second list.
- whitelist on/off: See above; the command succeeds even when it has no effect because the whitelist is already on/off.
- scoreboard objectives setdisplay: I find it odd that there's no complaint when clearing an empty display slot, or setting it to an objective that's already displayed in that slot, as neither of these have an effect.
- scoreboard players reset: This one has a little more merit: it succeeds even in the player has no tracked scores. If that weren't the case, you could tell who hasn't been tracked by the scoreboard system at all.
- scoreboard teams join: I won't complain about the fact that you can add players who aren't online (and may not exist), as that's actually useful. However, I find it strange that you can add a player to a team even if they're already on it.
*TL;DR* If you were looking for a TL;DR, it's the 4th paragraph from the top
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.
I have created two lists of commands which are effected by (or cause, depending on your interpretation) this bug. This first list contains the "true bug" commands, where the behavior is clearly incorrect and should likely be fixed.
- effect: This command reports success even if an effect was not successfully given. If a player has an effect at a higher level or duration than the command attempts to apply, the effect will not be applied (as is expected by standard status effect behavior), and yet the command will report its success (which is not expected; after all, it reports an error when it fails to remove an effect).
- enchant: This command will report its failure only if it cannot find a player, the enchantment ID is nonexistent, or the enchantment level is invalid for this enchantment and the enchantment is valid for this item and this item does not have conflicting enchantments. It's unusual, but this command will report success when attempting to enchant an item which does not support the given enchantment - even if the given enchantment also does not support the specified level! This behavior is rather counter-intuitive: if you specify an enchantment with an invalid level, it returns a failure if the player is holding an item which otherwise can accept this enchantment, and it returns a success if the player is holding an item which cannot accept it. Also, in case you missed it in my first sentence, yes, the command will also "succeed" if there is a conflicting enchantment and thus the enchantment could not be applied. This is likely the most "backwards" command in this entire report.
- gamerule: The little engine that couldn't fail. You can pass this command nonexistent gamerules. You can pass it values other than true and false. Regardless of your parameters, it always succeeds. It will actually even store these invalid values in the level.dat if your gamerule is valid - the resulting behavior, however, isn't defined. Needless to say, it also succeeds if you set a gamerule to its current value, despite the fact that this results in no change - shame, as it means you can't test for the value of a gamerule, but that's probably the least of this command's problems.
- weather: I'm sure many a player is disappointed to see that, although "/weather snow", "/weather tornado 10000", etc. succeed, nothing actually happens. That's right; this command actually doesn't give the user any message whatsoever when a nonexistent weather condition is used - and thus, it is considered successful. Amusingly enough, it also accepts extra parameters after after the time is specified, so commands of the form "/weather clear 1000000 dammit, I hate rain" actually execute and report success.
- scoreboard objectives add: Some commands erronously report failure when they've succeeded, and this is one of them. If you give the command a Display Name that's longer than 32 characters, the game will give an error and act like the objective was not created. Nevertheless, the objective is created, and its Display Name is its internal name instead. This certainly goes beyond just command block comparator output; it's unintuitive when typing the command in chat as well.
- scoreboard teams add: See above; this command is plagued by exactly the same behavior.
- scoreboard teams leave: This command won't settle for anything less than 100%. If at least one player it attempts to remove is not on a team, it will output 0, as though it completely failed, rather than outputting the number of players which it did successfully remove. Even if it doesn't fail to remove anybody, the highest it will output is 1 success regardless of the actual number of players removed.
This second list contains cases where it's debatable whether or not there is any bug (essentially, the ones where my idea of "correct behavior" may just be some else's idea of "feature request"). I'm fine with moving this second list down to the comments if this becomes an issue to anybody - I just figured this was the best place to list them if they indeed are also part of this bug. I suppose moderators (and myself) can also move items between these two lists.
- help: Counter-intuitively fails if commandname is a valid command. Also fails if commandname is not valid, but that would be proper behavior. The only reason I am including this command in the second list is because its use with comparators would be limited: at most, you could determine which commands are available if this is fixed. If we ignore mods, plugins, and other non-vanilla content, this is only helpful in determining what game version a map is running on (e.g. to tell the player they need to upgrade to a version with the desired command), or whether or not the map is running on a server (and server-specific commands themselves offer an alternate way to do this anyhow).
- give: Far from the biggest issue, but it seems that the command won't give an error when invalid damage values are used, even if the resulting items ignore these damage values. For example, it won't complain about negative armor damage; it merely spawns the item with zero damage instead.
- deop: I always found it funny that deop works on non-ops. This barely applies to this bug, as command blocks can't use the command anyhow, which is why I put it in the second list.
- pardon: See above, it works on non-banned players.
- pardon-ip: See above, it works on non-banned IPs.
- whitelist remove: See above, players don't have to be on the whitelist to be removed.
- save-off and save-on: Again, not a big deal, but I find it strange that you can disable world saving when it's already disabled, and enable it when it's already enabled. OPs could tell if this setting has been changed, if the command would give an error when using it has no effect. Once again, I realize this command can't be used in command blocks, hence its inclusion in the second list.
- whitelist on/off: See above; the command succeeds even when it has no effect because the whitelist is already on/off.
- scoreboard objectives setdisplay: I find it odd that there's no complaint when clearing an empty display slot, or setting it to an objective that's already displayed in that slot, as neither of these have an effect.
- scoreboard players reset: This one has a little more merit: it succeeds even in the player has no tracked scores. If that weren't the case, you could tell who hasn't been tracked by the scoreboard system at all.
- scoreboard teams join: I won't complain about the fact that you can add players who aren't online (and may not exist), as that's actually useful. However, I find it strange that you can add a player to a team even if they're already on it.
*TL;DR* If you were looking for a TL;DR, it's the 4th paragraph from the top
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.
I have created two lists of commands which are effected by (or cause, depending on your interpretation) this bug. This first list contains the "true bug" commands, where the behavior is clearly incorrect and should likely be fixed.
- effect: This command reports success even if an effect was not successfully given. If a player has an effect at a higher level or duration than the command attempts to apply, the effect will not be applied (as is expected by standard status effect behavior), and yet the command will report its success (which is not expected; after all, it reports an error when it fails to remove an effect).
- enchant: This command will report its failure only if it cannot find a player, the enchantment ID is nonexistent, or the enchantment level is invalid for this enchantment and the enchantment is valid for this item and this item does not have conflicting enchantments. It's unusual, but this command will report success when attempting to enchant an item which does not support the given enchantment - even if the given enchantment also does not support the specified level! This behavior is rather counter-intuitive: if you specify an enchantment with an invalid level, it returns a failure if the player is holding an item which otherwise can accept this enchantment, and it returns a success if the player is holding an item which cannot accept it. Also, in case you missed it in my first sentence, yes, the command will also "succeed" if there is a conflicting enchantment and thus the enchantment could not be applied. This is likely the most "backwards" command in this entire report.
- gamerule: The little engine that couldn't fail. You can pass this command nonexistent gamerules. You can pass it values other than true and false. Regardless of your parameters, it always succeeds. It will actually even store these invalid values in the level.dat if your gamerule is valid - the resulting behavior, however, isn't defined. Needless to say, it also succeeds if you set a gamerule to its current value, despite the fact that this results in no change - shame, as it means you can't test for the value of a gamerule, but that's probably the least of this command's problems.
- weather: I'm sure many a player is disappointed to see that, although "/weather snow", "/weather tornado 10000", etc. succeed, nothing actually happens. That's right; this command actually doesn't give the user any message whatsoever when a nonexistent weather condition is used - and thus, it is considered successful. Amusingly enough, it also accepts extra parameters after after the time is specified, so commands of the form "/weather clear 1000000 dammit, I hate rain" actually execute and report success.
- scoreboard objectives add: Some commands erronously report failure when they've succeeded, and this is one of them. If you give the command a Display Name that's longer than 32 characters, the game will give an error and act like the objective was not created. Nevertheless, the objective is created, and its Display Name is set to its internal name instead. This certainly goes beyond just command block comparator output; it's unintuitive when typing the command in chat as well.
- scoreboard teams add: See above; this command is plagued by exactly the same behavior.
- scoreboard teams leave: This command won't settle for anything less than 100%. If at least one player it attempts to remove is not on a team, it will output 0, as though it completely failed, rather than outputting the number of players which it did successfully remove. Even if it doesn't fail to remove anybody, the highest it will output is 1 success regardless of the actual number of players removed.
This second list contains cases where it's debatable whether or not there is any bug (essentially, the ones where my idea of "correct behavior" may just be some else's idea of "feature request"). I'm fine with moving this second list down to the comments if this becomes an issue to anybody - I just figured this was the best place to list them if they indeed are also part of this bug. I suppose moderators (and myself) can also move items between these two lists.
- help: Counter-intuitively fails if commandname is a valid command. Also fails if commandname is not valid, but that would be proper behavior. The only reason I am including this command in the second list is because its use with comparators would be limited: at most, you could determine which commands are available if this is fixed. If we ignore mods, plugins, and other non-vanilla content, this is only helpful in determining what game version a map is running on (e.g. to tell the player they need to upgrade to a version with the desired command), or whether or not the map is running on a server (and server-specific commands themselves offer an alternate way to do this anyhow).
- give: Far from the biggest issue, but it seems that the command won't give an error when invalid damage values are used, even if the resulting items ignore these damage values. For example, it won't complain about negative armor damage; it merely spawns the item with zero damage instead.
- deop: I always found it funny that deop works on non-ops. This barely applies to this bug, as command blocks can't use the command anyhow, which is why I put it in the second list.
- pardon: See above, it works on non-banned players.
- pardon-ip: See above, it works on non-banned IPs.
- whitelist remove: See above, players don't have to be on the whitelist to be removed.
- save-off and save-on: Again, not a big deal, but I find it strange that you can disable world saving when it's already disabled, and enable it when it's already enabled. OPs could tell if this setting has been changed, if the command would give an error when using it has no effect. Once again, I realize this command can't be used in command blocks, hence its inclusion in the second list.
- whitelist on/off: See above; the command succeeds even when it has no effect because the whitelist is already on/off.
- scoreboard objectives setdisplay: I find it odd that there's no complaint when clearing an empty display slot, or setting it to an objective that's already displayed in that slot, as neither of these have an effect.
- scoreboard players reset: This one has a little more merit: it succeeds even in the player has no tracked scores. If that weren't the case, you could tell who hasn't been tracked by the scoreboard system at all.
- scoreboard teams join: I won't complain about the fact that you can add players who aren't online (and may not exist), as that's actually useful. However, I find it strange that you can add a player to a team even if they're already on it.
*TL;DR* If you were looking for a TL;DR, it's the 4th paragraph from the top
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.
I have created two lists of commands which are effected by (or cause, depending on your interpretation) this bug. This first list contains the "true bug" commands, where the behavior is clearly incorrect and should likely be fixed.
- effect: This command reports success even if an effect was not successfully given. If a player has an effect at a higher level or duration than the command attempts to apply, the effect will not be applied (as is expected by standard status effect behavior), and yet the command will report its success (which is not expected; after all, it reports an error when it fails to remove an effect).
- enchant: This command will report its failure only if it cannot find a player, the enchantment ID is nonexistent, or the enchantment level is invalid for this enchantment and the enchantment is valid for this item and this item does not have conflicting enchantments. It's unusual, but this command will report success when attempting to enchant an item which does not support the given enchantment - even if the given enchantment also does not support the specified level! This behavior is rather counter-intuitive: if you specify an enchantment with an invalid level, it returns a failure if the player is holding an item which otherwise can accept this enchantment, and it returns a success if the player is holding an item which cannot accept it. Also, in case you missed it in my first sentence, yes, the command will also "succeed" if there is a conflicting enchantment and thus the enchantment could not be applied. This is likely the most "backwards" command in this entire report.
- gamerule: The little engine that couldn't fail. You can pass this command nonexistent gamerules. You can pass it values other than true and false. Regardless of your parameters, it always succeeds. It will actually even store these invalid values in the level.dat if your gamerule is valid - the resulting behavior, however, isn't defined. Needless to say, it also succeeds if you set a gamerule to its current value, despite the fact that this results in no change - shame, as it means you can't test for the value of a gamerule, but that's probably the least of this command's problems.
- weather: I'm sure many a player is disappointed to see that, although "/weather snow", "/weather tornado 10000", etc. succeed, nothing actually happens. That's right; this command actually doesn't give the user any message whatsoever when a nonexistent weather condition is used - and thus, it is considered successful. Amusingly enough, it also accepts extra parameters after after the time is specified, so commands of the form "/weather clear 1000000 dammit, I hate rain" actually execute and report success.
- scoreboard objectives add: Some commands erronously report failure when they've succeeded, and this is one of them. If you give the command a Display Name that's longer than 32 characters, the game will give an error and act like the objective was not created. Nevertheless, the objective is created, and its Display Name is set to its internal name instead. This certainly goes beyond just command block comparator output; it's unintuitive when typing the command in chat as well.
- scoreboard teams add: See above; this command is plagued by exactly the same behavior.
- scoreboard teams leave: This command won't settle for anything less than 100%. If at least one player it attempts to remove is not on a team, it will output 0, as though it completely failed, rather than outputting the number of players which it did successfully remove. Even if it doesn't fail to remove anybody, the highest it will output is 1 success regardless of the actual number of players removed.
This second list contains cases where it's debatable whether or not there is any bug (essentially, the ones where my idea of "correct behavior" may just be some else's idea of "feature request"). I'm fine with moving this second list down to the comments if this becomes an issue to anybody - I just figured this was the best place to list them if they indeed are also part of this bug. I suppose moderators (and myself) can also move items between these two lists.
- help: Counter-intuitively fails if commandname is a valid command. Also fails if commandname is not valid, but that would be proper behavior. The only reason I am including this command in the second list is because its use with comparators would be limited: at most, you could determine which commands are available if this is fixed. If we ignore mods, plugins, and other non-vanilla content, this is only helpful in determining what game version a map is running on (e.g. to tell the player they need to upgrade to a version with the desired command), or whether or not the map is running on a server (and server-specific command
s themselvesoffer an alternate way to do this anyhow).
- give: Far from the biggest issue, but it seems that the command won't give an error when invalid damage values are used, even if the resulting items ignore these damage values. For example, it won't complain about negative armor damage; it merely spawns the item with zero damage instead.
- deop: I always found it funny that deop works on non-ops. This barely applies to this bug, as command blocks can't use the command anyhow, which is why I put it in the second list.
- pardon: See above, it works on non-banned players.
- pardon-ip: See above, it works on non-banned IPs.
- whitelist remove: See above, players don't have to be on the whitelist to be removed.
- save-off and save-on: Again, not a big deal, but I find it strange that you can disable world saving when it's already disabled, and enable it when it's already enabled. OPs could tell if this setting has been changed, if the command would give an error when using it has no effect. Once again, I realize this command can't be used in command blocks, hence its inclusion in the second list.
- whitelist on/off: See above; the command succeeds even when it has no effect because the whitelist is already on/off.
- scoreboard objectives setdisplay: I find it odd that there's no complaint when clearing an empty display slot, or setting it to an objective that's already displayed in that slot, as neither of these have an effect.
- scoreboard players reset: This one has a little more merit: it succeeds even i
nthe player has no tracked scores. If that weren't the case, you could tell who hasn't been tracked by the scoreboard system at all.
- scoreboard teams join: I won't complain about the fact that you can add players who aren't online (and may not exist), as that's actually useful. However, I find it strange that you can add a player to a team even if they're already on it.
*TL;DR* If you were looking for a TL;DR, it's the 4th paragraph from the top
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.
I have created two lists of commands which are effected by (or cause, depending on your interpretation) this bug. This first list contains the "true bug" commands, where the behavior is clearly incorrect and should likely be fixed.
- effect: This command reports success even if an effect was not successfully given. If a player has an effect at a higher level or duration than the command attempts to apply, the effect will not be applied (as is expected by standard status effect behavior), and yet the command will report its success (which is not expected; after all, it reports an error when it fails to remove an effect).
- enchant: This command will report its failure only if it cannot find a player, the enchantment ID is nonexistent, or the enchantment level is invalid for this enchantment and the enchantment is valid for this item and this item does not have conflicting enchantments. It's unusual, but this command will report success when attempting to enchant an item which does not support the given enchantment - even if the given enchantment also does not support the specified level! This behavior is rather counter-intuitive: if you specify an enchantment with an invalid level, it returns a failure if the player is holding an item which otherwise can accept this enchantment, and it returns a success if the player is holding an item which cannot accept it. Also, in case you missed it in my first sentence, yes, the command will also "succeed" if there is a conflicting enchantment and thus the enchantment could not be applied. This is likely the most "backwards" command in this entire report.
- gamerule: The little engine that couldn't fail. You can pass this command nonexistent gamerules. You can pass it values other than true and false. Regardless of your parameters, it always succeeds. It will actually even store these invalid values in the level.dat if your gamerule is valid - the resulting behavior, however, isn't defined. Needless to say, it also succeeds if you set a gamerule to its current value, despite the fact that this results in no change - shame, as it means you can't test for the value of a gamerule, but that's probably the least of this command's problems.
- weather: I'm sure many a player is disappointed to see that, although "/weather snow", "/weather tornado 10000", etc. succeed, nothing actually happens. That's right; this command actually doesn't give the user any message whatsoever when a nonexistent weather condition is used - and thus, it is considered successful. Amusingly enough, it also accepts extra parameters after after the time is specified, so commands of the form "/weather clear 1000000 dammit, I hate rain" actually execute and report success.
- scoreboard objectives add: Some commands erronously report failure when they've succeeded, and this is one of them. If you give the command a Display Name that's longer than 32 characters, the game will give an error and act like the objective was not created. Nevertheless, the objective is created, and its Display Name is set to its internal name instead. This certainly goes beyond just command block comparator output; it's unintuitive when typing the command in chat as well.
- scoreboard teams add: See above; this command is plagued by exactly the same behavior.
- scoreboard teams leave: This command won't settle for anything less than 100%. If at least one player it attempts to remove is not on a team, it will output 0, as though it completely failed, rather than outputting the number of players which it did successfully remove. Even if it doesn't fail to remove anybody, the highest it will output is 1 success regardless of the actual number of players removed.
This second list contains cases where it's debatable whether or not there is any bug (essentially, the ones where my idea of "correct behavior" may just be someone else's idea of "feature request" or "nitpicking"). I'm fine with moving this second list down to the comments if this becomes an issue to anybody - I just figured this was the best place to list them if they indeed are also part of this bug. I suppose moderators (and myself) can also move items between these two lists.
- help: Counter-intuitively fails if commandname is a valid command. Also fails if commandname is not valid, but that would be proper behavior. The only reason I am including this command in the second list is because its use with comparators would be limited: at most, you could determine which commands are available if this is fixed. If we ignore mods, plugins, and other non-vanilla content, this is only helpful in determining what game version a map is running on (e.g. to tell the player they need to upgrade to a version with the desired command), or whether or not the map is running on a server (and the server-specific /list command itself offers an alternate way to do this anyhow).
- give: Far from the biggest issue, but it seems that the command won't give an error when invalid damage values are used, even if the resulting items ignore these damage values. For example, it won't complain about negative armor damage; it merely spawns the item with zero damage instead.
- deop: I always found it funny that deop works on non-ops. This barely applies to this bug, as command blocks can't use the command anyhow, which is why I put it in the second list.
- pardon: See above, it works on non-banned players.
- pardon-ip: See above, it works on non-banned IPs.
- whitelist remove: See above, players don't have to be on the whitelist to be removed.
- save-off and save-on: Again, not a big deal, but I find it strange that you can disable world saving when it's already disabled, and enable it when it's already enabled. OPs could tell if this setting has been changed, if the command would give an error when using it has no effect. Once again, I realize this command can't be used in command blocks, hence its inclusion in the second list.
- whitelist on/off: See above; the command succeeds even when it has no effect because the whitelist is already on/off.
- scoreboard objectives setdisplay: I find it odd that there's no complaint when clearing an empty display slot, or setting it to an objective that's already displayed in that slot, as neither of these have an effect.
- scoreboard players reset: This one has a little more merit: it succeeds even if the player has no tracked scores. If that weren't the case, you could tell who hasn't been tracked by the scoreboard system at all.
- scoreboard teams join: I won't complain about the fact that you can add players who aren't online (and may not exist), as that's actually useful. However, I find it strange that you can add a player to a team even if they're already on it.
*TL;DR* If you were looking for a TL;DR, it's the 4th paragraph from the top
is duplicated by
is duplicated by
is duplicated by
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.
I have created two lists of commands which are effected by (or cause, depending on your interpretation) this bug. This first list contains the "true bug" commands, where the behavior is clearly incorrect and should likely be fixed.
- effect: This command reports success even if an effect was not successfully given. If a player has an effect at a higher level or duration than the command attempts to apply, the effect will not be applied (as is expected by standard status effect behavior), and yet the command will report its success (which is not expected; after all, it reports an error when it fails to remove an effect).
- enchant: This command will report its failure only if it cannot find a player, the enchantment ID is nonexistent, or the enchantment level is invalid for this enchantment and the enchantment is valid for this item and this item does not have conflicting enchantments. It's unusual, but this command will report success when attempting to enchant an item which does not support the given enchantment - even if the given enchantment also does not support the specified level! This behavior is rather counter-intuitive: if you specify an enchantment with an invalid level, it returns a failure if the player is holding an item which otherwise can accept this enchantment, and it returns a success if the player is holding an item which cannot accept it. Also, in case you missed it in my first sentence, yes, the command will also "succeed" if there is a conflicting enchantment and thus the enchantment could not be applied. This is likely the most "backwards" command in this entire report.
- gamerule: The little engine that couldn't fail. You can pass this command nonexistent gamerules. You can pass it values other than true and false. Regardless of your parameters, it always succeeds. It will actually even store these invalid values in the level.dat if your gamerule is valid - the resulting behavior, however, isn't defined. Needless to say, it also succeeds if you set a gamerule to its current value, despite the fact that this results in no change - shame, as it means you can't test for the value of a gamerule, but that's probably the least of this command's problems.
- weather: I'm sure many a player is disappointed to see that, although "/weather snow", "/weather tornado 10000", etc. succeed, nothing actually happens. That's right; this command actually doesn't give the user any message whatsoever when a nonexistent weather condition is used - and thus, it is considered successful. Amusingly enough, it also accepts extra parameters after after the time is specified, so commands of the form "/weather clear 1000000 dammit, I hate rain" actually execute and report success.
- scoreboard objectives add: Some commands erronously report failure when they've succeeded, and this is one of them. If you give the command a Display Name that's longer than 32 characters, the game will give an error and act like the objective was not created. Nevertheless, the objective is created, and its Display Name is set to its internal name instead. This certainly goes beyond just command block comparator output; it's unintuitive when typing the command in chat as well.
- scoreboard teams add: See above; this command is plagued by exactly the same behavior.
- scoreboard teams leave: This command won't settle for anything less than 100%. If at least one player it attempts to remove is not on a team, it will output 0, as though it completely failed, rather than outputting the number of players which it did successfully remove. Even if it doesn't fail to remove anybody, the highest it will output is 1 success regardless of the actual number of players removed.
This second list contains cases where it's debatable whether or not there is any bug (essentially, the ones where my idea of "correct behavior" may just be someone else's idea of "feature request" or "nitpicking"). I'm fine with moving this second list down to the comments if this becomes an issue to anybody - I just figured this was the best place to list them if they indeed are also part of this bug. I suppose moderators (and myself) can also move items between these two lists.
- help: Counter-intuitively fails if commandname is a valid command. Also fails if commandname is not valid, but that would be proper behavior. The only reason I am including this command in the second list is because its use with comparators would be limited: at most, you could determine which commands are available if this is fixed. If we ignore mods, plugins, and other non-vanilla content, this is only helpful in determining what game version a map is running on (e.g. to tell the player they need to upgrade to a version with the desired command), or whether or not the map is running on a server (and the server-specific /list command itself offers an alternate way to do this anyhow).
- give: Far from the biggest issue, but it seems that the command won't give an error when invalid damage values are used, even if the resulting items ignore these damage values. For example, it won't complain about negative armor damage; it merely spawns the item with zero damage instead.
- deop: I always found it funny that deop works on non-ops. This barely applies to this bug, as command blocks can't use the command anyhow, which is why I put it in the second list.
- pardon: See above, it works on non-banned players.
- pardon-ip: See above, it works on non-banned IPs.
- whitelist remove: See above, players don't have to be on the whitelist to be removed.
- save-off and save-on: Again, not a big deal, but I find it strange that you can disable world saving when it's already disabled, and enable it when it's already enabled. OPs could tell if this setting has been changed, if the command would give an error when using it has no effect. Once again, I realize this command can't be used in command blocks, hence its inclusion in the second list.
- whitelist on/off: See above; the command succeeds even when it has no effect because the whitelist is already on/off.
- scoreboard objectives setdisplay: I find it odd that there's no complaint when clearing an empty display slot, or setting it to an objective that's already displayed in that slot, as neither of these have an effect.
- scoreboard players reset: This one has a little more merit: it succeeds even if the player has no tracked scores. If that weren't the case, you could tell who hasn't been tracked by the scoreboard system at all.
- scoreboard teams join: I won't complain about the fact that you can add players who aren't online (and may not exist), as that's actually useful. However, I find it strange that you can add a player to a team even if they're already on it.
*TL;DR* If you were looking for a TL;DR, it's the 4th paragraph from the top
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.
I have created two lists of commands which are effected by (or cause, depending on your interpretation) this bug. This first list contains the "true bug" commands, where the behavior is clearly incorrect and should likely be fixed.
- effect: This command reports success even if an effect was not successfully given. If a player has an effect at a higher level or duration than the command attempts to apply, the effect will not be applied (as is expected by standard status effect behavior), and yet the command will report its success (which is not expected; after all, it reports an error when it fails to remove an effect).
- enchant: This command will report its failure only if it cannot find a player, the enchantment ID is nonexistent, or the enchantment level is invalid for this enchantment and the enchantment is valid for this item and this item does not have conflicting enchantments. It's unusual, but this command will report success when attempting to enchant an item which does not support the given enchantment - even if the given enchantment also does not support the specified level! This behavior is rather counter-intuitive: if you specify an enchantment with an invalid level, it returns a failure if the player is holding an item which otherwise can accept this enchantment, and it returns a success if the player is holding an item which cannot accept it. Also, in case you missed it in my first sentence, yes, the command will also "succeed" if there is a conflicting enchantment and thus the enchantment could not be applied. This is likely the most "backwards" command in this entire report.
- gamerule: The little engine that couldn't fail. You can pass this command nonexistent gamerules. You can pass it values other than true and false. Regardless of your parameters, it always succeeds. It will actually even store these invalid values in the level.dat if your gamerule is valid - the resulting behavior, however, isn't defined. Needless to say, it also succeeds if you set a gamerule to its current value, despite the fact that this results in no change - shame, as it means you can't test for the value of a gamerule, but that's probably the least of this command's problems.
- weather: I'm sure many a player is disappointed to see that, although "/weather snow", "/weather tornado 10000", etc. succeed, nothing actually happens. That's right; this command actually doesn't give the user any message whatsoever when a nonexistent weather condition is used - and thus, it is considered successful. Amusingly enough, it also accepts extra parameters after after the time is specified, so commands of the form "/weather clear 1000000 dammit, I hate rain" actually execute and report success.
- scoreboard objectives add: Some commands erronously report failure when they've succeeded, and this is one of them. If you give the command a Display Name that's longer than 32 characters, the game will give an error and act like the objective was not created. Nevertheless, the objective is created, and its Display Name is set to its internal name instead. This certainly goes beyond just command block comparator output; it's unintuitive when typing the command in chat as well.
- scoreboard teams add: See above; this command is plagued by exactly the same behavior.
- scoreboard teams leave: This command won't settle for anything less than 100%. If at least one player it attempts to remove is not on a team, it will output 0, as though it completely failed, rather than outputting the number of players which it did successfully remove. Even if it doesn't fail to remove anybody, the highest it will output is 1 success regardless of the actual number of players removed.
This second list contains cases where it's debatable whether or not there is any bug (essentially, the ones where my idea of "correct behavior" may just be someone else's idea of "feature request" or "nitpicking"). I'm fine with moving this second list down to the comments if this becomes an issue to anybody - I just figured this was the best place to list them if they indeed are also part of this bug. I suppose moderators (and myself) can also move items between these two lists.
- help: Counter-intuitively fails if commandname is a valid command. Also fails if commandname is not valid, but that would be proper behavior. The only reason I am including this command in the second list is because its use with comparators would be limited: at most, you could determine which commands are available if this is fixed. If we ignore mods, plugins, and other non-vanilla content, this is only helpful in determining what game version a map is running on (e.g. to tell the player they need to upgrade to a version with the desired command), or whether or not the map is running on a server (and the server-specific /list command itself offers an alternate way to do this anyhow).
- give: Far from the biggest issue, but it seems that the command won't give an error when invalid damage values are used, even if the resulting items ignore these damage values. For example, it won't complain about negative armor damage; it merely spawns the item with zero damage instead.
- deop: I always found it funny that deop works on non-ops. This barely applies to this bug, as command blocks can't use the command anyhow, which is why I put it in the second list.
- pardon: See above, it works on non-banned players.
- pardon-ip: See above, it works on non-banned IPs.
- whitelist remove: See above, players don't have to be on the whitelist to be removed.
- save-off and save-on: Again, not a big deal, but I find it strange that you can disable world saving when it's already disabled, and enable it when it's already enabled. OPs could tell if this setting has been changed, if the command would give an error when using it has no effect. Once again, I realize this command can't be used in command blocks, hence its inclusion in the second list.
- whitelist on/off: See above; the command succeeds even when it has no effect because the whitelist is already on/off.
- scoreboard objectives setdisplay: I find it odd that there's no complaint when clearing an empty display slot, or setting it to an objective that's already displayed in that slot, as neither of these have an effect.
- scoreboard players reset: This one has a little more merit: it succeeds even if the player has no tracked scores. If that weren't the case, you could tell who hasn't been tracked by the scoreboard system at all.
- scoreboard teams join: I won't complain about the fact that you can add players who aren't online (and may not exist), as that's actually useful. However, I find it strange that you can add a player to a team even if they're already on it.
*TL;DR* If you were looking for a TL;DR, it's the 4th paragraph from the top
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
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.
I have created two lists of commands which are effected by (or cause, depending on your interpretation) this bug. This first list contains the "true bug" commands, where the behavior is clearly incorrect and should likely be fixed.
- effect: This command reports success even if an effect was not successfully given. If a player has an effect at a higher level or duration than the command attempts to apply, the effect will not be applied (as is expected by standard status effect behavior), and yet the command will report its success (which is not expected; after all, it reports an error when it fails to remove an effect).
- enchant: This command will report its failure only if it cannot find a player, the enchantment ID is nonexistent, or the enchantment level is invalid for this enchantment and the enchantment is valid for this item and this item does not have conflicting enchantments. It's unusual, but this command will report success when attempting to enchant an item which does not support the given enchantment - even if the given enchantment also does not support the specified level! This behavior is rather counter-intuitive: if you specify an enchantment with an invalid level, it returns a failure if the player is holding an item which otherwise can accept this enchantment, and it returns a success if the player is holding an item which cannot accept it. Also, in case you missed it in my first sentence, yes, the command will also "succeed" if there is a conflicting enchantment and thus the enchantment could not be applied. This is likely the most "backwards" command in this entire report.
- gamerule: The little engine that couldn't fail. You can pass this command nonexistent gamerules. You can pass it values other than true and false. Regardless of your parameters, it always succeeds. It will actually even store these invalid values in the level.dat if your gamerule is valid - the resulting behavior, however, isn't defined. Needless to say, it also succeeds if you set a gamerule to its current value, despite the fact that this results in no change - shame, as it means you can't test for the value of a gamerule, but that's probably the least of this command's problems.
- weather: I'm sure many a player is disappointed to see that, although "/weather snow", "/weather tornado 10000", etc. succeed, nothing actually happens. That's right; this command actually doesn't give the user any message whatsoever when a nonexistent weather condition is used - and thus, it is considered successful. Amusingly enough, it also accepts extra parameters after after the time is specified, so commands of the form "/weather clear 1000000 dammit, I hate rain" actually execute and report success.
- scoreboard objectives add: Some commands erronously report failure when they've succeeded, and this is one of them. If you give the command a Display Name that's longer than 32 characters, the game will give an error and act like the objective was not created. Nevertheless, the objective is created, and its Display Name is set to its internal name instead. This certainly goes beyond just command block comparator output; it's unintuitive when typing the command in chat as well.
- scoreboard teams add: See above; this command is plagued by exactly the same behavior.
- scoreboard teams leave: This command won't settle for anything less than 100%. If at least one player it attempts to remove is not on a team, it will output 0, as though it completely failed, rather than outputting the number of players which it did successfully remove. Even if it doesn't fail to remove anybody, the highest it will output is 1 success regardless of the actual number of players removed.
This second list contains cases where it's debatable whether or not there is any bug (essentially, the ones where my idea of "correct behavior" may just be someone else's idea of "feature request" or "nitpicking"). I'm fine with moving this second list down to the comments if this becomes an issue to anybody - I just figured this was the best place to list them if they indeed are also part of this bug. I suppose moderators (and myself) can also move items between these two lists.
- help: Counter-intuitively fails if commandname is a valid command. Also fails if commandname is not valid, but that would be proper behavior. The only reason I am including this command in the second list is because its use with comparators would be limited: at most, you could determine which commands are available if this is fixed. If we ignore mods, plugins, and other non-vanilla content, this is only helpful in determining what game version a map is running on (e.g. to tell the player they need to upgrade to a version with the desired command), or whether or not the map is running on a server (and the server-specific /list command itself offers an alternate way to do this anyhow).
- give: Far from the biggest issue, but it seems that the command won't give an error when invalid damage values are used, even if the resulting items ignore these damage values. For example, it won't complain about negative armor damage; it merely spawns the item with zero damage instead.
- deop: I always found it funny that deop works on non-ops. This barely applies to this bug, as command blocks can't use the command anyhow, which is why I put it in the second list.
- pardon: See above, it works on non-banned players.
- pardon-ip: See above, it works on non-banned IPs.
- whitelist remove: See above, players don't have to be on the whitelist to be removed.
- save-off and save-on: Again, not a big deal, but I find it strange that you can disable world saving when it's already disabled, and enable it when it's already enabled. OPs could tell if this setting has been changed, if the command would give an error when using it has no effect. Once again, I realize this command can't be used in command blocks, hence its inclusion in the second list.
- whitelist on/off: See above; the command succeeds even when it has no effect because the whitelist is already on/off.
- scoreboard objectives setdisplay: I find it odd that there's no complaint when clearing an empty display slot, or setting it to an objective that's already displayed in that slot, as neither of these have an effect.
- scoreboard players reset: This one has a little more merit: it succeeds even if the player has no tracked scores. If that weren't the case, you could tell who hasn't been tracked by the scoreboard system at all.
- scoreboard teams join: I won't complain about the fact that you can add players who aren't online (and may not exist), as that's actually useful. However, I find it strange that you can add a player to a team even if they're already on it.
*TL;DR* If you were looking for a TL;DR, it's the 4th paragraph from the top
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.
I have created two lists of commands which are effected by (or cause, depending on your interpretation) this bug. This first list contains the "true bug" commands, where the behavior is clearly incorrect and should likely be fixed.
- effect: This command reports success even if an effect was not successfully given. If a player has an effect at a higher level or duration than the command attempts to apply, the effect will not be applied (as is expected by standard status effect behavior), and yet the command will report its success (which is not expected; after all, it reports an error when it fails to remove an effect).
- gamerule: The little engine that couldn't fail. You can pass this command nonexistent gamerules. You can pass it values other than true and false. Regardless of your parameters, it always succeeds. It will actually even store these invalid values in the level.dat if your gamerule is valid - the resulting behavior, however, isn't defined. Needless to say, it also succeeds if you set a gamerule to its current value, despite the fact that this results in no change - shame, as it means you can't test for the value of a gamerule, but that's probably the least of this command's problems.
- scoreboard teams leave: This command won't settle for anything less than 100%. If at least one player it attempts to remove is not on a team, it will output 0, as though it completely failed, rather than outputting the number of players which it did successfully remove. Even if it doesn't fail to remove anybody, the highest it will output is 1 success regardless of the actual number of players removed.
This second list contains cases where it's debatable whether or not there is any bug (essentially, the ones where my idea of "correct behavior" may just be someone else's idea of "feature request" or "nitpicking"). I'm fine with moving this second list down to the comments if this becomes an issue to anybody - I just figured this was the best place to list them if they indeed are also part of this bug. I suppose moderators (and myself) can also move items between these two lists.
- help: Counter-intuitively fails if commandname is a valid command. Also fails if commandname is not valid, but that would be proper behavior. The only reason I am including this command in the second list is because its use with comparators would be limited: at most, you could determine which commands are available if this is fixed. If we ignore mods, plugins, and other non-vanilla content, this is only helpful in determining what game version a map is running on (e.g. to tell the player they need to upgrade to a version with the desired command), or whether or not the map is running on a server (and the server-specific /list command itself offers an alternate way to do this anyhow).
- give: Far from the biggest issue, but it seems that the command won't give an error when invalid damage values are used, even if the resulting items ignore these damage values. For example, it won't complain about negative armor damage; it merely spawns the item with zero damage instead.
- deop: I always found it funny that deop works on non-ops. This barely applies to this bug, as command blocks can't use the command anyhow, which is why I put it in the second list.
- pardon: See above, it works on non-banned players.
- pardon-ip: See above, it works on non-banned IPs.
- whitelist remove: See above, players don't have to be on the whitelist to be removed.
- save-off and save-on: Again, not a big deal, but I find it strange that you can disable world saving when it's already disabled, and enable it when it's already enabled. OPs could tell if this setting has been changed, if the command would give an error when using it has no effect. Once again, I realize this command can't be used in command blocks, hence its inclusion in the second list.
- whitelist on/off: See above; the command succeeds even when it has no effect because the whitelist is already on/off.
- scoreboard objectives setdisplay: I find it odd that there's no complaint when clearing an empty display slot, or setting it to an objective that's already displayed in that slot, as neither of these have an effect.
- scoreboard players reset: This one has a little more merit: it succeeds even if the player has no tracked scores. If that weren't the case, you could tell who hasn't been tracked by the scoreboard system at all.
- scoreboard teams join: I won't complain about the fact that you can add players who aren't online (and may not exist), as that's actually useful. However, I find it strange that you can add a player to a team even if they're already on it.
The following have already been fixed:
- enchant: This command will report its failure only if it cannot find a player, the enchantment ID is nonexistent, or the enchantment level is invalid for this enchantment and the enchantment is valid for this item and this item does not have conflicting enchantments. It's unusual, but this command will report success when attempting to enchant an item which does not support the given enchantment - even if the given enchantment also does not support the specified level! This behavior is rather counter-intuitive: if you specify an enchantment with an invalid level, it returns a failure if the player is holding an item which otherwise can accept this enchantment, and it returns a success if the player is holding an item which cannot accept it. Also, in case you missed it in my first sentence, yes, the command will also "succeed" if there is a conflicting enchantment and thus the enchantment could not be applied. This is likely the most "backwards" command in this entire report.
- weather: I'm sure many a player is disappointed to see that, although "/weather snow", "/weather tornado 10000", etc. succeed, nothing actually happens. That's right; this command actually doesn't give the user any message whatsoever when a nonexistent weather condition is used - and thus, it is considered successful. Amusingly enough, it also accepts extra parameters after after the time is specified, so commands of the form "/weather clear 1000000 dammit, I hate rain" actually execute and report success.
- scoreboard objectives add: Some commands erronously report failure when they've succeeded, and this is one of them. If you give the command a Display Name that's longer than 32 characters, the game will give an error and act like the objective was not created. Nevertheless, the objective is created, and its Display Name is set to its internal name instead. This certainly goes beyond just command block comparator output; it's unintuitive when typing the command in chat as well.
- scoreboard teams add: See above; this command is plagued by exactly the same behavior.
*TL;DR* If you were looking for a TL;DR, it's the 4th paragraph from the top
relates to
relates to
relates to
is duplicated by
![[Mod] Torabi](../../../data/assets/gravatar/torabi.png){kind=small}
is duplicated by
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.
I have created two lists of commands which are effected by (or cause, depending on your interpretation) this bug. This first list contains the "true bug" commands, where the behavior is clearly incorrect and should likely be fixed.
- effect: This command reports success even if an effect was not successfully given. If a player has an effect at a higher level or duration than the command attempts to apply, the effect will not be applied (as is expected by standard status effect behavior), and yet the command will report its success (which is not expected; after all, it reports an error when it fails to remove an effect).
- gamerule: The little engine that couldn't fail. You can pass this command nonexistent gamerules. You can pass it values other than true and false. Regardless of your parameters, it always succeeds. It will actually even store these invalid values in the level.dat if your gamerule is valid - the resulting behavior, however, isn't defined. Needless to say, it also succeeds if you set a gamerule to its current value, despite the fact that this results in no change - shame, as it means you can't test for the value of a gamerule, but that's probably the least of this command's problems.
- scoreboard teams leave: This command won't settle for anything less than 100%. If at least one player it attempts to remove is not on a team, it will output 0, as though it completely failed, rather than outputting the number of players which it did successfully remove. Even if it doesn't fail to remove anybody, the highest it will output is 1 success regardless of the actual number of players removed.
This second list contains cases where it's debatable whether or not there is any bug (essentially, the ones where my idea of "correct behavior" may just be someone else's idea of "feature request" or "nitpicking"). I'm fine with moving this second list down to the comments if this becomes an issue to anybody - I just figured this was the best place to list them if they indeed are
also part of this bug. I suppose moderators (and myself) can also move items between these two lists.
- help: Counter-intuitively fails if commandname is a valid command. Also fails if commandname is not valid, but that would be proper behavior. The only reason I am including this command in the second list is because its use with comparators would be limited: at most, you could determine which commands are available if this is fixed. If we ignore mods, plugins, and other non-vanilla content, this is only helpful in determining what game version a map is running on (e.g. to tell the player they need to upgrade to a version with the desired command), or whether or not the map is running on a server (and the server-specific /list command itself offers an alternate way to do this anyhow).
- give: Far from the biggest issue, but it seems that the command won't give an error when invalid damage values are used, even if the resulting items ignore these damage values. For example, it won't complain about negative armor damage; it merely spawns the item with zero damage instead.
- deop: I always found it funny that deop works on non-ops. This barely applies to this bug, as command blocks can't use the command anyhow, which is why I put it in the second list.
- pardon: See above, it works on non-banned players.
- pardon-ip: See above, it works on non-banned IPs.
- whitelist remove: See above, players don't have to be on the whitelist to be removed.
- save-off and save-on: Again, not a big deal, but I find it strange that you can disable world saving when it's already disabled, and enable it when it's already enabled. OPs could tell if this setting has been changed, if the command would give an error when using it has no effect. Once again, I realize this command can't be used in command blocks, hence its inclusion in the second list.
- whitelist on/off: See above; the command succeeds even when it has no effect because the whitelist is already on/off.
- scoreboard objectives setdisplay: I find it odd that there's no complaint when clearing an empty display slot, or setting it to an objective that's already displayed in that slot, as neither of these have an effect.
- scoreboard players reset: This one has a little more merit: it succeeds even if the player has no tracked scores. If that weren't the case, you could tell who hasn't been tracked by the scoreboard system at all.
- scoreboard teams join: I won't complain about the fact that you can add players who aren't online (and may not exist), as that's actually useful. However, I find it strange that you can add a player to a team even if they're already on it.
The following have already been fixed:
- enchant: This command will report its failure only if it cannot find a player, the enchantment ID is nonexistent, or the enchantment level is invalid for this enchantment and the enchantment is valid for this item and this item does not have conflicting enchantments. It's unusual, but this command will report success when attempting to enchant an item which does not support the given enchantment - even if the given enchantment also does not support the specified level! This behavior is rather counter-intuitive: if you specify an enchantment with an invalid level, it returns a failure if the player is holding an item which otherwise can accept this enchantment, and it returns a success if the player is holding an item which cannot accept it. Also, in case you missed it in my first sentence, yes, the command will also "succeed" if there is a conflicting enchantment and thus the enchantment could not be applied. This is likely the most "backwards" command in this entire report.
- weather: I'm sure many a player is disappointed to see that, although "/weather snow", "/weather tornado 10000", etc. succeed, nothing actually happens. That's right; this command actually doesn't give the user any message whatsoever when a nonexistent weather condition is used - and thus, it is considered successful. Amusingly enough, it also accepts extra parameters after after the time is specified, so commands of the form "/weather clear 1000000 dammit, I hate rain" actually execute and report success.
- scoreboard objectives add: Some commands erronously report failure when they've succeeded, and this is one of them. If you give the command a Display Name that's longer than 32 characters, the game will give an error and act like the objective was not created. Nevertheless, the objective is created, and its Display Name is set to its internal name instead. This certainly goes beyond just command block comparator output; it's unintuitive when typing the command in chat as well.
- scoreboard teams add: See above; this command is plagued by exactly the same behavior.
*TL;DR* If you were looking for a TL;DR, it's the 4th paragraph from the top
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
/effect
- Using lower amplifier
- Using same amplifier but lower time
/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 correctThe fact that it saves non existing gamerules is either intended or a different bug
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
/effect
- Using lower amplifier
- Using same amplifier but lower time
/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 correctThe fact that it saves non existing gamerules is either intended or a different bug
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
/effect
- Using lower amplifier
- Using same amplifier but lower time
/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(); } //... } }/ban (and probably /ban-ip)
Let you ban players multiple times, however only one ban list entry is created
/pardon-ip
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
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 correctThe fact that it saves non existing gamerules is either intended or a different bug
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
/effect
- Using lower amplifier
- Using same amplifier but lower time
/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(); } //... } }/ban (and probably /ban-ip)
Let you ban players multiple times, however only one ban list entry is created
/pardon-ip
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-87430Unaffected 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 correctThe fact that it saves non existing gamerules is either intended or a different bug
![[Bot] Arisa](../../../data/assets/gravatar/mustek2.png){kind=small}
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
This ticket has been marked as a duplicate of MC-15567, in favor of the better description/information provided.
When changing a player's team, a command block will return true when it shouldn't.
Steps to reproduce:
1. Create teams "testTeam1" and "testTeam2"
2. Place a command block with a comparator
3. Insert the command scoreboard teams join testTeam1 @p[team=testTeam2]
4. Activate the command block.
What I expected to happen:
The command block would return true IF AND ONLY IF
1) the team exists
2) the player could be found and
3) was added to it.
What happened:
The comparator turned on, even if the player isn't on the correct team (or any team). Note that although the comparator turns on, there is no text in the bottom box explaining that a player has been added to that team, because the command block didn't run the command successfully, so the comparator shouldn't turn on.
----------------------
This might be part of a larger set of improperly returning comparator values. I noticed this issue began in the last few snapshots where I had not had the problem in early 1.8 snapshots. Please see MC-15567 for some other examples. I wanted to post this since that bug hasn't been updated in a while and the team joining issue only became a problem for me a few weeks ago.
I think
MC-13236should 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!
Perhaps somebody should make a suggestion for a command similar to testfor (i.e. scoreboard-only). It would output success only if the target player is holding the desired item, with optional parameters for damage value and amount. In fact, there could even be a "minimum" parameter to check if the player is holding at least the specified amount of the item, and the clear command could likewise be given an amount parameter to only remove the specified amount of items. This would allow for command-based shops, among many other things (including the tricks you could do with the enchanting bug), and wouldn't rely on a bug which breaks command-based enchanting systems.
Maybe you could have "testfor @a[i=98,d=3]" to test for all the people with chiseled stone bricks. i = item and d = data value.
Edit: maybe even have a=7 and am=3 for max and minimum quantities.
The freaking enchant bug! They need to fix it because it ruins everything! I agree with you, davidj919. I made a mana system with it but now it won't work!
I can confirm the /effect and /gamerule commands are still affected in 1.7.4, but don't have the resources to test the /scoreboard one.
Confirmed for "/gamerule" in 14w21b
*Added screenshot
Is this still a concern in the current Minecraft version 1.8.1 Prerelease 3 / Launcher version 1.5.3 or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
No response for over a year.
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
Affected commands
/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.
/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
/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 correctThe fact that it saves non existing gamerules is either intended or a different bug
Changed reporter to Marcono1234.
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.