34 lines
No EOL
1.8 KiB
Markdown
34 lines
No EOL
1.8 KiB
Markdown
# 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 config 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 `/config` 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. |