NamespacedKeyArgument does not work in 1.17
BeefDev opened this issue · 3 comments
CommandAPI version
8.5.0
Minecraft version
1.17
Are you shading the CommandAPI?
Yes
What I did
Register this command
private CommandAPICommand nameSpacedKeyCommand() {
return new CommandAPICommand("printkey")
.withArguments(new NamespacedKeyArgument("key"))
.executesPlayer((player, arguments) -> {
NamespacedKey key = (NamespacedKey) arguments[0];
player.sendMessage(ChatColor.RED + "Namespace: " + ChatColor.YELLOW + key.getNamespace());
player.sendMessage(ChatColor.RED + "Key: " + ChatColor.YELLOW + key.getKey());
});
}Run the command /printkey mynamespaced:mykey
What actually happened
A NoSuchMethodError was thrown
(Speciffically the error happens on commandapi.nms.NMS_Common.getMinecraftKey(NMS_Common.java:416), because there is no
MinecraftKey ArgumentMinecraftKeyRegistered.e(CommandContext, String)
method.
What should have happened
The command executes normally, and the namespace & key are sent to the player as messages
Server logs and CommandAPI config
Don't think it will be much of a use, but here:
on load
[11:55:27 INFO]: [CommandAPI] Hooked into NMS io.github.beefdev.commandapireports.dependencies.commandapi.nms.NMS_1_17_R1 (compatible with 1.17.1)
[11:55:27 WARN]: [CommandAPI] Could not hook into the NBT API for NBT support. Download it from https://www.spigotmc.org/resources/nbt-api.7939/
[11:55:27 INFO]: [CommandAPI] Hooked into Spigot successfully for Chat/ChatComponents
[11:55:27 INFO]: [CommandAPI] Hooked into Adventure for AdventureChat/AdventureChatComponents
[11:55:27 INFO]: [CommandAPI] Hooked into Paper for paper-specific API implementations
on enable
[11:55:36 INFO]: [CommandAPI] Registering command /printkey key<NamespacedKeyArgument>
...
[11:55:39 INFO]: [CommandAPI] Linking permissions to commands:
[11:55:39 INFO]: [CommandAPI] NONE -> /printkey
[11:55:39 INFO]: [CommandAPI] Linked 1 Bukkit permissions to commands
[11:55:39 INFO]: [CommandAPI] Reloading datapacks...
Other
No response
This looks similar to the problem solved by #304, where the data packs reload failed on a 1.17 server due to special source mapping a field to slightly different values between 1.17 and 1.17.1. Luckily the framework for splitting 1.17 and 1.17.1 NMS is already in place thanks to that PR, so this should be fixed easily.
EDIT:
I noticed that this is actually a problem with a method from NMS_Common, which handles shared code for 1.17 to 1.19. The resolution should work mostly the same, just move the problematic method call from NMS common down to 1.17 common or whatever works.
This looks similar to the problem solved by #304, where the data packs reload failed on a 1.17 server due to special source mapping a field to slightly different values between 1.17 and 1.17.1. Luckily the framework for splitting 1.17 and 1.17.1 NMS is already in place thanks to that PR, so this should be fixed easily.
Ok, thanks for informing me