# configurator

This plugin/API allows developers to define configuration fields by name(or rather key) and data type, and have admins easily set
the fields' values in-game using commands such as `/cfg key chat.messageDelay set 50 ms`.

<small>
the key literal in `/cfg key` is required, because there are other modes like `/cfg check` that checks
the configFile for uninitialized values.
</small>

# Design

Plugins register configuration nodes by key. A key consists of a unique identifier and a type.
The type handles (de)serialization and defines actions. Actions can be used on nodes.
Nodes hold values.

The `/configFile` or `/cfg` command is used by admins to configure the plugin:
A lobby plugin might register a node with the identifier `lobby.spawnLocation` and type `ConfigLocationType`,
which gives us the command `/cfg key lobby.spawnLocation`.
Let's say the ConfigLocationType defines an action to use the player's location as the value("pick-current")
and an action to teleport the user to the defined location("teleport").
Thus, we can do `/cfg key lobby.spawnLocation pick-current` or `/cfg key lobby.spawnLocation teleport`.
Tab completion makes this pretty obvious.

## Lists

Now maybe we want to make our lobby have some launch pads(i.e. some pressure plates that launch the player).
So, lists would be handy.
For lists, we simply use a Node of type List<ConfigType of Element>, so for our launch pads, we could make a node
with identifier "lobby.launchpads" and type `ConfigListType<ConfigLocationType>`.
Now to add a launch pad, we can just `/cfg key lobby.launchpads append`, which creates a new uninitialized element
in the list, followed by `/cfg key lobby.launchpads.0 pick-current` which actually sets the node's value.

The node `lobby.launchpads.0` is not a real registered node. It is a Sub-Node of the `lobby.launchpads` node.