Implementing support for sub commands has always been something I wanted to do, but there were certain road blocks, mainly with how commands are parsed. However, those issues only persist if you're trying to implement sub commands as support for spaces in command names, which results in other problems too, and so I've come up with a far better alternative approach.
Instead of making it the parser's job to run the correct sub command, you instead make command blocks support sub commands directly via "nesting" additonal command blocks. This way, the parser only has to parse the "root" command as it usually would, and then if there are nested command blocks, each consequtive argument matching a command name can be checked/parsed by each layer of nesting with the same code.
In practice, this will be more efficient and easier to implement than using the parser, and allows for all command block features to be retained in sub commands.
Implementing support for sub commands has always been something I wanted to do, but there were certain road blocks, mainly with how commands are parsed. However, those issues only persist if you're trying to implement sub commands as support for spaces in command names, which results in other problems too, and so I've come up with a far better alternative approach.
Instead of making it the parser's job to run the correct sub command, you instead make command blocks support sub commands directly via "nesting" additonal command blocks. This way, the parser only has to parse the "root" command as it usually would, and then if there are nested command blocks, each consequtive argument matching a command name can be checked/parsed by each layer of nesting with the same code.
In practice, this will be more efficient and easier to implement than using the parser, and allows for all command block features to be retained in sub commands.