Internal CommandAPI

The CommandAPI does a lot of stuff "behind the scenes". This internal CommandAPI section will go into detail about what the CommandAPI does, how it's implemented and why it has been implemented like that.

Argument identifiers

The CommandAPI's arguments are basically representations of the different arguments that the Minecraft Command Data protocol handles. These are outlined in the table below:

There are a few arguments that aren't implemented. Here's why:

• minecraft:entity_anchor - This argument only has two values: eyes and feet. It's incredibly unnecessary for any other purpose and is easier to implement with a MultiLiteralArgument.

• minecraft:item_slot - Bukkit's implementation of item slot numbers differs very wildly to Minecraft's implementation of item slot numbers. This difference makes it near-impossible to have a suitable middle-ground for item slot numbers that ensures that invalid numbers cannot be passed to the wrong inventory type. An implementation of this would require a rewrite of the current system to maintain proper inventory slot access safety.

• minecraft:nbt, minecraft:nbt_path, minecraft:nbt_tag - You've got the NBTCompoundArgument, that's good enough, right? ¯\_(ツ)_/¯

Reloading datapacks

During the initialization of Minecraft 1.16+ servers, the CommandAPI uses a custom datapack reloading sequence as opposed to the normal Vanilla Minecraft datapack reloading method. The CommandAPI's method uses the server's current command dispatcher object as opposed to a new one, which allows datapacks to use commands registered by the CommandAPI. This can be invoked using the following method:

CommandAPI.reloadDatapacks();