Bedrock export¶
Every build also produces a Bedrock resource pack and Geyser mappings, so Bedrock players see your custom items instead of paper.
plugins/EmberForge/output/bedrock.mcpack the Bedrock pack
plugins/EmberForge/output/geyser-mappings.json the Geyser item mappings
Turn it off with bedrock.enabled: false.
Why two files¶
Bedrock cannot read a Java pack: different manifest, different texture index, different model format. Geyser bridges the gap only when given both halves —
- a mapping from (java item, custom model data) to a Bedrock item name, and
- a pack that actually contains a texture of that name.
Ship one without the other and the item stays paper.
Installing¶
cp output/geyser-mappings.json <geyser>/custom_mappings/emberforge.json
cp output/bedrock.mcpack <geyser>/packs/emberforge.mcpack
Restart Geyser. It reports what it took:
Stable pack identity¶
Manifest UUIDs are derived from the pack name, not generated randomly, so re-exporting keeps the same identity. A fresh UUID on every build makes every Bedrock client re-download the pack, and can leave two copies of it fighting on one device.
Two limits worth knowing¶
Flat icons only, for now. Bedrock needs a 2D sprite for an item icon. Items whose Java model is 3D — furniture, hats, most weapons — have no flat texture to give it, and are counted rather than shipped broken:
Converting those means generating Bedrock geometry and attachables from the Java model, which is on the roadmap.
80-character paths. Some Bedrock platforms break on asset paths of 80
characters or more. Texture files are named by model id (textures/items/ef_20001.png)
rather than by namespace and id, which keeps every path short while the item
identifier stays readable.
Do not run two custom-item mappers at once
If another converter is also writing Geyser mappings, both will claim the same (item, custom-model-data) pairs and Geyser refuses the duplicates:
Pick one. Whichever loses simply does not appear on Bedrock.