Refactor how blocks and items are defined#228
Merged
StackDoubleFlow merged 7 commits intomasterfrom Mar 6, 2026
Merged
Conversation
f44a6f4 to
522e527
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR aims to solve two issues:
Previously, adding a new block, even an extremely simple one, was a combersome process, which essentially boiled down to:
blocks!macro invocation, manually mapping the block id and name to the new enum variant. If the block has properties, then you may have to do a little math to encode/decode them.items!macro invocation, again manually mapping the id. Most items didn't even have a name mapping.core::interactionmodule.Then, when updating to a new game version, one would have to manually go through these massive macros and update the ids. Additionally, there are hardcoded protocol ids dotted around MCHPRS which can be hard to spot during an update. As a comical example, when we updated to 1.20.4, we missed the player entity id, so other players appeared as zombie villigers. There are other other types of protocol ids including note block sound ids, command argument type ids, and inventory type ids.
This PR solves these problems by introducing a single yaml file that contains a list of of the name of all blocks and items implemented by MCHPRS. It also checks in the generated
blocks.jsonandregistries.json. These 3 files are used in the newblock_data_genwhich generates a single rust file containing theBlockandItemenum, and many other generated implementations. To solve the problem where protocol ids are hardcoded everywhere, this PR introduces the new procedural macroprotocol_id!which can look up protocol id fromregistries.json. For example, to look up the entity id for a player, it's as simple asprotocol_id!("minecraft:entity_type", "minecraft:player").