How custom armor is split across a Bedrock add-on
A custom armor piece is not one file. The Behavior Pack defines the item and gameplay components. The Resource Pack supplies the icon and the attachable that controls how the equipped item renders on an entity. Geometry normally comes from Blockbench, while textures, materials, and render controllers complete the visual side.
This split explains a common failure: an item can exist in inventory and provide protection while appearing invisible when equipped. In that case, the Behavior Pack is loading but the Resource Pack cannot resolve the attachable, geometry, texture, or render controller. Debug each layer instead of rebuilding the entire pack.
Use one namespace and one stable identifier from the beginning. In this example, the item and attachable both use icedfox:crystal_chestplate. The attachable identifier should match the item it renders. Keep file names lowercase and use underscores so the same naming system works on Windows, Android, consoles, and dedicated servers.
Create the armor item in the Behavior Pack
Start with a working custom item, then add wearable and durability components supported by the target stable version. Do not copy a preview-only component into a public release without declaring that requirement. The exact component set can change, so compare your file with the current item component reference before shipping.
{
"format_version": "1.21.90",
"minecraft:item": {
"description": {
"identifier": "icedfox:crystal_chestplate",
"menu_category": { "category": "equipment" }
},
"components": {
"minecraft:icon": "crystal_chestplate",
"minecraft:max_stack_size": 1,
"minecraft:wearable": { "slot": "slot.armor.chest" },
"minecraft:durability": { "max_durability": 420 }
}
}
}Confirm that the item appears, can be equipped, and occupies the correct slot before adding a custom model. If the item itself does not load, inspect the Content Log and manifest dependencies first. The attachable cannot repair an invalid Behavior Pack item.
Add the translated display name through the Resource Pack language file and register the inventory icon in textures/item_texture.json. Test with a plain icon first. That gives you a known-good item while you work on the equipped model.
Build armor geometry without fighting the player rig
Create a Bedrock model in Blockbench and use the humanoid armor bones expected by your chosen render setup. Build around the player model rather than around an empty origin. Chest, arms, legs, boots, and helmet geometry need pivots that follow the corresponding player bones. A visually correct static model can still rotate badly if its pivots or parent bones are wrong.
Keep cube inflation and texture resolution intentional. Armor placed exactly on the skin can flicker through the player model. A small outward offset reduces z-fighting, but excessive inflation makes the piece look detached. Test slim and classic player models if your armor exposes the arms.
Export the geometry into the Resource Pack models/entity tree and give it a unique identifier such as geometry.icedfox.crystal_chestplate. Never leave the default identifier from a copied project. Duplicate geometry identifiers can make another resource override yours based on pack order.
Create the attachable definition
The attachable maps the item identifier to materials, textures, geometry, scripts, and render controllers. Microsoft documents attachables as the resource definitions used for equipped or held items, including armor and weapons. The short keys such as default are aliases that the render controller can resolve.
{
"format_version": "1.10.0",
"minecraft:attachable": {
"description": {
"identifier": "icedfox:crystal_chestplate",
"materials": {
"default": "armor",
"enchanted": "armor_enchanted"
},
"textures": {
"default": "textures/models/armor/crystal_chestplate",
"enchanted": "textures/misc/enchanted_actor_glint"
},
"geometry": {
"default": "geometry.icedfox.crystal_chestplate"
},
"scripts": {
"parent_setup": "variable.chest_layer_visible = 0.0;"
},
"render_controllers": [
"controller.render.armor"
]
}
}
}The parent_setup expression hides the relevant vanilla armor layer in the parent setup used by the sample. Do not paste visibility variables blindly across every slot; helmet, chest, legs, and boots can need different layer treatment. Begin with the official vanilla attachable closest to your use case and change one reference at a time.
Textures, materials, and enchantment glint
The texture path omits the file extension and is relative to the Resource Pack. On case-sensitive systems, Crystal_Chestplate.png and crystal_chestplate.png are different files. Keep the JSON path, file name, and exported UV layout synchronized.
The standard armor material is a useful baseline. If you need transparency, emissive areas, or unusual blending, use an appropriate documented material and test on every target renderer. A custom render controller is justified when you need conditional textures or geometry; it is unnecessary for a single static armor piece.
Keep the enchanted alias when you want the vanilla glint behavior. Test enchanted and unenchanted versions because a missing enchanted material or texture can make only one state fail. Also test first and third person, another player, an armor stand, movement, swimming, sneaking, and elytra combinations.
Test each layer in a fixed order
- Load the Behavior Pack and confirm the item appears by identifier.
- Verify the icon and translated name from the Resource Pack.
- Equip the item and inspect the Content Log for attachable errors.
- Replace custom geometry temporarily with a known vanilla geometry.
- Restore geometry, then test a simple opaque texture.
- Test enchantment, multiplayer visibility, and all movement states.
- Export a fresh pack and test outside the development folders.
This order isolates the failing layer. If vanilla geometry renders, the attachable is being found and your custom geometry identifier or file is the likely problem. If geometry renders with a test texture, inspect UVs and the original image. If development works but import fails, check manifest UUIDs, dependencies, pack versions, and stale duplicate packs.
Fix invisible or broken custom armor
- Invisible only when equipped: verify the attachable identifier exactly matches the item identifier.
- Pink or black texture: verify the extension-free path, file case, image mode, and UV layout.
- Model at the feet: inspect bone names, parents, pivots, and geometry identifier.
- Vanilla armor overlaps: use the correct parent visibility setup for the slot.
- Only enchanted armor fails: check the enchanted material and glint alias.
- Works in development but not an imported world: remove old duplicate packs and inspect dependency versions.
Read the first meaningful Content Log error, fix it, reload, and read again. One missing geometry can produce several later messages. Chasing the final error first wastes time.
Release checklist
Before publishing, test a clean import, survival crafting or acquisition, durability, death drops if relevant, armor stands, multiplayer, enchantment, classic and slim skins, and the current stable Bedrock release. Document whether experiments are required. Include both Behavior and Resource Packs and declare their dependency correctly.
Use original geometry and textures or assets whose license permits distribution. Keep editable Blockbench sources in your project repository, not inside the public pack unless you intend to ship them. A clean source structure makes later ports and bug fixes much faster.
Official sources checked
Primary references used to verify this tutorial:
- Microsoft Learn - Attachables Documentation
- Microsoft Learn - Adding a Custom Item
- Microsoft Learn - Comprehensive List of Pack Contents
- Blockbench Wiki - Bedrock Modeling