whimxiqal / mantle Goto Github PK

• Integer
• Player
  etc.

Currently, a help menu won't show up for a command unless the CommandInfo is set and the rule has a description. If the CommandInfo is set, a help menu should still appear with just the list of subcommands, and just with an empty description if the description isn't provided in the CommandInfo.

Boilerplate code in many executor methods can be eliminated with custom annotations like:

• PlayerOnly

Right now, permissions are handled by seeing which items in the parser tree show up as the command is parsed and connecting them to saved permissions. There should be an extra flag for addPermission in the command connector that specifies whether the permission is only meant for the command if there are no children on the command.

For example, /foo bar may have permission foo.bar, but also have a permission foo for if you want to run just /foo. Currently, if you want to specify that your rule RULE_foo has permission foo and your rule RULE_foobar has permission foo.bar, you will not be able to run /foo bar if permission foo is false.

A current work around is to just to extra permission checks within the executor and not include the root-command permission in the connector.

Help command should only show options for subcommands, not for possible custom completions, like player names

Currently, registering a parameter just provides the command source, such as the player. The registration should include information about the rest of the command.

One way to do this is allow the dev to register one or more "preprocessing" phases. This can get all the identifiers and also any other custom types of content like flags. This can be supplied to the dev for command completion and can also be supplied in the command executor so the dev doesn't have to manage the collection of identifiers themselves.

Subcommands should include their descriptions in the help menu, not just the subcommand itself

In the spirit of using Antlr4 to its fullest potential, I've decided supporting help commands altogether is too difficult and would require duplicating info in the connector.

The main reason why it's difficult is because "command" following the next one can be any number of things, which is either the next token after the current rule or any of the possible completion values for the next rule, which are all provided by the identifier info. Deciding what to send as a "subcommand" and applying the right description is not trivial and may not even conform any nonconventional approaches to command structures anyway.

There are ways to salvage some help command support, like providing a list of completions rather than "subcommands" and their descriptions, which is conducive to more eclectic grammars. But I'll only implement this if there's a push for it

Currently, if there's an ANTLR parsing error, which is just that someone types a command wrong, a very difficult-to-read error message appears that's very accurate, but not very Minecraft-y. This error should be made better

Add a configurable parameter on initialization that determines which language to use for logging, messaging, and errors

Implementing languages other than English will be tracked in other issues

New domain: whimxiqal.net

Currently, devs must parse children rules to find all the identifiers before running the command logic and any specific rule. Instead, during a preliminary parsing stage, all the relevant identifiers should be found and collected to be passed into the provide method of the CommandExecutor so during primary command parsing, all identifiers are available.

This change would include a registration of the dev's custom identifier rule in the CommandConnector, since we should make no assumptions about how the dev will manage identifiers.

In addition to the various options for command completion, parameters should include validation so it doesn't have to happen in the executor.