Individual command per args for brushes like erode #81
Labels
Enhancement
This PR enhances an existing feature
Comments
NotMyFault
changed the title
erode, I would be in favor of leaving the choice, an individual command per arg, as well as a general command for all args.
Aurelien30000
added a commit
to Aurelien30000/FastAsyncVoxelSniper
that referenced
this issue
Aug 12, 2023
# Introduction **This is the first pass of the cloud command migration for FAVS.** There will be a second one to restore old-fashioned command syntax, tracked as IntellectualSites#81. _I have to highlight that this is my first experience with this, must-say wonderful, command system. I have spent a lot of time reading every available documentation and code piece. If @Citymonstret want to take a look and maybe give us tips to avoid "ugly" workarounds or handling, we would be glad!_ The whole pull request has been tested, not yet thoroughly, you can have a global overview, but it is not really ready. If you have any question or remark, do not hesitate! -- # General Command Management I have opted to use the annotations extension of the cloud command system. In my opinion, this is better suited to the current brush format handling which is all done inside brush classes. **Executors have been kept and brush & performer command are still handled inside their classes.** - ``Snipe`` class has been extended for a usage as a commander, because FAVS relies on a lot on this class. - ``CommandRegistry`` is the main place for the whole handling behind the scenes. Otherwise, commands are registered as usually done in cloud, with some specific annotations when needed. **``SniperCommander`` class is the commander to use with cloud command system. If the player exists, it returns its sniper. Otherwise, it returns a simple ``SniperSender``, similar to ``CommandSender``.** # Command Manager FAVS uses the paper command manager, when available, to enjoy some improvements. Falls back to bukkit command manager otherwise. - Async tab-completions are enabled if available. - ``Snipe``, ``PerformerSnipe`` & ``Toolkit`` classes are registered into the injector in order to be injected in command methods. - Command exceptions are adapted and customized with the FAVS message syntax. # Command Post-Processor FAVS requires the command post-processor ins order handle specific FAVS behavior. - Handles the ``@RequireToolkit`` annotation, makes sure the toolkit is available and the value stored. - Handles the ``@DynamicRange`` annotation, used to define a range from non-constant variables, using reflection. - Prepares the brush & performer when needed, their ``Snipe`` and stores them. # Annotations & Parser FAVS uses some annotations to facilitate development, based on common rules and behaviors. - Handles the ``@RequireToolkit`` annotation, modifies the command meta. - Handles the custom command execution method handler, which should differ for brush & performer. Cloud commands are designed to live in a class instance, this is not suitable to the current management of brush & performer. I have opted for a custom execution method which uses the brush & performer instance from the execution context instead of the base instance. _This avoid extra parameters for each command method._ # Arguments FAVS needs a lot of custom arguments for either factories, registries, custom types, custom needs, etc. **Suggestions & parsers are also declared via annotations in custom classes.** # Other Changes - All classes related to internal command managing from VS have been removed. - ``FastAsyncVoxelSniper`` class has been removed. As far as I know, this class was useless and is now for sure. - Some classes and methods have been added or refactored, but the overall codebase is the same to try keeping maximum compatibility. - Some translations have been reorganized or removed. - Some code format has been modified, there will be another pull request next year hopefully to unify comments format. - Improvements to brush properties loading. Previously, all aliases were loaded, subsequently loading the same brush several times. - Modern switch syntax has replaced old ones. - General improvements. # Known Problems: - There is currently one small issue with static/literal arguments and their aliases. Tab-completions are not handled for all aliases due to https://github.com/Incendo/cloud/blob/master/cloud-core/src/main/java/cloud/commandframework/arguments/StaticArgument.java#L134. - Brigadier extension is voluntarily not used due to some incompatibilities with FAVS commands syntax.
Aurelien30000
added a commit
to Aurelien30000/FastAsyncVoxelSniper
that referenced
this issue
Sep 3, 2023
# Introduction **This is the first pass of the cloud command migration for FAVS.** There will be a second one to restore old-fashioned command syntax, tracked as IntellectualSites#81. _I have to highlight that this is my first experience with this, must-say wonderful, command system. I have spent a lot of time reading every available documentation and code piece. If @Citymonstret want to take a look and maybe give us tips to avoid "ugly" workarounds or handling, we would be glad!_ The whole pull request has been tested, not yet thoroughly, you can have a global overview, but it is not really ready. If you have any question or remark, do not hesitate! -- # General Command Management I have opted to use the annotations extension of the cloud command system. In my opinion, this is better suited to the current brush format handling which is all done inside brush classes. **Executors have been kept and brush & performer command are still handled inside their classes.** - ``Snipe`` class has been extended for a usage as a commander, because FAVS relies on a lot on this class. - ``CommandRegistry`` is the main place for the whole handling behind the scenes. Otherwise, commands are registered as usually done in cloud, with some specific annotations when needed. **``SniperCommander`` class is the commander to use with cloud command system. If the player exists, it returns its sniper. Otherwise, it returns a simple ``SniperSender``, similar to ``CommandSender``.** # Command Manager FAVS uses the paper command manager, when available, to enjoy some improvements. Falls back to bukkit command manager otherwise. - Async tab-completions are enabled if available. - ``Snipe``, ``PerformerSnipe`` & ``Toolkit`` classes are registered into the injector in order to be injected in command methods. - Command exceptions are adapted and customized with the FAVS message syntax. # Command Post-Processor FAVS requires the command post-processor ins order handle specific FAVS behavior. - Handles the ``@RequireToolkit`` annotation, makes sure the toolkit is available and the value stored. - Handles the ``@DynamicRange`` annotation, used to define a range from non-constant variables, using reflection. - Prepares the brush & performer when needed, their ``Snipe`` and stores them. # Annotations & Parser FAVS uses some annotations to facilitate development, based on common rules and behaviors. - Handles the ``@RequireToolkit`` annotation, modifies the command meta. - Handles the custom command execution method handler, which should differ for brush & performer. Cloud commands are designed to live in a class instance, this is not suitable to the current management of brush & performer. I have opted for a custom execution method which uses the brush & performer instance from the execution context instead of the base instance. _This avoid extra parameters for each command method._ # Arguments FAVS needs a lot of custom arguments for either factories, registries, custom types, custom needs, etc. **Suggestions & parsers are also declared via annotations in custom classes.** # Other Changes - All classes related to internal command managing from VS have been removed. - ``FastAsyncVoxelSniper`` class has been removed. As far as I know, this class was useless and is now for sure. - Some classes and methods have been added or refactored, but the overall codebase is the same to try keeping maximum compatibility. - Some translations have been reorganized or removed. - Some code format has been modified, there will be another pull request next year hopefully to unify comments format. - Improvements to brush properties loading. Previously, all aliases were loaded, subsequently loading the same brush several times. - Modern switch syntax has replaced old ones. - General improvements. # Known Problems: - There is currently one small issue with static/literal arguments and their aliases. Tab-completions are not handled for all aliases due to https://github.com/Incendo/cloud/blob/master/cloud-core/src/main/java/cloud/commandframework/arguments/StaticArgument.java#L134. - Brigadier extension is voluntarily not used due to some incompatibilities with FAVS commands syntax.
Aurelien30000
added a commit
to Aurelien30000/FastAsyncVoxelSniper
that referenced
this issue
Sep 9, 2023
# Introduction **This is the first pass of the cloud command migration for FAVS.** There will be a second one to restore old-fashioned command syntax, tracked as IntellectualSites#81. _I have to highlight that this is my first experience with this, must-say wonderful, command system. I have spent a lot of time reading every available documentation and code piece. If @Citymonstret want to take a look and maybe give us tips to avoid "ugly" workarounds or handling, we would be glad!_ The whole pull request has been tested, not yet thoroughly, you can have a global overview, but it is not really ready. If you have any question or remark, do not hesitate! -- # General Command Management I have opted to use the annotations extension of the cloud command system. In my opinion, this is better suited to the current brush format handling which is all done inside brush classes. **Executors have been kept and brush & performer command are still handled inside their classes.** - ``Snipe`` class has been extended for a usage as a commander, because FAVS relies on a lot on this class. - ``CommandRegistry`` is the main place for the whole handling behind the scenes. Otherwise, commands are registered as usually done in cloud, with some specific annotations when needed. **``SniperCommander`` class is the commander to use with cloud command system. If the player exists, it returns its sniper. Otherwise, it returns a simple ``SniperSender``, similar to ``CommandSender``.** # Command Manager FAVS uses the paper command manager, when available, to enjoy some improvements. Falls back to bukkit command manager otherwise. - Async tab-completions are enabled if available. - ``Snipe``, ``PerformerSnipe`` & ``Toolkit`` classes are registered into the injector in order to be injected in command methods. - Command exceptions are adapted and customized with the FAVS message syntax. # Command Post-Processor FAVS requires the command post-processor ins order handle specific FAVS behavior. - Handles the ``@RequireToolkit`` annotation, makes sure the toolkit is available and the value stored. - Handles the ``@DynamicRange`` annotation, used to define a range from non-constant variables, using reflection. - Prepares the brush & performer when needed, their ``Snipe`` and stores them. # Annotations & Parser FAVS uses some annotations to facilitate development, based on common rules and behaviors. - Handles the ``@RequireToolkit`` annotation, modifies the command meta. - Handles the custom command execution method handler, which should differ for brush & performer. Cloud commands are designed to live in a class instance, this is not suitable to the current management of brush & performer. I have opted for a custom execution method which uses the brush & performer instance from the execution context instead of the base instance. _This avoid extra parameters for each command method._ # Arguments FAVS needs a lot of custom arguments for either factories, registries, custom types, custom needs, etc. **Suggestions & parsers are also declared via annotations in custom classes.** # Other Changes - All classes related to internal command managing from VS have been removed. - ``FastAsyncVoxelSniper`` class has been removed. As far as I know, this class was useless and is now for sure. - Some classes and methods have been added or refactored, but the overall codebase is the same to try keeping maximum compatibility. - Some translations have been reorganized or removed. - Some code format has been modified, there will be another pull request next year hopefully to unify comments format. - Improvements to brush properties loading. Previously, all aliases were loaded, subsequently loading the same brush several times. - Modern switch syntax has replaced old ones. - General improvements. # Known Problems: - There is currently one small issue with static/literal arguments and their aliases. Tab-completions are not handled for all aliases due to https://github.com/Incendo/cloud/blob/master/cloud-core/src/main/java/cloud/commandframework/arguments/StaticArgument.java#L134. - Brigadier extension is voluntarily not used due to some incompatibilities with FAVS commands syntax.
Aurelien30000
added a commit
to Aurelien30000/FastAsyncVoxelSniper
that referenced
this issue
Sep 16, 2023
# Introduction **This is the first pass of the cloud command migration for FAVS.** There will be a second one to restore old-fashioned command syntax, tracked as IntellectualSites#81. _I have to highlight that this is my first experience with this, must-say wonderful, command system. I have spent a lot of time reading every available documentation and code piece. If @Citymonstret want to take a look and maybe give us tips to avoid "ugly" workarounds or handling, we would be glad!_ The whole pull request has been tested, not yet thoroughly, you can have a global overview, but it is not really ready. If you have any question or remark, do not hesitate! -- # General Command Management I have opted to use the annotations extension of the cloud command system. In my opinion, this is better suited to the current brush format handling which is all done inside brush classes. **Executors have been kept and brush & performer command are still handled inside their classes.** - ``Snipe`` class has been extended for a usage as a commander, because FAVS relies on a lot on this class. - ``CommandRegistry`` is the main place for the whole handling behind the scenes. Otherwise, commands are registered as usually done in cloud, with some specific annotations when needed. **``SniperCommander`` class is the commander to use with cloud command system. If the player exists, it returns its sniper. Otherwise, it returns a simple ``SniperSender``, similar to ``CommandSender``.** # Command Manager FAVS uses the paper command manager, when available, to enjoy some improvements. Falls back to bukkit command manager otherwise. - Async tab-completions are enabled if available. - ``Snipe``, ``PerformerSnipe`` & ``Toolkit`` classes are registered into the injector in order to be injected in command methods. - Command exceptions are adapted and customized with the FAVS message syntax. # Command Post-Processor FAVS requires the command post-processor ins order handle specific FAVS behavior. - Handles the ``@RequireToolkit`` annotation, makes sure the toolkit is available and the value stored. - Handles the ``@DynamicRange`` annotation, used to define a range from non-constant variables, using reflection. - Prepares the brush & performer when needed, their ``Snipe`` and stores them. # Annotations & Parser FAVS uses some annotations to facilitate development, based on common rules and behaviors. - Handles the ``@RequireToolkit`` annotation, modifies the command meta. - Handles the custom command execution method handler, which should differ for brush & performer. Cloud commands are designed to live in a class instance, this is not suitable to the current management of brush & performer. I have opted for a custom execution method which uses the brush & performer instance from the execution context instead of the base instance. _This avoid extra parameters for each command method._ # Arguments FAVS needs a lot of custom arguments for either factories, registries, custom types, custom needs, etc. **Suggestions & parsers are also declared via annotations in custom classes.** # Other Changes - All classes related to internal command managing from VS have been removed. - ``FastAsyncVoxelSniper`` class has been removed. As far as I know, this class was useless and is now for sure. - Some classes and methods have been added or refactored, but the overall codebase is the same to try keeping maximum compatibility. - Some translations have been reorganized or removed. - Some code format has been modified, there will be another pull request next year hopefully to unify comments format. - Improvements to brush properties loading. Previously, all aliases were loaded, subsequently loading the same brush several times. - Modern switch syntax has replaced old ones. - General improvements. # Known Problems: - There is currently one small issue with static/literal arguments and their aliases. Tab-completions are not handled for all aliases due to https://github.com/Incendo/cloud/blob/master/cloud-core/src/main/java/cloud/commandframework/arguments/StaticArgument.java#L134. - Brigadier extension is voluntarily not used due to some incompatibilities with FAVS commands syntax.
Aurelien30000
added a commit
to Aurelien30000/FastAsyncVoxelSniper
that referenced
this issue
Oct 15, 2023
# Introduction **This is the first pass of the cloud command migration for FAVS.** There will be a second one to restore old-fashioned command syntax, tracked as IntellectualSites#81. _I have to highlight that this is my first experience with this, must-say wonderful, command system. I have spent a lot of time reading every available documentation and code piece. If @Citymonstret want to take a look and maybe give us tips to avoid "ugly" workarounds or handling, we would be glad!_ The whole pull request has been tested, not yet thoroughly, you can have a global overview, but it is not really ready. If you have any question or remark, do not hesitate! -- # General Command Management I have opted to use the annotations extension of the cloud command system. In my opinion, this is better suited to the current brush format handling which is all done inside brush classes. **Executors have been kept and brush & performer command are still handled inside their classes.** - ``Snipe`` class has been extended for a usage as a commander, because FAVS relies on a lot on this class. - ``CommandRegistry`` is the main place for the whole handling behind the scenes. Otherwise, commands are registered as usually done in cloud, with some specific annotations when needed. **``SniperCommander`` class is the commander to use with cloud command system. If the player exists, it returns its sniper. Otherwise, it returns a simple ``SniperSender``, similar to ``CommandSender``.** # Command Manager FAVS uses the paper command manager, when available, to enjoy some improvements. Falls back to bukkit command manager otherwise. - Async tab-completions are enabled if available. - ``Snipe``, ``PerformerSnipe`` & ``Toolkit`` classes are registered into the injector in order to be injected in command methods. - Command exceptions are adapted and customized with the FAVS message syntax. # Command Post-Processor FAVS requires the command post-processor ins order handle specific FAVS behavior. - Handles the ``@RequireToolkit`` annotation, makes sure the toolkit is available and the value stored. - Handles the ``@DynamicRange`` annotation, used to define a range from non-constant variables, using reflection. - Prepares the brush & performer when needed, their ``Snipe`` and stores them. # Annotations & Parser FAVS uses some annotations to facilitate development, based on common rules and behaviors. - Handles the ``@RequireToolkit`` annotation, modifies the command meta. - Handles the custom command execution method handler, which should differ for brush & performer. Cloud commands are designed to live in a class instance, this is not suitable to the current management of brush & performer. I have opted for a custom execution method which uses the brush & performer instance from the execution context instead of the base instance. _This avoid extra parameters for each command method._ # Arguments FAVS needs a lot of custom arguments for either factories, registries, custom types, custom needs, etc. **Suggestions & parsers are also declared via annotations in custom classes.** # Other Changes - All classes related to internal command managing from VS have been removed. - ``FastAsyncVoxelSniper`` class has been removed. As far as I know, this class was useless and is now for sure. - Some classes and methods have been added or refactored, but the overall codebase is the same to try keeping maximum compatibility. - Some translations have been reorganized or removed. - Some code format has been modified, there will be another pull request next year hopefully to unify comments format. - Improvements to brush properties loading. Previously, all aliases were loaded, subsequently loading the same brush several times. - Modern switch syntax has replaced old ones. - General improvements. # Known Problems: - There is currently one small issue with static/literal arguments and their aliases. Tab-completions are not handled for all aliases due to https://github.com/Incendo/cloud/blob/master/cloud-core/src/main/java/cloud/commandframework/arguments/StaticArgument.java#L134. - Brigadier extension is voluntarily not used due to some incompatibilities with FAVS commands syntax.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Idea from @JayemCeekay: For some brushes like
erode, I would be in favor of leaving the choice, an individual command per arg, as well as a general command for all args.- Should be addressed when switching to cloud.
Originally posted by @Aurelien30000 in #52 (comment)
The text was updated successfully, but these errors were encountered: