User Tools

Site Tools


Sidebar

← Go back to the homepage

Fabric Tutorials

Setup

Basics

These pages are essential must-reads when modding with Fabric, and modding Minecraft in general, if you are new to modding, it is recommended you read the following.

Items

Blocks and Block Entities

Data Generation

World Generation

Commands

These pages will guide you through Mojang's Brigadier library which allows you to create commands with complex arguments and actions.

Events

These pages will guide you through using the many events included in Fabric API, and how to create your own events for you or other mods to use.

Entities

Fluids

Mixins & ASM

These pages will guide you through the usage of SpongePowered's Mixin library, which is a highly complex topic. We recommend you read these pages thoroughly.

Miscellaneous

Yarn

Contribute to Fabric

tutorial:commands

Licensing: The code in this article is licensed under the “Creative Commons Zero v1.0 Universal” license. The license grants you the rights to use the code examples shown in this article in your own mods.

Creating Commands

Creating commands can allow a mod developer to add functionality that can used through a command. This tutorial will teach you how to register commands, and the general command structure of Brigadier.

Note: All code written here was written for 1.19.2. For old versions, some versions and mappings may differ.

What is Brigadier?

Brigadier is a command parser & dispatcher written by Mojang for use in Minecraft. Brigadier is a tree based command library where you build a tree of arguments and commands.

The source code for brigadier can be found here: https://github.com/Mojang/brigadier

The ''Command'' interface

In Minecraft, Command (com.mojang.brigadier.Command) is an functional interface that run some specific things, and throw a CommandSyntaxException in some cases. It has a generic type S, which defines the type of the command source. The command source provides some context in which a command was ran. In Minecraft, the command source is typically a ServerCommandSource which can represent a server, a command block, rcon connection, a player or an entity. In some cases, it can also be a ClientCommandSource.

The single method in Command, run(CommandContext<S>) takes a CommandContext<S> as the sole parameter and returns an integer. The command context holds your command source of S and allows you to obtain arguments, look at the parsed command nodes and see the input used in this command.

Like other functional interfaces, it is usually used as a lambda or a method reference:

Command<ServerCommandSource> command = context -> {
    return 0;
};

In vanilla Minecraft, they are usually used as method references, such as static methods named register under classes named XXXCommand.

The integer can be considered the result of the command. In Minecraft, the result can correspond to the power of a redstone comparator feeding from a command block or the value that will be passed the chain command block the command block is facing. Typically negative values mean a command has failed and will do nothing. A result of 0 means the command has passed. Positive values mean the command was successful and did something.

What can the ServerCommandSource do?

A ServerCommandSource provides some additional implementation specific context when a command is run. This includes the ability to get the entity that executed the command, the world the command was ran in or the server the command was run on.

  1. // Get the source. This will always work.
  2. final ServerCommandSource source = ctx.getSource();
  3.  
  4. // Unchecked, may be null if the sender was the console.
  5. final Entity sender = source.getEntity();
  6.  
  7. // Will end the command if the source of the command was not an Entity.
  8. // The result of this could contain a player. Also will send feedback telling the sender of the command that they must be an entity.
  9. // This method will require your methods to throw a CommandSyntaxException.
  10. // The entity options in ServerCommandSource could return a CommandBlock entity, any living entity or a player.
  11. final Entity sender2 = source.getEntityOrThrow();
  12.  
  13. // Will end the command if the source of the command was not explicitly a Player. Also will send feedback telling the sender of the command that they must be a player. This method will require your methods to throw a CommandSyntaxException
  14. final ServerPlayerEntity player = source.getPlayer();
  15.  
  16. // Get's the sender's position as a Vec3 when the command was sent. This could be the location of the entity/command block or in the case of the console, the world's spawn point.
  17. source.getPosition();
  18.  
  19. // Get's the world the sender is within. The console's world is the same as the default spawn world.
  20. source.getWorld();
  21.  
  22. // Get's the sender's rotation as a Vec2f.
  23. source.getRotation();
  24.  
  25. // Access to the instance of the MinecraftServer this command was ran on.
  26. source.getServer();
  27.  
  28. // The name of the command source. This could be the name of the entity, player, the name of a CommandBlock that has been renamed before being placed down or in the case of the Console, "Console"
  29. source.getName();
  30.  
  31. // Returns true if the source of the command has a certain permission level. This is based on the operator status of the sender. (On an integrated server, the player must have cheats enabled to execute these commands)
  32. source.hasPermissionLevel(int level);

Register a basic command

Commands are registered by registering in CommandRegistrationCallback in the Fabric API. For information on registering callbacks, please see the callbacks.

The event should be registered in your mod's initializer. The callback has three parameters. The CommmandDispatcher<S> is used to register, parse and execute commands. S is the type of command source the command dispatcher supports, which is usually ServerCommandSource. The second parameter provides an abstraction to registries which may be passed to certain command argument methods. The third parameter is a RegistrationEnvironment which identifies the type of server the commands are being registered on.

To simplify the code, it is highly recommended to static import the methods in CommandManager (see Static Imports):

import static net.minecraft.server.command.CommandManager.*;

In the mod initializer, we just register the simplest command:

  1. public class ExampleMod implements ModInitializer {
  2. @Override
  3. public void onInitialize() {
  4. CommandRegistrationCallback.EVENT.register((dispatcher, registryAccess, environment) -> dispatcher.register(literal("foo")
  5. .executes(context -> {
  6. // For versions below 1.19, replace "Text.literal" with "new LiteralText".
  7. context.getSource().sendMessage(Text.literal("Called /foo with no arguments"));
  8.  
  9. return 1;
  10. })));
  11. }
  12. }

CommandManager.literal(“foo”) tells brigadier this command has one node, a literal called foo.

