An user of my plugin using Lamp on a GeyserMC+Floodgate server is having this issue while trying to execute a command with a player selector: He sent me his Floodgate config:

# Floodgate prepends a prefix to bedrock usernames to avoid conflicts
# However, certain conflicts can cause issues with some plugins so this prefix is configurable using the property below
# It is recommended to use a prefix that does not contain alphanumerical to avoid the possibility of duplicate usernames.
username-prefix: '*'

It seems like Lamp recognizes the star as an incorrect username character and completely blocks player selector from there. Is it possible to fix this, or at least have an option somewhere to allow "unsafe" usernames? Some plugins do have such options: LuckPerms have a allow-invalid-usernames boolean config option, and ChestChop have a VALID_PLAYERNAME_REGEXP regex option.

Hey! Is it possible to have a command under a parent, and also be standalone simultaneously? If that doesn't make sense to you, here; let me show you a demonstration of the idea:

@Command("parent")
public final class ExampleCommand {
    
    @Default // /parent
    public String defaultCommand() {
        return "default command";
    }
    
    @Subcommand("sub") // /parent sub
    public String subCommand() {
        return "sub command";
    }
    
    @Command("test") // /test
    @Subcommand("test") // /parent test
    public String subCommand2() {
        return "test command";
    }
}

If so, could you please show me how I could achieve such a thing? Thank you!

Error occurs with jda module. When user sends picture, or emote MessageReceivedEvent occurs, and MessageReceivedEvent#getMessage#getContentRaw returns empty string.

