fixeddev / command-flow

A flexible and platform-agnostic command framework for Java 8+

command-flow

A flexible command framework which removes lots of boilerplate code used in commands

Check the documentation for installation and usage information for this project

command-flow's Issues

Don't convert from adventure's `Component` to BungeeCord chat `BaseComponent[]` on Paper

(commandflow-bukkit)
Paper supports sending adventure Component messages natively.

Maybe add an interface like:

interface ComponentSender {
    void sendMessage(Player player, Component component);
}

And create a Paper implementation:

class PaperComponentSender implements ComponentSender {
    @Override
    public void sendMessage(Player player, Component component) {
        player.sendMessage(component); // Paper method 
    }
}

And if we are not on Paper, fall back to an implementation that converts components to bungeecord-chat base components.

https://github.com/unnamed/command-flow/blob/master/Bukkit/src/main/java/me/fixeddev/commandflow/bukkit/BukkitCommandWrapper.java#L105

Create `AnnotatedCommandTreeBuilder` factory that accepts `PartInjector` and `SubCommandInstanceCreator`

Make `AnnotatedCommandTreeBuilder` accept a function to convert annotation strings to Components

Currently the fromString method is private and always outputs either a TranslatableComponent or a TextComponent, it would be nice if it could accept a converter function.

https://github.com/unnamed/command-flow/blob/f3723639e1177474c9edcbabaffd27e73a5f7176/Universal/src/main/java/me/fixeddev/commandflow/annotated/AnnotatedCommandTreeBuilderImpl.java#L217

Example use cases: libraries like MiniMessage and MineDown(adventure?) allow converting strings to components and it would be nice to support them from the annotations.

Note that MiniMessage also supports using translatable components like: <lang:some.translation.key>, similar to the current implementation which accepts %translatable:some.translation.key%, which is limited (can't add text before or after)

`commandflow-discord` should use Application commands

commandflow-discord currently uses messages to detect commands. We should use Application Commands instead since it's a more user-friendly and native way to create bot commands.

Also, bots can't read message contents without a privileged intent

Problems trying to install with maven

Hello! I really liked your command manager, and I wanted to try to use it, but when I want to use it with maven I get several errors, I have everything set, as the read.me says, the library is still running or something I'm doing wrong ?, I await your answer, thanks for reading

ArgumentPart suggestions

Well, I think there's a issue with part suggestions in sub-commands, if we have a empty parent sub-command then the next argument position wouldn't be suggested correctly.

There is an example, as you can see we have a empty parent with a custom part called 'Bank'. Suggestions of that part aren't being suggested, but this issue only occurs with the empty parent.

BREAKING: Move from `me.fixeddev` to `team.unnamed`

Maybe for 1.0.0?

Wiki or enhanced README

Hey,
this repo seems to be a nice framework.
Could you provide the concept or some general usage examples?

Greetings
Paul

Replace text with adventure

The library used by the project for message components has had a major api update and a project rename (text -> adventure).
As adventure has become the de facto standard in minecraft development, switching to the new version would increase compatibility and usability by a lot. (Paper and Velocity for example, both use adventure natively).

Rename `master` to `main`

https://github.com/github/renaming

Text-api conflict with other plugins

Every time i try to load a plugin that uses text-api,
CommandFlow throws a IllegalAccessError:

• https://paste.md-5.net/ujomemaxob.coffeescript

but it disappears if i remove any of the conflicting plugins.

Make `Translator#setConverterFunction` use `Component` instead of `TextComponent`

Translator#setConverterFunction takes a Function<String, TextComponent> as parameter, I think it should be Function<String, Component>.

The DefaultTranslator also ignores it being a TextComponent:

/* 77 */     Component newComponent = stringToComponent.apply(trans);

Add tab-completion for Flags and Switches

Tab-Completion for Flags and Switches are a useful feature for advanced commands, but are still left out quite often because of implementation difficulties.

Suggestions should switch to flags/switches as soon as the user types the '-' symbol. All the available flag/switch names should be listed then. When a flag is chosen, the completion should switch be handled by the Part again. If it's a switch, it should just switch back to normal completion.