OpenTerrainGenerator
OpenTerrainGenerator copied to clipboard
PG85
Feature: Alternative config file type
We should consider switching to, or at least providing the option to use a standardized file format for biome and object configuration files. This would allow us to reduce the size of configuration files, provide easier parsing with an external API such as SnakeYAML, and allow for easy integration with programs such as visual studio code and online parsers.
YAML or TOML would be good options for this.
SnakeYAML: https://bitbucket.org/asomov/snakeyaml/src/master/
Most important ofc would be to ask the people actually using the configs on a regular basis.
Here's what the current configs can do btw, that a new implementation should also support:
- Default/Min/Max values for settings.
- Allow settings missing from file, use per-setting default values if missing. Missing int settings should not default to 0 (zero), etc.
- Backwards compatibility for older versions/formats (read old formats, write new format).
- Comments.
- Allow all value types and syntaxes, without the need for manual escaping of characters.
For YAML:
Here's what the current configs can do btw, that a new implementation should also support:
* Default/Min/Max values for settings.
This is currently done in the code anyway.
* Allow settings missing from file, use per-setting default values if missing. Missing int settings should not default to 0 (zero), etc.
This is currently done in the code anyway.
* Backwards compatibility for older versions/formats (read old format, write new format).
Shouldn't be an issue, and I haven't seen any breaking changes in YAML in the time I've been using it.
* Comments.
Modern SnakeYML supports comments.
* Allow all value types and syntaxes, without the need for manual escaping of characters.
Should be possible? " and ' may need escaping.
For my part, I'd highly recommend that whatever language you/we use, you use an OTG-specific file extension. This would allow things like VScode extensions and just simple user configurations to specifically target OTG files. Not sure what the best value would be to use for this -- we've got BO3, BO4, and BC currently. Google says OTG is already taken by a different standard, so probably not free real estate there.
@Coll1234567 If you just deserializes classes like yaml, xml, json etc, reading files direclty into classes, then you won't be able to do:
- Default/Min/Max values for settings.
- Allow settings missing from file, use per-setting default values if missing. Missing int settings should not default to 0 (zero), etc.
Things like ints will be automatically coerced to zero when missing, but that should also be an allowed value, and not assumed to be the default. We need to be able to recognise settings that are missing from the file entirely.
- Backwards compatibility for older versions/formats (read old format, write new format).
If you're using deserialisation, you can't do this, unless you maintain classes that represent every previous version of the format as well, or are prepared to include in one class every setting and format we've ever supported (which will then also be written back ofc).
- Allow all value types and syntaxes, without the need for manual escaping of characters.
Any string has to be encased in "" (not needed currently), any quotes or reserved characters inside will need to be escaped, though I suppose we rarely use those for any settings (mob spawn settings is one place).
To me this seems a little unnecessary, especially as everyone is just going to be using the old types of files.
Plus it'll be a cold day in heck before community tools like bo3_bulkedit will support it.
Just seems like a waste of effort. We've had our own special way of doing things since Buycruss and it works so why fix it?
