#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 infoon 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/ckcommand, 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_NAMEPLAYER_UUIDWORLD_NAMEWORLD_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 
). 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 infocommand -
description - human-friendly description of the requirement, will be displayed in the
/ck infocommand -
rule - this rule, expressed as a boolean expression (i.e. either
trueorfalse), 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 
.
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. 
, 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,