Skip to content
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

Dynamically Updated MultiLiteral Argument #513

Open
CollidaCube opened this issue Dec 26, 2023 · 2 comments · May be fixed by #602
Open

Dynamically Updated MultiLiteral Argument #513

CollidaCube opened this issue Dec 26, 2023 · 2 comments · May be fixed by #602
Labels
enhancement New feature or request

Comments

@CollidaCube
Copy link

Description

Currently, with StringArgument, you can provide a list of suggestions dynamically for the player to chose from using .replaceSuggestions(...) but it will really accept any token. There is also MultiLiteralArgument which has a hard-coded list of accepted values and considers any other token invalid. I would like to see an in-between where you can dynamically provide a list of accepted values and the argument will mark any other token as invalid.

Expected code

// Optimally, I imagine this
// Variation 1:

new MultiLiteralArgument("messageId").replaceSuggestions(
        ArgumentSuggestions.stringCollection(info -> EconomyManager.getAllEconomyIds())
);

// Variation 2:

new MultiLiteralArgument("messageId", ArgumentSuggestions.stringCollection(info -> EconomyManager.getAllEconomyIds()));

// This could work too

new StringArgument("messageId")
        .replaceSuggestions(
                ArgumentSuggestions.stringCollection(info -> EconomyManager.getAllEconomyIds())
                        .withRequirement(args -> args.suggestions().contains(args.currentArg()))
        );

// Or a new argument altogether

new DynamicallyUpdatedLiteralArgument("messageId").replaceSuggestions(...);

Extra details

No response

@CollidaCube CollidaCube added the enhancement New feature or request label Dec 26, 2023
@JorelAli
Copy link
Owner

This is a limitation of Brigadier.

The MultiLiteralArgument is syntactic sugar for a collection of LiteralArgument objects, which each use an underlying Brigadier LiteralCommandNode which can accept a string literal of your choice (consisting of any sequence of characters). This list of literals is sent from your Minecraft server to your client upon login, or whenever updated (e.g. player.updateCommands()). Because the list is sent to the client, the client can validate these client-side.

The StringArgument is a simple Brigadier StringTypeArgument with suggestions. These suggestions are sent from the server to the player while the player is typing the command - they're not used for validation, but they provide a "close enough" approximation to what you're trying to achieve. Suggestions can be validated server-side (e.g. in your .executes() method) if your input must conform to a specific set of values.

It's not possible to create a dynamically changing list of suggestions without restructing the command tree during the running of the server and updating the player's list of commands which is not something that we can do easily or quickly on a per-player basis.

@JorelAli JorelAli closed this as not planned Won't fix, can't repro, duplicate, stale Apr 30, 2024
willkroboth added a commit that referenced this issue Jun 20, 2024
Acts like `MultiLiteralArgument`, but literals can be changed and differ for each CommandSender

Resolves #513

Uses Paper's `AsyncPlayerSendCommandsEvent` and Velocity's `PlayerAvailableCommandsEvent` to change the client's view of the command tree. Note that a similar event does not exist on Spigot, so the suggestions are not dynamic, though the parsing still is.

`DifferentClientNode` class added to handle creating client-server command tree de-syncs (I believe this can be used to make `FlagsArgument` platform-agnostic)
@willkroboth
Copy link
Collaborator

An experimental implementation of this idea is present on the dev/command-build-rewrite branch 83ee2cf. I'm reopening this issue for tracking.

@willkroboth willkroboth reopened this Jun 20, 2024
willkroboth added a commit that referenced this issue Jul 4, 2024
Acts like `MultiLiteralArgument`, but literals can be changed and differ for each CommandSender

Resolves #513

Uses Paper's `AsyncPlayerSendCommandsEvent` and Velocity's `PlayerAvailableCommandsEvent` to change the client's view of the command tree. Note that a similar event does not exist on Spigot, so the suggestions are not dynamic, though the parsing still is.

`DifferentClientNode` class added to handle creating client-server command tree de-syncs (I believe this can be used to make `FlagsArgument` platform-agnostic)
willkroboth added a commit that referenced this issue Aug 15, 2024
Acts like `MultiLiteralArgument`, but literals can be changed and differ for each CommandSender

Resolves #513

Uses Paper's `AsyncPlayerSendCommandsEvent` and Velocity's `PlayerAvailableCommandsEvent` to change the client's view of the command tree. Note that a similar event does not exist on Spigot, so the suggestions are not dynamic, though the parsing still is.

`DifferentClientNode` class added to handle creating client-server command tree de-syncs (I believe this can be used to make `FlagsArgument` platform-agnostic)
willkroboth added a commit that referenced this issue Sep 1, 2024
Acts like `MultiLiteralArgument`, but literals can be changed and differ for each CommandSender

Resolves #513

Uses Paper's `AsyncPlayerSendCommandsEvent` and Velocity's `PlayerAvailableCommandsEvent` to change the client's view of the command tree. Note that a similar event does not exist on Spigot, so the suggestions are not dynamic, though the parsing still is.

`DifferentClientNode` class added to handle creating client-server command tree de-syncs (I believe this can be used to make `FlagsArgument` platform-agnostic)
@willkroboth willkroboth linked a pull request Sep 3, 2024 that will close this issue
5 tasks
@willkroboth willkroboth linked a pull request Sep 3, 2024 that will close this issue
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants