Repository navigation
Bedrock data for 1.16.1201-1.26.60 - #1335
Conversation
|
Thanks for work on this. I think as mentioned we really want to have something like minecraft-data-generator to auto generate this data going forward. It helps act both as a sanity check and removes need for manual time making update PRs Right now we can merge only on basis that it "looks good" which isn't ideal |
|
generated by https://github.com/mc-zuri/bedrock-data-generator |
|
Cool adding to doc would be good Does it support all the versions ? |
|
Tested the data across all 27 versions it adds (1.16.201 to 1.21.0). Every version has complete items/blocks/blockStates/materials/blockCollisionShapes that parse and are non-empty, and the counts scale per build (items 914 -> 1599, blockStates 6611 -> 14160), so the per-version regeneration looks right. End-to-end through node-minecraft-data + prismarine-registry + prismarine-block, 1.17.10 to 1.21.0 all work (both the indexed and hashed block-id schemes round-trip The four oldest (1.16.201, 1.16.210, 1.16.220, 1.17.0) are a bit special: this PR adds item data they never had (published |
rom1504
left a comment
rom1504
left a comment
There was a problem hiding this comment.
Astra agent review — AI-generated, not manually written by the maintainer.
Reviewed b34f7dfed829, including the existing discussion and extremeheat's approval. The direction is useful: shared Bedrock facts come from an actual per-build server extractor, and the candidate CI already checks each selected block/state mapping for matching names, complete coverage, and valid default-state ranges. I found no new correctness defect in the portions inspected.
A clarification on the four oldest versions returning no items: replacing the JSON files and dataPaths.json alone does not update the Node wrapper's generated data.js getters. Using the existing wrapper loader with the candidate getters that bin/generate_data.js would produce, I get 914 items for each of 1.16.201, 1.16.210 and 1.16.220, and 1,038 for 1.17.0, including itemsByName.stone. This supports checking wrapper regeneration before assuming a loader-code change is required. It is a focused consumer diagnostic, not a full wrapper release test.
Additional validation: with the candidate 1.17.10 blocks/items/collision shapes and selected 1.17.0 material table, the actual block model round-tripped 7,852 states through fromStateId → getProperties → fromProperties; stone with the candidate diamond-pickaxe ID gives a 300 ms dig time. Dependencies for that diagnostic were minecraft-data 3.110.2, prismarine-registry 1.12.0 and prismarine-block 1.23.0; the unchanged 1.17.10 palette came from that installed data release. I also checked item-ID uniqueness, harvest-tool/drop references for 1.17.10, 1.26.30 and 1.26.51, and all 1.26.30 collision-array lengths against their block state ranges. These checks passed.
I have not rerun the native extractor or established full latest-version downstream compatibility from these samples. The existing documentation/version-coverage request remains relevant: doc/bedrock.md still points at the old extractor and describes collision/material data as coming from Java. I am linking that request rather than adding duplicate inline feedback. The next useful integration check is a regenerated Node wrapper with the 1.26.40/1.26.51 data through current registry/block consumers, alongside recording the generator revision and exact server builds.
Skills used: prismarine-protocol-data-review distinguished generated wrapper exports from the loader and checked producer/consumer references; prismarine-review checked existing feedback and the actual CI validation scope; prismarine-architecture-review checked the shared-data ownership and regeneration boundary; prismarine-item-inventory-review helped trace item IDs into harvest-tool and drop consumers.
Every block state of the exact Bedrock Dedicated Server build of each version, in runtime id order, each state's properties as the game's NBT tags. A version whose palette is the previous version's shares its file through dataPaths.json.
Every block by the server's numeric block id: hardness, resistance,
light, stack size, material and harvest tools, runtime ids, bounding
box, and its drops. Drops are drawn from the game's own drop code for
a player mining the block with an empty hand, or for a data-driven
block taken from its loot tables. A block no player can mine drops
nothing.
blocks_schema.json takes a negative item id in a drop's
{ drop: { id, metadata } }, as items_schema.json does: Bedrock's block
items past id 255 have negative ids, and in 1.16.201 and 1.16.210 such
a drop carries a data value.
Each state's collision boxes as the game's addCollisionShapes gives them, written in the form of the version's committed file, its blocks in the order of the version's blocks.json.
Each material's dig speeds by item id, from the destroy speed the game gives every item on every block.
Every registered item by the runtime id the server sends, with the stack size, durability, enchantment slots and repair items the game answers, the block state its creative item places, and from 1.21.60 the nbt and version the item registry packet carries. Each item's keys keep the order the version's committed file wrote them in.
|
I have regenerated from linux for all 1.16.201+ versions, updated block display names, fixed paths to types.yml, added docs about generator. |
|
you can see few demos here. it just have biomes and entities in additional commits. |
mc-zuri
changed the title
ubuntu-latest is now ubuntu-26.04, whose CMake 4 refuses leveldb-mcpe's cmake_minimum_required. leveldb-zlib has no prebuilt binary for Node 24, so installing bedrock-protocol compiles it and fails; ubuntu-24.04 has CMake 3.31.
|
Thanks |
No description provided.