java.util.NoSuchElementException
at java.util.LinkedList.getFirst(LinkedList.java:244)
at revxrsal.commands.core.BaseCommandDispatcher.eval([BaseCommandDispatcher.java:33](https://github.com/Revxrsal/Lamp/blob/5d00ebe8ec30e2f5f24db5d57717fc0a682c8eb2/common/src/main/java/revxrsal/commands/core/BaseCommandDispatcher.java#L33))
at revxrsal.commands.core.BaseCommandHandler.dispatch([BaseCommandHandler.java:519](https://github.com/Revxrsal/Lamp/blob/5d00ebe8ec30e2f5f24db5d57717fc0a682c8eb2/common/src/main/java/revxrsal/commands/core/BaseCommandHandler.java#L519))

I think it occurs because BaseCommandHandler#parseArguments returns ArgumentStack.empty() when string empty.

So if we add something like this to the BaseCommandDispatcher#eval:

if(arguments.isEmpty()) throw new InvalidCommandException("", "");

Everything will be fine

this PR adds value resolver for org.bukkit.NamespacedKey with resource_location brigadier type to support nice client-side formatting

bumped Lamp version to 3.0.4-SNAPSHOT

each default arg type bound like this: but the type does not do anything at all in the bind method: and the parameter's class type hasn't check in the argument resolver too: and looks like it does support nullable too: so i've made the string resolver like this:

public interface CommandFactory {
  @Inject
  @NotNull
  @Provides
  @Singleton
  static BukkitCommandHandler commandManager(@NotNull final Plugin plugin) {
    final var handler = BukkitCommandHandler.create(plugin);
    handler.registerBrigadier();
    handler.enableAdventure();
    handler
      .getBrigadier()
      .orElseThrow()
      .registerArgumentTypeResolver(
        0,
        parameter -> {
          if (parameter.getType() != String.class) {
            return null;
          }
          if (parameter.getType().isAnnotationPresent(Quoted.class)) {
            return StringArgumentType.string();
          }
          if (parameter.consumesAllString()) {
            return StringArgumentType.greedyString();
          }
          return StringArgumentType.word();
        }
      );
    return handler;
  }
}

am i wrong with the returning null if the parameter is not a string? because looks like if it does not find any resolver, returns string already so it should check the parameter type first.

Lamp currently supports arguments provided by Brigadier library directly. There are, however more Minecraft-specific arguments included in game internals. All of them are handled by the client to support completions etc. (see wiki)

They can be accessed with a bit of reflection or NMS on supported platforms. Do note there is a Paper PR (https://github.com/PaperMC/Paper/pull/6695) open to expose them directly to the API which may, or may not be merged in the future.

Notes

• Some existing arguments would need to be handled differently to mimic their brigadier parser behavior.
  • Lamp uses StringArgumentType for String which expects validation (see this)
  • EntitySelector<T> should refer to internal minecraft:entity type to support rich client-side completions.
• Supporting some arguments (eg. minecraft:vec2 and vec3) could be a bit hacky and would most likely require internal changes.

Thoughts

Since that have more side effects than it sounds, I think that addition of BrigadierCommandHandler (or similar) is necessary. This would keep current users unaffected by these changes and also make brigadier easier to maintain.

Sponge

I know nothing about Sponge and can't really suggest anything in that regards. I can only say that since all (minecraft) platforms can use Brigadier, maybe a new module structure is needed. (example)

MinecraftCommandHandler<T> extends CommandHandler<T> { ... }
BrigadierCommandHandler<T> extends MinecraftCommandHandler<T> { ... }

MinecraftCommandHandler<Bukkit> handler = ... // for simple commands
BrigadierCommandHandler<Bukkit> handler = ... // for brigadier commands

MinecraftCommandHandler<Sponge> handler = ... // for simple commands
BrigadierCommandHandler<Sponge> handler = ... // for brigadier commands

At the moment, the 3.0.1 release is currently not available on JitPack due to the error below, this PR solves the following issue:

⚠️ ERROR: No build artifacts found Expected artifacts in: $HOME/.m2/repository/io/github/revxrsal/bukkit/3.0.1

You can view the live result of this PR at https://jitpack.io/#Tofpu/Lamp/3.0.2

i.e. if I have the following commands:

mycom
mycom list
mycom add

The only command that shows up is mycom. (Each is its own method, and the path is specified in full via @Command) I am currently working on a plugin that would benefit from this functionality, so it would be best if Lamp supported it.

Hi, i have a question. Is it possible to get missing permission from NoPermissionException handler? if so how to do it?

my code: commandHandler.registerExceptionHandler(NoPermissionException.class, (actor, ex) -> { TextBuilder.builder() .text("&7You dont have permission to execute this command! &7(&c{PERM}&7)") .placeholder("{PERM}", I WANT TO GET MISSING PERMISSION HERE ) .send(((BukkitCommandActor) actor).getSender()); });

Hey,

I've encountered an issue with paper brigadier using latest Lamp version (from latest commit) on Paper 1.19.2.

Commands with multiple arguments (including optional ones) work as intended. But when I create a command with no arguments, brigadier expects an argument (which shouldn't be happening).

Code example:

@Command("testcmd")
public void execute(Player player) { ... }

Result in-game:

I should note that the same issue is with subcommands - if subcommand doesn't have arguments, same issue occurs.

Hey, I've been playing with Lamp for a while and I am trying something, but I can't figure out how.

Is ist possible to set args at a specific position in the (sub)command? Like "user <name> changePassword <password>" and not having all args at the end?

Hello,

A neat suggestion I think would be nice for Lamp is the option for @Flag and @Switch annotations to support aliases. I'm unsure if this is natively supported by brigadier since I've never worked with commands before, but it would be cool to use.

Perhaps the inputted array could override all of the names for the switch/flag, or add on upon the inputted parameter name (that could be an option in the CommandHandler). The original message is available on the Lamp Discord.

Something like this:

public void send(Player sender, @Flag({"sendtype", "sendingtype", "st"}) SendType type, @Switch({"broadcast", "sendall"}) boolean sendAll) {
   // ...
}

@SkytAsul (their original message) also recommended the option to mix flags and/or switches together, as in some Unix commands, such as:

rm -r -f
# Becomes...
rm -rf

Thanks!

With those two commands:

	@Subcommand("test")
	public void test(int dumbArg, @Optional Player optionalArg, @Switch boolean switchArg) {}

	@Subcommand("test2")
	public void test2(int dumbArg, @Switch boolean switchArg) {}

It's working normally when I do:

/mycommand test2 4 /mycommand test 5 /mycommand test 5 -switchArgs

But I am getting this: when executing:

/mycommand test2 4 -switchArg /mycommand test 5 SkytAsul -switchArg

But if I execute all of these commands in console, I get no issue. It's only for players. I also get normal syntax coloring in chat when typing the 2 failing commands, it only fails after I hit enter.

I can't find a reason why those two commands are failing.