.

core/configurator/README.md

@@ -0,0 +1,34 @@
+# 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.