-
-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect Argument Required #507
Comments
I split up your command so it's easier to see what's going on and ended with this: new CommandTree("request")
.then(new LiteralArgument("toggle")
.executesPlayer(info -> {
info.sender().sendMessage(Component.text().content("Toggled"));
})
)
.then(new MultiLiteralArgument("answer", "accept", "deny")
.withRequirement(sender -> {
if (!(sender instanceof Player player)) return false;
return true;
})
.then(new PlayerArgument("target")
.executesPlayer(info -> {
info.sender().sendMessage(Component.text().content("You chose option " + info.args().get("answer") + " with player name " + ((Player) info.args().get("target")).getName()));
})
)
)
.then(new OfflinePlayerArgument("target")
.replaceSuggestions(ArgumentSuggestions.strings(strings -> new String[0]))
.then(new DoubleArgument("amount", Double.MIN_VALUE)
.executesPlayer(info -> {
info.sender().sendMessage(Component.text().content("You chose " + ((OfflinePlayer) info.args().get("target")).getName() + " with value " + info.args().get("amount")));
})
)
)
.register(); From this, and from your logs it isn't apparent what would cause your issue so I also tested these commands ingame and they worked without issues. |
Oooh, actually, I think this is a very subtle vanilla bug. So, usually, literal nodes should take priority over argument nodes. In this case, that means that while However, requirements are always evaluated server-side. When the server sends the Commands to the client, it evaluates whether the player is allowed to use the So, the problem here happens because the client does not know about the literal argument, while the server always tries to use the literal I think it makes the most sense for Mojang to fix this. Unfortunately, I'm not sure if this bug affects vanilla gameplay so they might not be willing to fix it. They might not have any problems with this if they don't happen to have a command with the specific structure needed to reveal this bug, similar to the resolution of https://bugs.mojang.com/browse/MC-261429. I also don't know if Spigot would fix this. I don't think they officially support custom Brigadier commands, so their stance might be the same as Mojang's. Paper might have a good reason to fix this once PaperMC/Paper#8235 is merged, so I might bring this up with them if I can't find a good reason to bring this directly to Mojang. In the meantime, you could modify your command structure to avoid the bug. Instead of |
Still happens on 1.20.2, the command still works it's just that it says it won't work before executing. |
Wait, if this is a requirement issue, it should be enough to just resend the commands after the player has been added to that map, right? |
Yeah, if the player meets the requirements to run the I think the problem here is that when the requirement is not met, the client and server handle the command differently. I think the server shows the intended behavior, where literal arguments are preferred by default. Typing So, the vanilla bug happens when there is a literal node with an unmet requirement and an argument node in the same place. When the server receives a command using the literal, it will send back the However, the client will show that the command is valid because it thinks the input is referring to the argument node. So, I think this is a client issue that only Mojang or a client+server side mod can fix. Unfortunately, I don't think Mojang is going to fix this. There doesn't seem to be a vanilla command that has the specific structure necessary to reveal this issue. I am still looking, but even if they did fix it, they probably wouldn't backport the fix to 1.19 or any other version. Right now, I think the only way to fix the command when the requirement is not met is to change its structure to avoid the ambiguous case. The main conflict is that |
This seems to be a bug with Brigadier, as reported by Mojang/brigadier#87. That means it will probably never be fixed. The best way to approach this is probably just to avoid cases where a literal and argument may be ambiguous. |
sad |
CommandAPI version
9.20
Minecraft version
1.19
Are you shading the CommandAPI?
Yes
What I did
CommandAPI all works correctly, this is the code for the command I'm having an issue with.
What actually happened
What should have happened
Not what is portrayed in the screenshots above
Server logs and CommandAPI config
Other
No response
The text was updated successfully, but these errors were encountered: