Pocketmine-mp: Split server configurations are confusing and inconsistent

[dktapps]

For a long time (past several years) PocketMine-MP has operated with two configuration files: server.properties and pocketmine.yml. The original goal of this appears to have been something like:

• Have a config file which imitates the standard config file of the vanilla server.
• Provide a second config file for "advanced" configuration.

The actual result of this is that:

• Users get confused because they expect that server.properties options from PC to also work in PM when in a lot of cases they don't. Our RTFD even says to visit the Minecraft wiki to see what properties can be used, when in fact half of the properties on the wiki do not work in PocketMine-MP.
• We have inconsistencies in the configuration files when handling similar things (for example anti-cheat settings and world generation options split between two config files), leading to confusion over where a new config option should be located.
• It's difficult to add PM-only features without making configs more confusing (for example it's possible for PocketMine-MP to support multiple server-ip configurations with little effort).

This issue proposes that we scrap both configuration files and have a single file where everything is located. This should be in a format that supports complex structures (for example YAML), has a clear name (e.g. server.yml), and has all config options properly organized, documented and findable.

[95CivicSi]

This would help new users (and some experienced users) tremendously.

[SOF3]

Also reconsider the language used. YAML is really hard for updating. Also consider hiding default settings. Let's distinguish if the user explicitly disabled send-usage or just got it auto generated.

[dktapps]

YAML is currently the best option we have. I'm open to alternative suggestions.

[ZizzyZizzy]

This change will cause chaos with any hosting service that supports Pocketmine. server.properties has been the defacto standard for Minecraft configuration since pretty much day 1, and as such is built into every hosting software that exists today.

Also, in my last 5 years of hosting experience, users are constantly messing up the YML files because of improper spacing. YAML is powerful and yet notoriously unforgiving; A single misplaced space renders the entire file useless.

It's even more confusing when the plugin (or whatever) automagically reverts to a default YAML configuration file (or doesn't load) when an error occurs, leaving the end-user befuddled because their changes didn't stick, not to mention wiping out all the changes that were configured properly before the most recent misplaced space.

A more involved alternative would be to have console/in-game commands accessible to make various changes automatically to a yaml configuration file and leave server.properties as-is to maintain backwards compatibility.

[dktapps]

yeah, backwards compatibility is a problem here, but the reason we have this mess to begin with is because of PM attempting (badly) to substitute for a vanilla server. False promises of vanilla compatibility just lead to things inexplicably not working (look at the spawn-mobs config for example).

As I said above I'm open to alternative suggestions wrt. the format. I'm also not a huge fan of YAML, but currently we don't have a better option.

[95CivicSi]

Because of how the the current release methods are happening with PocketMine, hosting services would have plenty of time to make appropriate changes to their dashboards or other user interfaces before it became necessary to convert.

As for the problem with users and config files, I don't believe that there is any (human readable) format that supports fault tolerance on a level which will significantly reduce the problem @ZizzyZizzy mentioned. The best way to eliminate user created syntax errors in configs, is to require the user to make changes via an interface that will fix errors, or keep users from making changes that will break the setup. Even that won't completely fix these types of problems, but they would be significantly reduced.

In the end, I feel that YAML is easier for end users in comparison to JSON and I don't think there's a better option for configs at the moment.