See attached screenshot. Amongst others, the following inputs will trigger this bug:
Valid prefixes:
/clear @a[gamemode=cr(note it works properly without the lastr!)
Invalid prefixes:
/clear @a[gamemode=x/clear @a[gamemode==/clear @a[_rotation=
See attached screenshot. Amongst others, the following inputs will trigger this bug:
Valid prefixes:
/clear @a[gamemode=cr (note it works properly without the last r!)
Invalid prefixes:
/clear @a[gamemode=x
/clear @a[gamemode==
/clear @a[_rotation=
Confirmed
command-syntax-help, selector
Minecraft 18w05a
Minecraft 18w06a
Retrieved
This seems to be an attempt to show when arguments or their values are valid/invalid. Example:
/clear @a[gamemode=purple corrects it to: /clear @a[gamemode=]
/clear @a[magedome= corrects it to: /clear @a[]
This behavior might be a placeholder that the devs are using until they fully implement error handling and tab completion for selector arguments. The bracket is currently misaligned to show that the argument or value parameter is invalid, and it aligns properly when a valid argument is put in. Example:
/clear @a[type=player will properly align the closed bracket.
/clear @a[gamemode= will resolve to: /clear @a[gamemode=] to show that gamemode is a valid argument.
Also, the error handling still thinks that the shorthand versions for gamemodes, a, c, s, and sp, are still valid, even though they were removed. This is why /clear @a[gamemode=c (erroneously) places the bracket in the "correct" spot.