Potential revamp of the plugin (implementations, features, cross-server compatibility,...)

[TheJoshue]

This is an idea i have in my mind, this plugin is already capable of these stuff, i am just putting here my suggestion for a revamp, both idea for new implementations and configuration example (and potentially to make developer doing this at least a second easier!)
I am not really aware how hard this is to create, but I will however explain it anyway in details

1. BungeeCord plugin jar (only used on BUNGEE/PROXY) that will act as main and only configuration place for this system.
2. Significantly smaller plugin .jar (same name, same everything, will act as bridge plugin and will not have configuration and not generate folder) that will basically be a listener I guess and will only be there for additional functionalities for spigot users, for example to check for permissions if you are having different permission managers on each subserver (or not having some permission manager connected to MySQL like LuckPerms or don't even have MySQL function for permission manager)
   3*. Additionally I would like to add that if you want to use plugin only on a standalone spigot server, then the author should make this plugin compatible for both proxy/spigot so the main jar file can be used and generates different configs on bungee and on spigot side, depending on where it's used (this can be done later, i hope this can get into bungeecord stage and later add spigot support again)

Some other improvements (suggestions) to the current state of the plugin:

• Redesigning how config is written
• Adding "permission:" to command set
• Adding names of command sets instead of priority number as name
• Adding "priority:" to command set to indicate a priority of the command set
• TAB-Completer allowing/blocking for command sets (i fully agree with Suggestion: tab blocking #2)
• Adding an option to change mode to allow/deny commands only from bungee side (anything that is executed on the subserver) called "bungee-mode:".
  When this is true, you don't need spigot extension plugin (CommandDefender jar) on bungee's subserver because "permission:" from the command set in CD will be checked if exists in any groups of a bungee's permission manager (config.yml or LuckPerms, etc...).
  However if this is false, you need spigot extension plugin (CommandDefender jar) on bungee's subserver in plugins folder and this will disable checking of "permission:" node in bungee's permission manager (assuming you actually have one), so this will check for permission of a player from LOCAL permission manager (however, permissions for each commandset are always defined in .../BungeeCordServer/plugins/CommandDefender/settings.yml).
  THIS SUGGESTION IN SHORT: Adding BungeeCord support with additional spigot functions used through extension jar file on spigot side (that don't have config)
• Adding useful guide (can be in the separate file something like "guide.txt") to explain how powerful this plugin really is!!!
  THESE ARE JUST SUGGESTIONS!!!!!

(BungeeCord only) Configuration example:
* I am editing the current default configuration but with my comments that will explain to author new features

# This is an explanation of what this plugin is capable of doing.
# (higher number has higher priority)
#
#####PART OF CONFIG
#  cmdset_one:
#    mode: DENY
#    priority: 1
#    list:
#      - '/method1'
#      - '/method2'
#  cmdset_two:
#    mode: ALLOW
#    priority: 2
#    list:
#      - '/method1 *'
#      - '/method2 specificsubcommand'
#      - '/method3'
#      - '/method4'
#  cmdset_three:
#    mode: DENY
#    priority: 3
#    list:
#      - '/method3 *'
#      - '/method4 specificsubcommand'
#####END OF CONFIG
#
# Methods of allowing/denying (sub)commands (using example part of config from above):
# 
# *Method 1: Deny core command + Allow core command only if there is any subcommand following:
#     ✘ (deny)  = "/method1"
#     ✓ (allow) = "/method1 *" (* means any)
#
# *Method 2: Deny core command + Allow core command only if there is a specific subcommand following:
#     ✘ (deny)  = "/method2"
#     ✓ (allow) = "/method2 specificsubcommand"
#
# *Method 3: Allow core command + Deny core command only if there is any subcommand following:
#     ✓ (allow) = "/method3"
#     ✘ (deny)  = "/method3 *" (* means any)
#
# *Method 4: Allow core command + Deny core command only if there is a specific subcommand following:
#     ✓ (allow) = "/method4"
#     ✘ (deny)  = "/method4 specificsubcommand"
#
########################################################################################################
# An option to change mode to allow/deny commands only from bungee side, so when this is true, you don't need spigot extension plugin (CommandDefender jar) on bungee's subserver, but you lose some functionalities like check for permission from spigot server (if you want to use local permission manager plugin)
# Input: true/false
bungee-mode: true

command-groups:

  # Name of command group set, can be any name
  cmdset_example1:

    # Allow or deny this set of commands
    # Input: DENY/ALLOW
    mode: DENY

    # Command set's priority, higher number has higher priority
    # Input: <integer>
    priority: 1

    # If you have an additional (spigot extension) CommandDefender jar plugin installed on a subserver, this permission will work for local permission manager plugin (example: PermissionsEX, GroupManager, LuckPerms without MySQL and BungeeCord jar file)
    # Optional, if the "permission:" block is not present, this command set will impact all players
    # Input: <new.permission.node>
    permission: commanddefender.commandset.Example

    # Should this set of command be allowed/denied for tab-completion?
    # If true, this will prevent everything ("/[TAB]", "/ [TAB]", "/command [TAB]") except tab-completion of playername ("/tell [TAB]" - in this case [TAB] will auto-complete only playernames)
    # If false or if this setting isn't even present, nothing related to TAB-completion won't be touched for this certain command set
    # Input: true/false
    tab-completer-block: true

    # Defined list (sub)commands for this command set
    list:
      - '/plugins'
      - '/pl'
      - '/version'
      - '/ver'
      - '/icanhasbukkit'
      - '/about'
      - '/?'

    # Deny message, can be there or not. If not present, the default deny message from language file will be used.
    deny-message:
      - '%prefix% override default message'

  cmdset_default:
    mode: ALLOW
    priority: 1
    permission: commanddefender.commandset.Default
    tab-completer: true
    list:
      - '/msg'
      - '/whisper'
      - '/home'
      - '/tpa'
      - '/spawn'

  # If a command is not allowed/blocked in the priorities above, should the command be allowed (ALLOW) or denied (DENY)?
  unlisted: DENY

  # If a command is not declared as allowed/blocked in the command sets above, should the command be displayed as TAB completion? (true = command will be displayed; false = command won't be displayed)
  # Input: true/false
  tab-completion-unlisted: true

# You can toggle whether CommandDefender checks if the user has a 'force-allow' or 'force-deny'
# permission for each command your users run here.
# Note that these permissions allow/deny only function on the command, not the arguments. e.g. you can only allow/deny
# '/island' with these permissions, you can't block individual arguments such as '/island home'. Note that each prioritised
# list can have a bypass permission though.
enable-allow-deny-permissions: true

# Block colons (:) in the first argument of commands? e.g. block /bukkit:plugins
block-colons: true

# Run the update checker on startup?
# Asynchronous (doesn't halt your server startup), will check once, and only send one warning message if an update is found.
check-for-updates: false

# Do not touch this value unless you are fully aware with what you are doing!
file-version: 2

I didn't do any changes to part under "unlisted: DENY".

Thank you for reading this!

I hope people will give more attention to this masterpiece of plugin.