Several resource files contain native yaml comments in them. While having comments is great, they are not normally parsed by machines. This means that if a program were to consume and export this file all of the comments would be stripped out. #75 Intends to do just this. Additionally those comments could not be displayed to the users of the GUI. For the most part these comments are used in three situations:
Notes about an item
Dividers between items in the list
Notes about the entire resource list at the top of the file
There are likely other use cases, however these are the three that will be addressed now and others will be address ad-hoc.
The best solution is to convert these comments into fields that can be parsed and displayed to the GUI users. #78 is intending to replace the resources: dictionary with an array so we will assume this work has already been completed for the following examples.
# A recipe list for craftmine, not to be confused with another popular game.
resources:
# Rocky Resources
- name: Stone
recipes:
- recipe_type: Raw Resource
- output: 1
recipe_type: Smelting
requirements:
Cobblestone: -1
Fuel: -1
# Granite-y resources
# Granite says it is made by crafting here, but really it is Ethereal Smelting. Which is not yet supported
- name: Granite
recipes:
- recipe_type: Raw Resource
- output: 1
recipe_type: Crafting
requirements:
Diorite: -1
Nether Quartz: -1
becomes
comment: A recipe list for craftmine, not to be confused with another popular game.
resources:
- comment: Rocky Resources
- name: Stone
recipes:
- recipe_type: Raw Resource
- output: 1
recipe_type: Smelting
requirements:
Cobblestone: -1
Fuel: -1
- comment: Granite-y resources
- name: Granite
comment: Granite says it is made by crafting here, but really it is Ethereal Smelting. Which is not yet supported
recipes:
- recipe_type: Raw Resource
- output: 1
recipe_type: Crafting
requirements:
Diorite: -1
Nether Quartz: -1
While a little less visually distinct from the native comments we have now increased compatibility with machine parsers, allowed this datum to be translated to json and back, and allowed the future GUI Editor to benefit from comments.
Using - comment: in the resources list was decided over using a recursing - group: style syntax because this method was simpler and made less assumptions about how the resources file should be structured.
After this change the linter will begin to print warnings when it discovers a native comment (if possible).
Several resource files contain native yaml comments in them. While having comments is great, they are not normally parsed by machines. This means that if a program were to consume and export this file all of the comments would be stripped out. #75 Intends to do just this. Additionally those comments could not be displayed to the users of the GUI. For the most part these comments are used in three situations:
There are likely other use cases, however these are the three that will be addressed now and others will be address ad-hoc.
The best solution is to convert these comments into fields that can be parsed and displayed to the GUI users. #78 is intending to replace the
resources:dictionary with an array so we will assume this work has already been completed for the following examples.becomes
While a little less visually distinct from the native comments we have now increased compatibility with machine parsers, allowed this datum to be translated to json and back, and allowed the future GUI Editor to benefit from comments.
Using
- comment:in the resources list was decided over using a recursing- group:style syntax because this method was simpler and made less assumptions about how the resources file should be structured.After this change the linter will begin to print warnings when it discovers a native comment (if possible).