You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Minecraft 1.17 gave some pretty good data for why using a item's name as a URL key is a bad idea when they renamed a large number of their items. The plan is to give every item in a calculator a numerical ID. This will just be an integer starting at 1 and increasing for each new item. This integer will be stored in the resources file and should never change. If an item name is changed the ID will stay the same and all old recipes will immediately target the newly named item keeping it up to date. Items will not be renumbered if their order shifts around.
In the URL items will be encoded using base64 to represent both the item ID and the quantity.
Each base64 number can be delimited by a non-base64 delimiter character and parsed in pairs to recreate the recipe string
Another possibility is to use some variation of varints in order to represent the data either with a 6 bit varint whcih would be slightly restrictive, or with some kind of combination of base64 encoded 8-bit varint strings. More experimentation will need to go into these solutions before one is selected.
This change will require an update to all calculator resource_list.yaml files
The text was updated successfully, but these errors were encountered:
Minecraft 1.17 gave some pretty good data for why using a item's name as a URL key is a bad idea when they renamed a large number of their items. The plan is to give every item in a calculator a numerical ID. This will just be an integer starting at 1 and increasing for each new item. This integer will be stored in the resources file and should never change. If an item name is changed the ID will stay the same and all old recipes will immediately target the newly named item keeping it up to date. Items will not be renumbered if their order shifts around.
In the URL items will be encoded using base64 to represent both the item ID and the quantity.
Each base64 number can be delimited by a non-base64 delimiter character and parsed in pairs to recreate the recipe string
Another possibility is to use some variation of varints in order to represent the data either with a 6 bit varint whcih would be slightly restrictive, or with some kind of combination of base64 encoded 8-bit varint strings. More experimentation will need to go into these solutions before one is selected.
This change will require an update to all calculator
resource_list.yaml
filesThe text was updated successfully, but these errors were encountered: