Command Kits v1.2.0 | Kits of Commands and Items!

#About:
Command Kits is a simple yet flexible kit plugin. Groups of commands and items called “kits” can be defined in the plugin config file. Players can then execute these kits all at once with one command. Requirements can also be set on the kits to only allow players to execute them under certain circumstances.

#Downloads:
You can grab the latest build off of GitHub here!

#Github Repository:
You can view the GitHub repository of Command Kits here!

#Commands:
/ck - Attempts to execute the Command Kit with the specified kitName. (Aliases: ck, commandKits)
/ck pluginInfo - Displays version information about the Command Kits Plugin.
/ck list - Lists available command kits, kits for which the player does not have permission will not be displayed. Kits which the player meets the requirements for will be displayed in GREEN, kits which the player does not meet the requirments for will be displayed in RED.
/ck info - Displays the description of the kit with the name kitName, as well of any requirements it may have. Requirements which the player meets will be displayed in GREEN, requirements which the player does not meet will be displayed in RED. If the player meets all requirments the border of the display will be GREEN, otherwise it will be RED.
/ck reload - Reloads the configuration file for Command Kits
#Permissions
commandKits.command.select
commandKits.command.pluginInfo
commandKits.command.list
commandKits.command.kitInfo
commandKits.command.reloadConfig

#Defining a Simple Kit:
So you may be wondering what the point of this plugin is or how it works. At the core of Command Kits is the concept of a “kit”, while this is similar to kits from other kit plugins instead of holding just items, these kits can also hold commands. In order to define a “kit” simply create an entry in the kits section of the config like so:

kits {
    Test {
        description="This is an example kit"
        interval=30
        message="&9You used the example kit!&f"
        name=Example
    }
}

Kits consist of a key for the section (Test), a name (Example), a description (This is an example kit), a message (&9You used the example kit!&f) and an interval (30) All of these fields are optional except key and name.

  • key - used solely for your organizational purposes, it can be named what you wish
  • name - this is what players will used to access the kit within commands
  • description - this is what will be returned to players when they call /ck info on this kit
  • message - this is what will be sent to the player upon executing the kit, supports all normal Minecraft format codes in ampersand (&) format.
  • interval - time in seconds until the player can use this kit again.
    ##The Meat - Commands
    Kits can also have an optional commands section, which commands that will be executed when this kit is run with the /ck command, by defualt they will be executed by the player.

For example below is a kit with a simple command section:

kits {
    Test {
        commands=[
            "minecraft:me I used the example kit!",
            "minecraft:me It was really fun"
        ]
        name=Example
    }
}    

“Zerthick, this is all well and good, but what happens if the commands I want to execute need to be executed from the console, or take arguments?”
Well, I’m glad you asked! In order to execute a command from the console instead of the player simply prefix a command with a ‘$’. So for example in order to execute the time set day command from the console I could add the following command to the commands section of a kit:

"$minecraft:time set day"

“So what about arguments then?”
Now we get into some of the fun stuff, the drop-in system. The way the drop-in system works is by defining several “drop-ins” that will be inserted into the command at run-time, for example one such drop-in is PLAYER_NAME. In order to use drop-ins simply enclose the requested drop-in in curly-braces like so:

"$minecraft:tell {PLAYER_NAME} Hello!"

This will make the console tell whatever player executed this kit “Hello!” Some available drop-ins include:

  • PLAYER_NAME
  • PLAYER_UUID
  • WORLD_NAME
  • WORLD_UUID

But that’s not all! In addition to those predefined drop-ins, you can also access most of the player-supported data keys found in the Keys Enum. (I plan to support them all once Player.getKeys() doesn’t throw an AbstractMethodError :stuck_out_tongue_winking_eye:). These are accessed like normal dropn-ins, except whatever key you wish to access must be prefixed by KEYS_. So for example let’s say we wanted to double the amount of xp levels a player has, we could do so with the following command

"$minecraft:xp {KEYS_EXPERIENCE_LEVEL}L {PLAYER_NAME}"

As of Command Kits v0.2.1 you can also access arguments passed in by the player!

Arguments can be passed in after the kit name. Example: /ck <kitName> [arg1] [arg2] ...
You can access these arguments in your commands via the ARGS_ drop-in type
For example to access the first argument in a command simply append the index 1 to the drop-in {ARGS_1}
If you simply want to insert all arguments in a drop-in (ex: for a message input) you can use {ARGS_*}
You can also specify ranges of args to insert, for example 1 to 3 {ARGS_1-3}
If you want to specify a starting index, but include all args after it we can also use *, for example all arguments from 2 forward {ARGS_2-*}
Similarly if we wanted all arguments up to and including the 2nd one we could use {ARGS_*-2}

As of Command Kits v0.3.1 you can now also check to see if a player has a particular permission with the PERM_ drop-in type. For example to check if the player has the permission some.permission.example we can simply append the permission name to the drop-in like so {PERM_some.permission.example}, this will evaluate to true if the player has the permission or false if the player doesn’t have the permission.

##The Potatoes - Requirements
“Zerthick, didn’t you say something about requirements earlier, where are those?”
Now we get to the other half of Command Kits, requirements.

In addition to the three sections mentioned earlier, kits can have an optional requirements section, where each condition in the section must be true in order for the player to execute the command. The most basic requirement is a permission, for example:

kits {
    Example {
        commands=[
            "minecraft:me I used the example kit!",
            "$minecraft:tell {PLAYER_NAME} You used the example kit!"
        ]
        description="This is an example kit"
        name=Example
        requirements {
            permission="commandKits.example"
        }
    }
}

This kit will only be able to be executed by a player with the permission commandKits.example, in addition, if a player does not have permission to use a kit, they will not be able to call /ck info on that kit, nor will it be visible when they call /ck list.

“What about drop-ins, do they have a role to play here to?”
Yes! Any piece of data accessed via a drop-in can also be used as a requirement for a kit. As of command kits v0.3.1, requirements other than the basic permission requirement are specified as an advanced requirement section.
For example:

requirements {
    Test {
        # Description of requirement
        description="This requirement specifies that the player must have at least 5 enchanting levels to use this kit."
        # Human-friendly name for requirement
        name="Example Requirement"
        rule="{KEYS_EXPERIENCE_LEVEL} >= 5"
    }
    # This is the permission required to run /kc on this kit
    permission="commandKits.example"
}

Every advanced requirement consists of a key for the section (Test), a name (Example Requirement), a description (This requirement specifies that the player must have at least 5 enchanting levels to use this kit.), and a rule ({KEYS_EXPERIENCE_LEVEL} >= 5).

  • key - used solely for your organizational purposes, it can be named what you wish
  • name - the name of the requirement, will be displayed in the /ck info command
  • description - human-friendly description of the requirement, will be displayed in the /ck info command
  • rule - this rule, expressed as a boolean expression (i.e. either true or false), will be used to evaluate if the requirement is met by the player

''Hold up a minute Zerthick, you’re saying we can express requirements as a boolean expression?"
YES! This is the big feature of Command Kits v0.3.1, for values representing numbers the following operations are supported +, -, *, /, %, <, >, <=, >=, ==, !=. All numbers are evaluated as doubles when performing addition, subtraction, multiplication, division, and modulo division! Strings are denoted encased in single quotes ex: 'This is a String' and support the following operations ==, !=, +(concatenation). The following boolean operations are also available &&(and), ||(or), !(not)

There are two requirements when writing rule expressions

1. Rules must evaluate to either true or false
2. All tokens in rules must be separated by spaces

The first requirement is so that Command Kits can determine whether or not the player has a requirement, the second is because I need to improve my regex skills :wink:.

Examples:
rule="3 + 4" fails Requirement 1: 3 + 4 = 5 not true or false
rule="3+4<5" fails Requirement 2: tokens not separated by spaces
rule="3 + 4 < 5" valid, tokens are separated by spaces and evaluates to either true or false, in this case false.

So for example, say we have are requirement that in order to use a kit a player must have a permission “mykit.use”, be in a world named “MyWorld”, and either be flying or have at least 30 levels of exp. Then we could have the following requirements section:

requirements {
    MyWorldFlyingExp {
        description="You must be in MyWorld and have either 30 levels of xp or be flying"
        name="MyWorld: Flying or 30 Exp Levles"
        rule="{WORLD_NAME} == 'MyWorld' && ( {KEYS_IS_FLYING} == true || {KEYS_EXPERIENCE_LEVEL} >= 30 )"
    }
    permission="mykit.use"
}

You can specify as many different advanced requirements as you like, but they must all be true in order for a player to use a kit!
##Vanilla Minecraft and Beyond!
As you have seen, all of my examples use vanilla Minecraft commands, but the beauty of Command Kits is that it will work with any plugin that supports player commands, so long as you can define appropriate arguments for them. Have a spell plugin that uses commands, but only want you players to be able to cast spells in a certain world or with a certain level of exp? Bind the spell to a Command Kit! Or say you have a whole bunch of plugins and whenever you have to accomplish a task you type in the same series of commands over and over, bind the sequence to a command kit and knock it out all with one command!

