Skip to content

CommandTree

tom2208 edited this page Nov 13, 2021 · 10 revisions

The Problem this Datastructure should solve

While implenting we got confronted with a repeating pattern of code: Some nested-ifs to assign the functionality to the right subcommand; syntax error messaging needed a high amount of hard-coding; the TabComplition for every new command was a very similar thing too.

The Solution: The CommandTree datastructure

Our solution is a tree structure for the commands. Every node represents a subcommand thus a command a CommandSender wants to execute would be a path on the command tree. It checks for the arguments being valid for the special nodes and then executes the correct command or sends an errror message. I will elaborate it in detail by using a cutout of the CommandTree of our CleaningItemCommand class.

CommandTree Example: CleaningItemCommand

There are several types of nodes:

  • type node: indicated with type:<label> in the image; this node checks if the argument can be interpreted as a special type (eg. BlacklistType, Player, String, Float). Important is: the children of a node can be neutrales or they must differentiate in their type. If we have two nodes with the same type only one will be reached every time.

  • executable node: short executables; colored blue; idicates an executable command. That means if a player trys to execute a command the algorithm goes through the CommandTree and if it ends on an executable command it will try to execute it (This would work for /cleaningitem get). This node can be a type node too.

  • definite execute node: colored yellow; these nodes are similar to the executables but this node will not only execute if the alogrith ends here it further forces the alogirth ending and executing the command. This is useful for commands that need texts as an argument. In our example we got the command /cleaningitem name <name> a space would result in a new argument thus in an sytax error if the text is long enough. This node can be a type node too.

  • neutral node: short neutrals; colored white; these nodes can not be executed if the algorith ends on them this would result in an synatax error message sent to the CommandSender. An example for this node is active on the image. (this nodes is an executable in our code too and sends the status of the cleaning item being active or not but we change that for our explanation)

  • the root: colored green; there is alway only one root. The root itself can be an executable but not a type node. An example for a executable root is the CleanInventory command. Its label gets initialized with the CommandTree.