Pass CommandSourceStack to convert method of CustomArgumentType.Converted

[xaanndeer]

Is your feature request related to a problem?

Using the new Brigadier API, I would like to create a custom argument type that returns a direct player instead of a list with just one player in it. Unfortunately I'm unable to since PlayerSelectorArgumentResolver needs a CommandSourceStack to be resolved.

public class SinglePlayerArgumentType implements CustomArgumentType.Converted<Player, PlayerSelectorArgumentResolver> {

    @Override
    public @NotNull Player convert(@NotNull PlayerSelectorArgumentResolver playerSelectorArgumentResolver) throws CommandSyntaxException {
        return playerSelectorArgumentResolver.resolve(<commandSourceStack>);
    }

    @Override
    public @NotNull ArgumentType<PlayerSelectorArgumentResolver> getNativeType() {
        return ArgumentTypes.player();
    }

}

Describe the solution you'd like.

To extend the functionality of custom argument types it would come in handy to pass the current CommandSourceStack to the convert method of the interface. This could e.g. be used to return a different object depending on the command dispatcher, allow developers to create custom argument types that return an entity from a SelectorArgumentResolver that needs custom requirements, ...

Describe alternatives you've considered.

Create my own extension of ArgumentType

Other

No response

[Machine-Maker]

This is a brigadier limitation. The current executor is not available when an argument type is being parsed. If you look at the brigadier ArgumentType interface, you will see that the parse method only takes a StringReader, and doesn't have any other context to parse. That is why a lot of the arguments have a "resolve" method because it later has to use the current executor to get the value of the argument.

Also, calling getFirst on the list returned by the player selector isn't really a big deal imo, so that's why we didn't add 2 more unique result types for a single player and single entity.

EDIT: It is not the goal of this addition to the Paper API to create a command framework, only the bare minimum required to make the brigadier library useable by plugins. If you want a more complete (and better IMO) command framework, you can look at other existing options (cloud, CommandAPI, acf, etc.)

[xaanndeer]

Ah, I wasn't aware this is a Brigadier limitation since I believed arguments get parsed when a command dispatcher well... dispatches a command. Thanks for the quick reply though!

[Machine-Maker]

brigadier is different in that it lets you "parse" the commands into a pre-parsed container, and then execute that for any executor. This is ofc, only possible if you can parse a command without an executor. And as such, the executor is not available during parsing.