JorelAli / CommandAPI

A Bukkit/Spigot API for the command UI introduced in Minecraft 1.13

Home Page:https://commandapi.jorel.dev

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Suggestions filtering for namespaced keys and locations when replacing suggestions works differently

willkroboth opened this issue · comments

CommandAPI version

9.0.4

Minecraft version

1.20.1

Are you shading the CommandAPI?

Yes

What I did

This issue was originally reported by Zoom on the CommandAPI discord. For additional context, see this thread.

Register these commands:

@Override
public void onEnable() {
    CommandAPI.onEnable();
    
    new CommandAPICommand("enchantment")
            .withArguments(new EnchantmentArgument("enchantment"))
            .executes(this::sendArg)
            .register();
    
    new CommandAPICommand("enchantmentSuggestions")
            .withArguments(
                    new EnchantmentArgument("enchantment")
                            .replaceSafeSuggestions(SafeSuggestions.suggest(
                                    Enchantment.WATER_WORKER
                            ))
            )
            .executes(this::sendArg)
            .register();
    
    new CommandAPICommand("location")
            .withArguments(new LocationArgument("location"))
            .executes(this::sendArg)
            .register();
    
    new CommandAPICommand("locationSuggestions")
            .withArguments(
                    new LocationArgument("location")
                            .replaceSafeSuggestions(SafeSuggestions.suggest(
                                    new Location(null, 0, 0, 0)
                            ))
            )
            .executes(this::sendArg)
            .register();
}

private void sendArg(CommandSender sender, CommandArguments arguments) {
    sender.sendMessage(arguments.get(0).toString());
}

What actually happened

When using the default Enchantment suggestions (/enchantment), typing aq suggests minecraft:aqua_affinity:

Enchantment normal

However, when the suggestions are replaced with just minecraft:aqua_affinity (/enchantmentsuggestions), typing aq does not suggest anything:

Enchantment suggestions Enchantment missing

When using the default Location suggestions (/location), after typing the first value, the next values for the original suggestion are included:

(Trying to suggest 25.05 71.00 -8.43)
Location normal

(71.00 and -8.43 are still being suggested even though 25.05 was not input)
Location normal 2

However, when the suggestions are replaced, the suggestion is only kept if the first value was exactly what was suggested:

(Trying to suggest 0.0 0.0 0.0)
Location suggestions

(Suggestions continue, 0.0 == 0.0)
Location suggestions 2

(No suggestions are given, 10 != 0)
Location missing

(No suggestions are given, "0" != "0.0")
Location missing 2

Similar things happen for Location2D, and other arguments that input a namespaced key.

What should have happened

The vanilla behavior is excepted to happen.

Typing /enchantmentsuggestions aq is expected to suggest minecraft:aqua_affinity.

Typing /locationsuggestions 10 is expected to suggest 10 0.0 0.0.

Server logs and CommandAPI config

No response

Other

When ArgumentSuggestions suggests each String, it uses this shouldSuggest method to decide if each suggestion should be added:

private static boolean shouldSuggest(SuggestionsBuilder builder, String suggestion) {
return suggestion.toLowerCase(Locale.ROOT).startsWith(builder.getRemaining().toLowerCase(Locale.ROOT));
}

This is just a simple startsWith check, which makes sense most of the time. If the suggestions are ArgumentSuggestions.strings("alpha", "beta", "bear"), and the input is be, only the suggestions that start with the input should be suggested: ["beta", "bear"].

However, when Vanilla suggests world locations and resource locations, it uses special logic in net.minecraft.commands.SharedSuggestionProvider. This uses slightly more logic than just startsWith to produce the behavior seen when the CommandAPI does not replace the suggestions.

image

Instead of relying on ArgumentSuggestions#shouldSuggest, Arguments that use locations or namespaced keys could probably hook into SharedSuggestionProvider's logic.