Home
This wiki outlines the basic and advanced functions of the ConfigurationMaster utility.
Links:
It is an API for Bukkit - including the majority of its forks, such as Spigot, Paper and Tuinity - which expands upon and improves experience related to using config files. It is considered one of the first of its kind to serve such a purpose and solve the problems that it does.
The features it currently covers include:
- Commenting on specific options, or even just about anywhere in the file.
- Separating options into specific sections.
- Forcing an order upon options so that new options can be added in the middle, at the bottom or even at the top of the configuration.
- Add example options/sections which don't reappear unless a new file is generated.
- Temporarily storing a file which has bad syntax as a separate configuration file.
- A customisable title, subtitle, description and set of external links to include in the header.
- The ability to move options around, especially when creating a new configuration format.
CM works in a fairly simple way, making it lightweight and simple to use. Two of its core functions are a little bit more complex though, but not by too much.
To maintain node order, CM uses a temporary FileConfiguration object which starts off empty. As more default values are added, the temporary config picks these up and takes the existing values out of the current configuration; because it started off empty, all provided paths and values are completely new to it, meaning that options are placed in chronological order. Once the loading process for adding defaults is complete, the temporary config saves itself to the config file that was originally read from. As a result, all nodes are added in a fixed order and do not get jumbled up as more and more values are added.
To add comments and sections, every time a comment or section is requested to be added, it is put in an area where it's "pending" - waiting for an option to sit above. When this option appears, any pending comments will be "tagged" to it. When it is time for writing the comments, the utility splits up each config path into individual sections (e.g. "option-1.option-2" get separated into "option-1" and "option-2") to decide the indent of the comment before placing it above the option. When a comment finds the option it was tagged to, the comment itself is split up as well, so that any divisions created by \n are taken into account, and written into the file on the line that the option is currently on (moving it down). If a special syntax is used to indicate a section, then that instead of a comment is written.
For a simple guide on setting the plugin up, check the Basic Setup page over here. For other and more advanced functions, see the sidebar.
