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

Signed commands support #381

Open
demkom58 opened this issue Dec 17, 2022 · 5 comments
Open

Signed commands support #381

demkom58 opened this issue Dec 17, 2022 · 5 comments
Assignees
Labels
enhancement New feature or request future idea An idea that won't be worked on yet, but may in the future
Milestone

Comments

@demkom58
Copy link

demkom58 commented Dec 17, 2022

Description

It would be nice to see an API for working with signed commands.

It also looks like Adventure in version 4.12 has the required API for this. FYI: SignedMessage.java

Motivation

In Minecraft, there are commands that allow you to write in private messages, as far as I understand, the command arguments are signed (FYI: Protocol#Chat_Command). For any use case that accepts player input and outputs, this would be a useful feature.

The first use case that comes to mind is message channels: global, local, etc.

Expected code

new CommandAPICommand(commandName)
     .withArguments(new AdventureSignedMessageArgument("message"))
     .executesPlayer((player, args) -> {
          final SignedMessage message = (SignedMessage) args[0];
          player.sendMessage(message, ChatType.CHAT.bind(Component.text("local")));
     }).register();

Extra details

No response

@demkom58 demkom58 added the enhancement New feature or request label Dec 17, 2022
@JorelAli
Copy link
Owner

Care to elaborate a bit more about signed commands? This is really vague.

  • What features would you expect the CommandAPI to have to implement signed commands?
  • What would the API to interact with signed commands look like in code (or pseudocode)?

@demkom58
Copy link
Author

I did as you ask, but I think there is some space for exploration and it may not end up looking like this.

@JorelAli
Copy link
Owner

@demkom58 Thanks very much! This is actually really helpful. I think making something like this will be pretty possible.

Scheduling for 9.0.0.

@JorelAli JorelAli added this to the 9.0.0 milestone Dec 21, 2022
@JorelAli JorelAli added the scheduled for next release This will be implemented for the next public release label Dec 21, 2022
@JorelAli
Copy link
Owner

JorelAli commented Dec 23, 2022

Currently implemented on the dev/signed-arguments branch for 9.0.0. I've added an AdventureSignedMessageArgument which can return a SignedMessage object.

This is only compatible with Paper 1.19.3 onwards (Paper 1.19.2 and below doesn't have Adventure 4.12.0).


Adventure API's support for signed arguments is really not that well fleshed out (yet?) and has a lot of limitations other than providing an API for inspection purposes for command arguments. Apparently, player chat has a very strict lifecycle which may not be able to persist long enough to send signed player messages (but this is just conjecture). After briefly browsing the Adventure Discord Server, the API can only create system signed messages.

Based on current developments in Paper, it seems that sending SignedMessage support is still actively in development.

The CommandAPI will need an example to demonstrate how to use signed messages. I'm sure that in time, Adventure and Paper will figure out how to make a useful API for SignedMessages, but at the moment I can't recommend the above example:

new CommandAPICommand(commandName)
     .withArguments(new AdventureSignedMessageArgument("message"))
     .executesPlayer((player, args) -> {
          final SignedMessage message = (SignedMessage) args[0];
          player.sendMessage(message, ChatType.CHAT.bind(Component.text("local"))); // <<--[HERE]
     }).register();

At the time of writing, the Audience#sendMessage(SignedMessage, Bound) method looks really half-implemented - its bound parameter isn't used (and is explicitly stated to be non-null), so I have no idea what it's doing.

@JorelAli JorelAli self-assigned this Jan 22, 2023
@JorelAli JorelAli removed the scheduled for next release This will be implemented for the next public release label May 10, 2023
@JorelAli
Copy link
Owner

Unscheduling this request for the next release. This functionality seems to be still very early in development and doesn't have any meaningful use cases yet.

@JorelAli JorelAli added the future idea An idea that won't be worked on yet, but may in the future label Jun 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request future idea An idea that won't be worked on yet, but may in the future
Projects
Archived in project
Development

When branches are created from issues, their pull requests are automatically linked.

2 participants