For actively developed games, item names can change over time. This can cause several types of issues because we key our items off of their names. To solve this an immutable resource id should be added.
The two major issues are
1) Existing URLs will break because the name of the item is different. (referenced in #34)
2) Item recipes all need to be updated to the new name and can easily be forgotten or skipped
These examples will assume that #78 has already been completed
resources:
- name: Stone
recipes:
- recipe_type: Raw Resource
- name: Granite
recipes:
- recipe_type: Raw Resource
- name: Stone Slab:
recipes:
- output: 6
recipe_type: Crafting
requirements:
Stone: -3
- output: 2
recipe_type: Cutting
requirements:
Stone: -1
- recipe_type: Raw Resource
Becomes
resources:
- name: Stone
id: 1
recipes:
- recipe_type: Raw Resource
- name: Granite
id: 2
recipes:
- recipe_type: Raw Resource
- name: Stone Slab:
id: 3
recipes:
- output: 6
recipe_type: Crafting
requirements:
1: -3
- output: 2
recipe_type: Cutting
requirements:
1: -1
- recipe_type: Raw Resource
If an item is deleted from the recipe list the item id will be persisted so no other resource uses it
deprecated_ids: [2]
resources:
- name: Stone
id: 1
recipes:
- recipe_type: Raw Resource
- name: Stone Slab:
id: 3
recipes:
- output: 6
recipe_type: Crafting
requirements:
1: -3
- output: 2
recipe_type: Cutting
requirements:
1: -1
- recipe_type: Raw Resource
A linter will be unable to catch instances of removing or altering an id, however it may be possible to detect the deletion of an id during a presumit or premerge check in github actions.
IDs do not need to be numerically incrementing, or ordered in any way. The ordering of the list of resources determines how the items will be displayed to the user, which is completely disjoint from the purpose of the id.
The major downside to this approach is that the requirements field is no longer easily readable. So there may be some better solutions here in regards to dealing with requirements.
For actively developed games, item names can change over time. This can cause several types of issues because we key our items off of their names. To solve this an immutable resource id should be added.
The two major issues are 1) Existing URLs will break because the name of the item is different. (referenced in #34) 2) Item recipes all need to be updated to the new name and can easily be forgotten or skipped
These examples will assume that #78 has already been completed
Becomes
If an item is deleted from the recipe list the item id will be persisted so no other resource uses it
A linter will be unable to catch instances of removing or altering an id, however it may be possible to detect the deletion of an id during a presumit or premerge check in github actions.
IDs do not need to be numerically incrementing, or ordered in any way. The ordering of the list of resources determines how the items will be displayed to the user, which is completely disjoint from the purpose of the id.
The major downside to this approach is that the
requirementsfield is no longer easily readable. So there may be some better solutions here in regards to dealing with requirements.