-
Bug
-
Resolution: Fixed
-
Minecraft 1.8.6, Minecraft 15w35b, Minecraft 1.9, Minecraft 1.9.1 Pre-Release 3, Minecraft 1.9.4, Minecraft 16w21a, Minecraft 1.11.2, Minecraft 17w14a, Minecraft 17w15a, Minecraft 17w17a, Minecraft 17w17b, Minecraft 1.12 Pre-Release 2
-
Confirmed
I don't know if this is a valid report, but I hope so. Else I am pretty much fine with it, if you say it "Invalid" as long as your explanation would be this is a suggestion.
Notes:
- This does not include the required changes from
MC-69822 - This does not include "sub commands" like for example /scoreboard players ...
- See this crowdin discussion (German)
It seems like the command syntax suggestions are inconsistent or irritating.
Considering:
- <arg> = argument
- text = literal
- [] = optional
- [<arg>] = optional argument
- [<arg1> <arg2>] = optional arguments, either both have to be provided or both have to be omitted
- [text] = optional literal
- | as or
- text1|text2 = either text1 or text2 has to be provided literal
Note: This implies that arguments never use one of these characters
General
achievement
/achievement <give|take> <stat_name|*> [player] /achievement give|take <stat name>|* [<player>]
Note: The underscore is not needed as it doesn't exactly uses an argument called "stat_name". However something like <stat or achievement> would make more sense as the /achievement command was mainly made to interact with achievements (I guess, see also MC-80826)
ban
/ban <name> [reason ...] /ban <name> [<reason ...>]
ban-ip
/ban-ip <address|name> [reason ...] /ban-ip <address|name> [<reason ...>]
clear
/clear [player] [item] [data] [maxCount] [dataTag] /clear [<player>] [<item>] [<data>] [<maxCount>] [<dataTag>]
clone
/clone <x1> <y1> <z1> <x2> <y2> <z2> <x> <y> <z> [maskMode] [cloneMode] /clone <x1> <y1> <z1> <x2> <y2> <z2> <x> <y> <z> [<maskMode>] [<cloneMode>]
debug
/debug <start|stop> /debug start|stop
effect
/effect <player> <effect> [seconds] [amplifier] [hideParticles] OR /effect <player> clear /effect <player> <effect> [<seconds>] [<amplifier>] [<hideParticles>] OR /effect <player> clear
enchant
/enchant <player> <enchantment ID> [level] /enchant <player> <enchantment ID> [<level>]
fill (See also MC-80823)
/fill <x1> <y1> <z1> <x2> <y2> <z2> <TileName> [dataValue] [oldBlockHandling] [dataTag] /fill <x1> <y1> <z1> <x2> <y2> <z2> <TileName> [<dataValue>] [<oldBlockHandling>] [<dataTag>]
gamemode
/gamemode <mode> [player] /gamemode <mode> [<player>]
gamerule
/gamerule <rule name> [<value>]
give
/give <player> <item> [amount] [data] [dataTag] /give <player> <item> [<amount>] [<data>] [<dataTag>]
help
/help [page|command name] /help [<page>|<command name>]
kick
/kick <player> [reason ...] /kick <player> [<reason ...>]
kill
/kill [player|entity] /kill [<player|entity>]
particle
/particle <name> <x> <y> <z> <xd> <yd> <zd> <speed> [count] [mode] /particle <name> <x> <y> <z> <xd> <yd> <zd> <speed> [<count>] [<mode>]
Note: I assume the "d" means delta (or difference), however then it is inconsistent with the arguments dx, dy and dz from selectors
playsound
/playsound <sound> <source> <player> [x] [y] [z] [volume] [pitch] [minimumVolume] /playsound <sound> <source> <player> [<x>] [<y>] [<z>] [<volume>] [<pitch>] [<minimumVolume>]
recipe
/recipe <give|take> [player] <name|*> /recipe give|take <player> <name>|*
replaceitem
/replaceitem <entity|block> ... /replaceitem entity|block ...
scoreboard
/scoreboard <objectives|players|teams> ... /scoreboard objectives|players|teams ...
setblock
/setblock <x> <y> <z> <TileName> [dataValue] [oldBlockHandling] [dataTag] /setblock <x> <y> <z> <TileName> [<dataValue>] [<oldBlockHandling>] [<dataTag>]
spawnpoint
/spawnpoint [player] [<x> <y> <z>] /spawnpoint [<player>] [<x> <y> <z>]
stats
/stats <entity|block> ... /stats entity|block ...
summon
/summon <EntityName> [x] [y] [z] [dataTag] /summon <EntityName> [<x> <y> <z>] [<dataTag>]
Note: For summon the current help is anyways incorrect as you cannot set only one coordinate, or at least it will have no impact on where the entity gets spawned
testfor
/testfor <player> [dataTag] /testfor <player> [<dataTag>]
testforblock
/testforblock <x> <y> <z> <TileName> [dataValue] [dataTag] /testforblock <x> <y> <z> <TileName> [<dataValue>] [<dataTag>]
testforblocks
/testforblocks <x1> <y1> <z1> <x2> <y2> <z2> <x> <y> <z> [mode] /testforblocks <x1> <y1> <z1> <x2> <y2> <z2> <x> <y> <z> [<mode>]
time
/time <set|add|query> <value> /time set|add|query <value>
title
/title <player> <title|subtitle|clear|reset|times> ... /title <player> title|subtitle|clear|reset|times ...
tp
/tp [target player] <destination player> OR /tp [target player] <x> <y> <z> [<y-rot> <x-rot>] /tp [<target player>] <destination player> OR /tp [<target player>] <x> <y> <z> [<y-rot> <x-rot>]
trigger
/trigger <objective> <add|set> <value> /trigger <objective> add|set <value>
weather
/weather <clear|rain|thunder> [duration in seconds] /weather clear|rain|thunder [<duration in seconds>]
worldborder
/worldborder <set|center|damage|warning|get|add> ... /worldborder set|center|damage|warning|get|add ...
xp
/xp <amount> [player] OR /xp <amount>L [player] /xp <amount> [<player>] OR /xp <amount>L [<player>]
spreadplayers
/spreadplayers <x> <z> <spreadDistance> <maxRange> <respectTeams true|false> <player ...>
<respectTeams true|false> would mean either respectTeams true or false as value. That is not correct. Maybe something like this would make more sense:
/spreadplayers <x> <z> <spreadDistance> <maxRange> <respectTeams> <player ...>
See for example effect as there hideParticles is an argument as well
Proof for the inconsistency
For example the /execute command has this syntax:
/execute <entity> <x> <y> <z> detect <x> <y> <z> <block> <data> <command>
According to all the other commands it should look like this instead:
/execute <entity> <x> <y> <z> <detect> <x> <y> <z> <block> <data> <command>
Another example is the /achievement command:
/achievement <give|take> <stat_name|*> [player]
This would imply that the second argument is either stat_name or * which is not correct. It is a stat name or "*"
Other problems
Some arguments use "...". While that makes sense for commands like scoreboard as after each possible argument follow different other arguments, it does certainly not make sense for
- /me
- /tell
The "..." have rather the function to indicate that multiple kinds of this argument can follow as used already for spreadplayers:
/spreadplayers <x> <z> <spreadDistance> <maxRange> <respectTeams true|false> <player ...> /spreadplayers ~ ~ 1 2 false @p @e[type=!Player]
This means however that the help for scoreboard teams join is incomplete:
/scoreboard teams join <team> [player] /scoreboard teams join <team> [<player ...>]
and
/tell <player> <private message ...> /tell <player ...> <private message>
- is duplicated by
-
- Resolved
- relates to
-
- Resolved
-
- Resolved
-
- Resolved
-
- Resolved
-
- Resolved