The CommandAPI should safeguard against duplicate command path types
Description
If a user registers multiple commands that have the same argument type paths, the CommandAPI should tell the user that there are commands with identical types which can lead to unexpected outcomes.
For example, if someone registers the following:
new CommandAPICommand("test")
.withArguments(new StringArgument("str_1"))
.executesPlayer((player, args) -> {
// str1.set((String) args[0]);
})
.register();
new CommandAPICommand("test")
.withArguments(new StringArgument("str_2"))
.executesPlayer((player, args) -> {
// str2.set((String) args[0]);
})
.register();
The following JSON is generated (as expected):
{
"type": "root",
"children": {
"test": {
"type": "literal",
"children": {
"str_1": {
"type": "argument",
"parser": "brigadier:string",
"properties": {
"type": "word"
},
"executable": true
},
"str_2": {
"type": "argument",
"parser": "brigadier:string",
"properties": {
"type": "word"
},
"executable": true
}
}
}
}
}
Running /test hello will always run using str_1, and the str_2 case will never be called. During command registration, an error warning message should be displayed on the second argument's registration - this will produce the same result (i.e. the second command can't be run) at all times.
Expected code
Fail to register the command message is displayed:
Failed to register command:
/test str_2<StringArgument>
Because it conflicts with this previously registered command:
/test str_1<StringArgument>
This should only be called when the whole path is identical in argument type. This doesn't apply to literal arguments.
Extra details
No response
This also doesn't apply to arguments that are distinguishable. For example, an integer argument with bounds (1, 10) and another with bounds (50, 100) are distinguishable if the values provided are 5 and 60.
However, if the first argument has bounds (1, 100) and the values are 5 and 60, they're indistinguishable (and all pass to the first case)
Alternatively (and ideally), the CommandAPI should use dispatcher.findAmbiguities to find the ambiguities in the command tree and generate some meaningful output based on that (which saves trying to implement an ambiguity checker)