To execute this command, you must type /foo, with is case-sensitive. If /Foo, /FoO, /FOO, /fOO or /fooo is typed instead, the command will not run.

If desired, you can also make sure a command is only registered under some specific circumstances, for example, only in the dedicated environment:

  1. public class ExampleCommandMod implements ModInitializer {
  2. @Override
  3. public void onInitialize() {
  4. CommandRegistrationCallback.EVENT.register((dispatcher, registryAccess, environment) -> {
  5. if (environment.dedicated) {
  6. ...;
  7. }
  8. });
  9. }
  10. }

Static Imports

In the example above, the use of static imports is used for code simplifying. For a literal this would shorten the statement to literal(“foo”). This also works for getting the value of an argument. This shortens StringArgumentType.getString(ctx, “string”) to getString(ctx, “string”). This also works for Minecraft's own argument types.

Below is an example of some static imports:

  1. // getString(ctx, "string")
  2. import static com.mojang.brigadier.arguments.StringArgumentType.getString;
  3. // word()
  4. import static com.mojang.brigadier.arguments.StringArgumentType.word;
  5. // literal("foo")
  6. import static net.minecraft.server.command.CommandManager.literal;
  7. // argument("bar", word())
  8. import static net.minecraft.server.command.CommandManager.argument;
  9. // Import everything in the CommandManager
  10. import static net.minecraft.server.command.CommandManager.*;

Note: Please be sure you use the literal and argument from CommandManager instead of other classes, or you may have issues with generics when trying to compile.

Brigadier's default arguments are at com.mojang.brigadier.arguments

Minecraft's arguments are in net.minecraft.command.arguments. CommandManager is in the package net.minecraft.server.command.

Requirements

Let's say you have a command that you only want operators to be able to execute. This is where the requires method comes into play. The requires method has one argument of a Predicate<ServerCommandSource> which will supply a ServerCommandSource to test with and determine if the CommandSource can execute the command.

For example this may look like the following:

  1. dispatcher.register(literal("foo")
  2. .requires(source -> source.hasPermissionLevel(4))
  3. .executes(ctx -> {
  4. ctx.getSource().sendFeedback(Text.literal("You are an operator"), false);
  5. return 1;
  6. });

This command will only execute if the source of the command is a level 4 operator at minimum. Otherwise, the command is not registered. Also this has the side effect of not showing this command in tab completion to anyone who is not a level 4 operator. This is also why you cannot tab-complete most commands when you did not enable cheating.

Arguments

Arguments in Brigadier both parse and error check any inputted arguments. Minecraft creates some special argument types for it's own use such as the EntityArgumentType which represents the in-game entity selectors @a, @r, @p, @e[type=!player, limit=1, distance=..2], or an NbtTagArgumentType that parses stringified nbt (snbt) and verifies that the input is the correct syntax.

TODO: Go into more detail on how to use arguments

A sub command

To add a sub command, you register the first literal node of the command normally.

  1. dispatcher.register(literal("foo"))

In order to have a sub command, one needs to append the next node to the existing node. This is done use the then(ArgumentBuilder) method which takes in an ArgumentBuilder.

This creates the command foo <bar> as shown below.

  1. dispatcher.register(literal("foo")
  2. .then(literal("bar"))
  3. );

It is advised to indent your code as you add nodes to the command. Usually the indentation corresponds to how many nodes deep one is on the command tree. The new line also makes it visible that another node is being added. There are alternative styles to formatting the tree command that are shown later on in this tutorial.

So let's try running the command

Most likely if you typed /foo bar in game, the command will fail to run. This is because there is no code for the game to execute when all the required arguments have been met. To fix this, you need to tell the game what to run when the command is being executed using the executes(Command) method. Below is how the command should look as an example.

  1. dispatcher.register(literal("foo")
  2. .then(literal("bar")
  3. .executes(context -> {
  4. // For versions below 1.19, use ''new LiteralText''.
  5. context.getSource().sendMessage(Text.literal("Called foo with bar"));
  6.  
  7. return 1;
  8. })
  9. )
  10. );

Advanced concepts

Below are links to the articles about more complex concepts used in brigadier.

Page Description
Exceptions Fail execution of a command with a descriptive message and in certain contexts.
Suggestions Suggesting command input for the client.
Redirects Allow use of aliases or repeating elements to execute commands.
Custom Argument Types Parse your own arguments into your own objects.
Examples Some example commands

FAQ

Why does my command not compile

There are two immediate possibilities for why this could occur.

Catch or throw a CommandSyntaxException

The solution to this issue is to make the run or suggest methods throw a CommandSyntaxException. Brigadier will handle the checked exceptions and forward the proper error message in game for you.

Issues with generics

You may have an issue with generic types once in a while. Verify you are using CommandManager.literal(…) or CommandManager.argument(…) instead LiteralArgumentBuilder or RequiredArgumentBuilder in your static imports.

Can I register client side commands?

Fabric has a ClientCommandManager that can be used to register client side commands.

Dark Arts

A few things we don't recommend, but are possible.

Can I register commands in runtime?

You can do this but it is not recommended. You would get the CommandManager from the server and add anything commands you wish to it's CommandDispatcher.

After that you need to send the command tree to every player again using CommandManager.sendCommandTree(ServerPlayerEntity). This is required because the client locally caches the command tree it receives during login (or when operator packets are sent) for local completions rich error messages.

Can I unregister commands in runtime?

You can also do this, however it is much less stable than registering commands and could cause unwanted side effects. To keep things simple, you need to use reflection on brigadier and remove the nodes. After this, you need to send the command tree to every player again using sendCommandTree(ServerPlayerEntity). If you don't send the updated command tree, the client may think a command still exists, even though the server will fail execution.

tutorial/commands.txt · Last modified: 2022/08/08 02:24 (external edit)