Deploy Addons / deploy (push) Failing after 0s
The four portal blocks referenced vanilla texture paths from their own pack (emerald_block, amethyst_block, prismarine_bricks, end_portal_frame_top) without shipping those files. While the blocks rendered through the legacy blocks.json path this was invisible; once minecraft:geometry made material_instances take effect the lookup failed outright and they rendered as missing-texture. Ships real 16x16 textures generated through scripts/build-textures.py: a dark stone frame around a glowing field, one hue per destination -- jamie green, lyla purple, mya teal, plus a gold-ringed frame. terrain_texture.json now points at these instead of vanilla paths, so every key in the pack resolves to a file the pack actually contains. lobby_transfer_RP bumped to 1.0.1 so clients re-download rather than serving cached art; the lobby world pin was updated to match. Known issue, not fixed here: lobby_transfer_RP and hub_return_transfer_BP share pack UUID b2c3d4e5-1111-2222-3333-fedcba654321. They never load on the same server today, so the collision is latent, but it makes version bumps on either pack risky and should be resolved with a fresh UUID plus a pin update. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015Gf1kZypRDfPL1YiWUS1LC
24 lines
530 B
JSON
24 lines
530 B
JSON
{
|
|
"resource_pack_name": "lobby_transfer_RP",
|
|
"texture_name": "atlas.terrain",
|
|
"padding": 8,
|
|
"num_mip_levels": 4,
|
|
"texture_data": {
|
|
"portal_frame": {
|
|
"textures": "textures/blocks/portal_frame"
|
|
},
|
|
"portal_jamie": {
|
|
"textures": "textures/blocks/portal_jamie"
|
|
},
|
|
"portal_lyla": {
|
|
"textures": "textures/blocks/portal_lyla"
|
|
},
|
|
"portal_mya": {
|
|
"textures": "textures/blocks/portal_mya"
|
|
},
|
|
"portal_field": {
|
|
"textures": "textures/blocks/portal_field"
|
|
}
|
|
}
|
|
}
|