Some fixes for commands #3262
Merged
Some fixes for commands #3262
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dualspiral
approved these changes
Jan 29, 2021
| }); | ||
| SpongeParameterizedCommandRegistrar.INSTANCE.register( | ||
|
|
||
| // TODO: this used to be done after the event, do we care? |
There was a problem hiding this comment.
It doesn't matter. Callbacks in Sponge should be calling sponge:callback anyway, so as long as that registers, it should be fine.
| @@ -90,7 +90,7 @@ public SpongeParameterValueBuilder(@NonNull final Type token) { | |||
| @Override | |||
| public Parameter.Value.@NonNull Builder<T> setRequiredPermission(@Nullable final String permission) { | |||
| if (permission == null) { | |||
| return this.setUsage(null); | |||
| return this.setRequirements(null); | |||
| public TypeToken<LiteralArgumentBuilder<CommandSource>> handledType() { | ||
| return BrigadierCommandRegistrar.COMMAND_TYPE; | ||
| public @NonNull CommandRegistrarType<LiteralArgumentBuilder<CommandSource>> type() { | ||
| return TYPE; |
There was a problem hiding this comment.
To do a @Zidane - this should be BrigadierCommandRegistrar.TYPE, fully qualifying all static access, even if in the same class.
| public TypeToken<Command.Parameterized> handledType() { | ||
| return SpongeParameterizedCommandRegistrar.COMMAND_TYPE; | ||
| public @NonNull CommandRegistrarType<Command.Parameterized> type() { | ||
| return TYPE; |
| public TypeToken<Command.@NonNull Raw> handledType() { | ||
| return SpongeRawCommandRegistrar.COMMAND_TYPE; | ||
| public @NonNull CommandRegistrarType<Command.Raw> type() { | ||
| return TYPE; |
zml2008
force-pushed
the
feature/commands-tweaks
branch
from
153d6af
to
a8b5d2d
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
SpongeAPI | Sponge
This fixes some minor issues with commands, from things that came up in Discord and a few things that I noticed while reading through the implementation.
I'd still like to look at:
The function loading changes in 1.16 have meant that commands are initialized extremely early, and are re-initialized on every datapack reload. I'm thinking it'll probably make sense to convert the dispatcher registry into a dispatcher factory registry, and match the Mojang datapack lifecycle more closely with our registration sequence. Since Mojang's strategy is to fully register commands and load datapacks with the new set of commands before applying those commands to the active server, I think we'll want to just re-register commands on a whole new dispatcher, and remove all the singletons used.
ArgumentReadertoRawcommands rather than just a plain StringThis seems like the closest we can get to allowing custom commands systems to match vanilla behaviour without binding them to constructing their own
Parameterizedcommands. Unfortunately, I thinkCommandContexttakes in too much detail specific to parameterized/Brigadier commands for it to be exposed to raw commands without major design changes. I think theArgumentReadercan also expose enough low-level parsing to easily cover converting everything that is aClientCompletionType