##The Dessert - Items:
As of Command Kits v1.0.0 kits can now have an optional items section, which will specify items to be given to the player upon executing the kit. Now you can have all the power of the requirements system for all your everyday Minecraft kit needs! For Example:

kits {
    Test {
        items=[
            "minecraft:stone 5",
            "minecraft:diamond {KEYS_EXPERIENCE_LEVEL}"
        ]
        name=Example
    }
}

The format of items is simply the item name Ex: minecraft:stone followed by an integer amount Ex: 5
You can also specify any integer drop-in as the amount as well, for example the above kit would give the player the number of diamonds equal to their experience level!

#Suggestions
If you’ve made it this far, thank you for reading about Command Kits! I hope it will be useful in your endeavors as a server administrator. Command kits is still under heavy development and I am completely open to feedback or suggestions. Have an idea for another drop-in, or would like to see more varied types of requirements? Think the way of defining kits sucks? Let me know! Also, I’d love to see what kind of crazy kits people come up with, be sure to share any in the comments. :grinning:

8 Likes

Great plugin! This looks really nice!

3 Likes

Thank you! I’m glad you like it!

thanks for this great plugin ! i go test it :smiley:

Thanks! Be sure to let me know if you find any bugs! :grinning:

1 Like

Also, i have a very big request x), i know one bukkit plugin… THE BEST PLUGIN ever
i love it xD
Its MyCommand ( dev.bukkit.org/bukkit-plugins/mycommand/ )
The plugin does anything you want as personaliz command like you :3 and if you can add some feature like option for execute as console, as player
Or make alias command , or still command with arguments (exemple : /vip $arg and /vip pseudo do command /pex user $arg group set vip )

I dont know if you understand but if you can, if you do this …
i love you :smiley: (and donations when i can x))

Interesting, I had never heard of MyCommand before, it looks neat. Command Kits already supports executing from console or by player, just add a ‘$’ in front of any command you want executed by the console :grin:, I do intend to eventually add the ability to pass arguments into commands, they will be if the form of drop-ins {ARG_1}, {ARG_2}, etc. something like that. Aliasing, is an interesting idea, you can essentially alias a command simply by creating a kit for it, though I could add in the option to define aliases for a kit itself, :wink:

1 Like

oh okay thanks !

Very thanks for your investment!!<3

New release Command Kits v0.2.1!

Added new Drop-In type the ARGS_
Arguments can now be passed in after the kit name. Example: /ck <kitName> [arg1] [arg2] ...
You can access these arguments in your commands via the ARGS_ drop-in type
For example to access the first argument in a command simply append the index 1 to the drop-in {ARGS_1}
If you simply want to insert all arguments in a drop-in (ex: for a message input) you can use {ARGS_*}
You can also specify ranges of args to insert, for example 1 to 3 {ARGS_1-3}
If you want to specify a starting index, but include all args after it we can also use *, for example all arguments from 2 forward {ARGS_2-*}
Similarly if we wanted all arguments up to and including the 2nd one we could use {ARGS_*-2}

Enjoy!

1 Like

I’m currently in the process of revamping the requirements section of kits, unfortunately this will break compatibility with the old format, however I plan for you to be able to specify requirements of the form "( {KEYS_EXPERIENCE_LEVEL} >= 5 && {WORLD_NAME} == MyWorld ) || {KEYS_IS_FLYING} == true" :grinning:

1 Like

why nobody see this plugin, its very nice plugin , you merit most download XD

1 Like

New release Command Kits v0.3.1!

Changes:

  • Added in /ck reload command to reload the configuration file while the server is still running
  • Added in PERM_drop-in type to check if a player has a permission in a rule expression
  • Added Advanced Requirement section to enable specifying requirements as boolean expressions

I’ve updated the guide in the first post to reflect these changes, but the big one is requirements are now expressed as boolean expressions!

Enjoy! :grinning:

2 Likes

Can you add command bungee ?^^ for tp for exemple :smiley:
thx <3

I’m not exactly sure what you mean by command bungee, could you give me some more examples? :grin:

1 Like

i send you mp ^^

New release CommandKits v0.3.2!
Changes:

  • This release brings compatibility with Sponge Beta Build 3.0.0

@Flashback083 I got your message I plan to hopefully add command control structures (loops/delays/etc) this weekend!
Enjoy!

1 Like

Thanks so much ! <3
and you think you can remove the prefixe /ck command ?
example : if i create /ck admin, i want to know if its possible to add /admin directly ^^

thankjs ! <3