A proposal for command modding and ambiguous commands

[IntegratedQuantum]

Commands are a bit of a special-case:
Mods will inevitably want to add commands with the same name. For all other assets this is solved by adding mod: in front of it, but for commands this would be rather annoying. Autocomplete would make this bearable, but it would still make commands needlessly long.

Beyond that there is a second problem: Ambiguous commands. As commands get more complex we (or a mod author) may find ourselves in a situation where multiple results may be parsed. One example of this would /tp <biome> and (hypothetical) /tp <structure>, if any biome id matches a structure id, it is unclear where to tp the player.

To solve this I propose to send an error to the player when this happens and give them an option to resolve the conflicts, possible message:

Found ambiguous arguments for command ..., could be
/tp[1] <biome>
/tp[4] <structure>

The numbers would be the index based on the order of the command arguments union (and the order of mods), to select one variant you could then just run /tp[1] cubyz:xyz

[Wunka]

While this is a solution. I still like the mod: solution more. This would give the player a better idea about what the index means. I suggest maybe something in this direction:

Found ambiguous arguments for command ..., could be
/tp <biome>
/tp <structure>
please type either /tp biome:<id> or /tp structure:<id>

this could then also later be used for non index based optional arguments.
We probably need some kind of reserved key to indicate that the start is talking about the argument name.
For overloaded commands you can do:

Found ambiguous arguments for command ..., could be
/cubyz:tp <biome>
/mod:tp <biome>

While this does "bloat" the commands. I think it makes it more explicit and would pave the way for a maybe later more complex system

[IntegratedQuantum]

Adding biome: to the string may in itself also cause problems, e.g. if there is an addon with the same name, then it could cause more issues.

I do however agree that mod: is nicer. So let me extend on that:

/cubyz:tp:biome
/mod:tp:structure

Where the last part would be the name of the command in the code (currently it's @"/tp ...", but once we auto-generate these, we could replace them with a better name).

[Wunka]

Adding biome: to the string may in itself also cause problems, e.g. if there is an addon with the same name, then it could cause more issues.

That's why I said this:

We probably need some kind of reserved key to indicate that the start is talking about the argument name.

Something like /tp $biome:cubyz:rare/rainbow_forest
Or mabye if we don't use = somewhere:
/tp biome=cubyz:rare/rainbow_forest
Maybe even go full zig mode:
/tp .biome=cubyz:rare/rainbow_forest

[Argmaster]

The issue with mod:foo or even worse mod:bar/foo is that it's very unintuitive. It requires you to start referencing the namespace where something is, instead of referencing the thing they want to use. That makes the auto completion very inefficient, since boilerplate is the first thing you have to write, before you actually communicate to auto complete what you intend to use.

Approach proposed in the issue is good, although it would require extra QOL refinement to make it more pleasant. Even though we have history, moving cursor through whole message to add square brackets and a number is tedious. I would suggest to make the command clickable in UI and for shell usage re-prompt for the number alone.

there is an addon with the same name

We could require leading : to imply mod name has to be inferred.

/tp .biome=cubyz:rare/rainbow_forest

Or we can go typical shell syntax route --biome=

In general anything that delocalizes the knowledge is annoying.
Keyword/flag option is IMO better because it keeps the knowledge localized - meaning of an argument is annotated right next to an argument. On the contrary both numbering and word approaches delocalizes the knowledge moving annotation to the start of the command, regardless of where the ambiguity happened. That also doesn't scale if there are multiple ambiguities.

[Wunka]

I do however agree that mod: is nicer. So let me extend on that:

/cubyz:tp:biome
/mod:tp:structure

Where the last part would be the name of the command in the code (currently it's @"/tp ...", but once we auto-generate these, we could replace them with a better name).

I would also find this an acceptable solution. Mine would allow as said non index based optional arguments, but this is also soemthing we don't really need. One thing where it could be interesting is with multiple optional arguments e.g: #3106 (comment)
What if both optional arguments have overlapping ok arguments?

[Wunka]

/tp .biome=cubyz:rare/rainbow_forest

Or we can go typical shell syntax route --biome=

👍 I like both, but the shell syntax is probably better as its more known. But at the same time .biome would fit better with zon syntax wich if people touch addons it is not far fetched. So consistency may also play a role here

[IntegratedQuantum]

I would also prefer the . syntax. I think it's better to be consistent with our addon files, than to be consistent with the command line (where honestly the patterns are much more varied, --biome=value is hte most common these days, but I still frequently see -biome value or, on that one special OS that wants to do everything differently, /biome value)

We could also make a poll for this on the discord.

[tillpp]

i did like the /tp[mod] idea,
but it would add more to type ( [] is one more characters then : ), and we want commands to be short/fast to write

the --biome=value type command does fit with CLI,
I think there was some talk about using cubyz as a CLI tool. And i think this would be a good step into that direction.

[IntegratedQuantum]

and we want commands to be short/fast to write

Ideally you'd only need to write it when the parser cannot find a clear match

[Argmaster]

Yeah I have in mind that we may want to accept shell arguments for Cubyz executable and having single tool do both would be convenient.

[IntegratedQuantum]

CLI is besides the point. If you think there is a use-case for command-line arguments (when we already have the launchconfig), then please make an issue for it.