CustomArgumentInfo.previousArgs is empty (should contain PlayerArgument)

CommandAPI version: 8.4.1

Minecraft version: 1.18.2

Shading the CommandAPI? yes

What I did:

My plugin stores “profiles” (just an object in memory) for all players. Admins should be able to access profiles by other players, for that purpose I have two arguments. SenderOwnedProfileArgument, which gets the player who is the command sender and gets their profiles, which works perfectly. TargetOwnedProfileArgument, for the admin commands, which gets a previous arg, casts it to a player and follows the same procedure, this breaks.

This is the code for the custom argument which breaks: https://www.toptal.com/developers/hastebin/cubihezazu.java This is the line where I add the arguments: .withArguments(new PlayerArgument("target"), new TargetOwnedProfileArgument(this.plugin.getAPI().getPlayerList(), messages, "profile", 0).get()) This is the command I run: /adminprofiles profile BeefDevClone a

The withArguments method is called on a subcommand (profile) which is later added to adminprofiles as a subcommand. BeefDevClone is supposed to be the player argument (name of my account), and a is the name of one BeefDevClone’s profiles.

What actually happened:

After I executed the command I get a Error in executing command adminprofiles profile BeefDevClone a - a<--[HERE]. Printing inside the function which creates the argument (before line 35 in the code). Shows that the previousArgs array is empty, even though the player argument is before the custom one. This causes the call in line 35 to fail because the array is empty (I assume an ArrayIndexOutOfBoundsException is thrown somewhere.).

Sadly no error logs apart from this.

What should have happened:

The PlayerArgument is added to the array, the custom argument gets it and executes normally.

[JorelAli]

Fixed in 8.5.1.

[JorelAli]

@willkroboth

The loop that adds objects to the array returned by CustomArgumentInfo#previousArgs breaks once it gets to an argument with the node name equal to the argument for which it is generating the previous arguments. This works as intended if there are no arguments with the same name, which is not necessarily a valid assumption.

Well yes, but technically no. Brigadier requires required arguments to have different names (i.e. it applies to all arguments except literal arguments). Arguments with the same name do conflict internally as well in Brigadier (implemented in CommandContext#getArgument, which uses a map of argument names to parsed arguments). I’m fairly certain simply omitting the case of literal arguments would be sufficient.

Everything else you said about calling the generatePreviousArguments multiple times sounds pretty plausible however! I’m all for any performance improvements 😃