Two issues an addon-wide audit turned up.
The portal-texture commit bumped lobby_transfer_RP to 1.0.1 but left the
behavior pack's dependency on it pinned at 1.0.0. A dependency whose version
does not match the referenced pack's header is exactly the kind of mismatch
that makes Bedrock drop a pack, so this was a regression waiting to bite.
portal_field carries a menu_category, so it appears in the creative inventory,
but had no lang entry -- it showed as the raw key tile.silverlabs:portal_field
.name. The other four portal blocks were already named.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015Gf1kZypRDfPL1YiWUS1LC
hub-return existed on the host at 1.0.9 but had never been committed; main
only had 1.0.5. The deploy workflow's `git checkout -f origin/main -- $PATHS`
reverted the host to 1.0.5, discarding work that existed nowhere in git.
Recovered verbatim from the 2026-06-03 NAS archive. The RP is byte-identical
between the two, and the file sets match, so this is only the BP manifest
version plus scripts/main.js.
What 1.0.9 adds over 1.0.5:
* a spawn tip pointing players at private chests, since break-protection
covers chests but not terrain
* Family Goals integration -- a "Family" button in the hub menu, shown only
when the family-goals addon is present (sniffed via its world dynamic
property), dispatching `scriptevent family:menu` as the player so
family-goals sees the right sourceEntity
That integration pairs with family-goals, which was itself uncommitted until
this branch, so the two were lost and recovered together.
All three child worlds re-pinned to [1,0,9] (jamie already expected it; lyla
and mya were on 1.0.5) and verified loading at 1.0.9 in the pack stack.
Carried over as-is rather than tidied: openHubMenu still emits a
`[Hub][diag]` console.warn on every open, left from mid-development. Worth
removing, but not while recovering -- recovery should be faithful.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015Gf1kZypRDfPL1YiWUS1LC
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
Brings in four commits:
* redstone-link-addon -- wireless redstone (TX/RX paired by channel name)
* family-goals-addon -- was live on jamie but in no commit on any branch
* block textures generated through scripts/build-textures.py
* minecraft:geometry fix for the 7 custom blocks that rendered untextured
All of it is already deployed by hand and verified on the live stack, so a
CI deploy from this merge is a no-op content-wise. docker-compose.yml here is
byte-identical to the host, and deploy.yml's PATHS now covers every directory
the compose file mounts.
--no-ff so the whole change can be reverted as one unit if a live world
misbehaves.
* feat/redstone-link-and-family-goals:
fix(addons): add minecraft:geometry to the 7 untextured custom blocks
fix(redstone-link): add minecraft:geometry so material_instances applies
feat(redstone-link): real block textures via build-textures.py, add build.sh
feat(redstone-link): wireless redstone addon; track family-goals
Without a minecraft:geometry component Bedrock renders a custom block
through the legacy blocks.json texture path instead of material_instances.
These packs' blocks.json files only set "sound", with no "textures", so the
client substituted a default and the blocks rendered untextured. Diagnosed
and verified in-game on redstone-link; this applies the same one-line fix to
the rest.
Confirmed in the field for the portal blocks: portal_jamie, portal_lyla and
portal_mya all fell back to the same default, so players had to guess which
portal led to which world. They reference vanilla textures (emerald_block,
amethyst_block, prismarine_bricks), so with geometry set they render green,
purple and teal respectively -- one per child.
Also fixes home_sign, smart_crafting_table, tent_canvas and portal_frame.
full_block is correct for all seven: every custom block model in these packs
(hammock_slab, tent_panel_l/r, portal_field) is already referenced by its own
block, and no orphan model exists for any of these, so they were always meant
to be plain cubes.
No pack versions bumped deliberately. Block definitions live in the behavior
pack and reach clients through the network block palette rather than a cached
resource pack, so a bump is unnecessary -- and bumping would require updating
the matching pin in all four world_behavior_packs.json files, where a
mismatch silently drops the pack from the stack.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015Gf1kZypRDfPL1YiWUS1LC
The blocks rendered as an untextured default. Root cause: with no
minecraft:geometry component, Bedrock renders the block through the legacy
blocks.json texture path instead of material_instances. blocks.json here
only sets "sound", with no "textures", so the client substituted a default.
This produces no error in the content log -- both paths are valid, they just
resolve differently -- which is why the pack looked correct everywhere:
files installed byte-perfect, pack activated, terrain_texture.json valid,
and a clean world with only this addon still showed the wrong texture.
Adding "minecraft:geometry": "minecraft:geometry.full_block" fixes it,
verified in-game.
BP bumped to 1.0.1 so clients cannot reuse the cached copy. The lobby world
pin is updated to match; a mismatch silently drops the pack from the stack.
Note: 7 of the repo's other custom blocks have the same defect -- home_sign,
smart_crafting_table, tent_canvas, and all four lobby portal blocks. Most
blocks here DO set geometry, so those seven look like oversights rather than
intent. Not fixed in this commit; they touch every live world.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015Gf1kZypRDfPL1YiWUS1LC
The first textures were a motif floating on a flat slab. That hits the
lesson already documented on mailbox_block(): an icon-like sprite "reads
as a placeholder when applied to all 6 faces of a cube". Replaced with
machine faces whose traces run out to the edges, so they connect across
tile boundaries and a wall of them reads as continuous circuitry --
transmitter radiating out, receiver feeding in.
Generated through scripts/build-textures.py using the existing palette and
rect/px/save helpers rather than an ad-hoc script, so they regenerate with
everything else. Running the pipeline also rewrites the other five
textures, but pixel-identically -- that churn is only a newer Pillow
re-encoding, so those files are left alone.
RP header bumped to 1.0.1 (with the BP dependency to match) because clients
cache packs by uuid+version and would otherwise keep serving the old art.
The lobby world pin was updated to match; a mismatch silently drops the
pack from the stack.
Adds build.sh to package the .mcaddon, mirroring addon/build.sh. It omits
that script's `-x` exclude: these packs have no dotfiles, and dropping it
keeps the script working with the 7-Zip `zip` shim on the workstation as
well as Info-ZIP on the CI runner.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015Gf1kZypRDfPL1YiWUS1LC
Adds redstone-link-addon: a transmitter/receiver pair bound by channel
name, giving redstone that runs anywhere without wire, support blocks or
line of sight. Bedrock custom blocks can read redstone power but cannot
emit it, so a live receiver is swapped to a vanilla redstone_block and
back; receiver positions persist in a world dynamic property, with a
reconcile pass at boot to repair anything a crash left inconsistent.
Deployed and proven end-to-end on lobby (Hub World).
Also commits family-goals-addon, which was running on jamie -- mounted in
docker-compose.yml and pinned in the world -- while existing in no commit
on any branch. It was unbacked-up production code.
That omission was load-bearing for deploys: deploy.yml checks out
docker-compose.yml from origin/main, so a deploy would have replaced the
host compose with a version lacking the family-goals mount and silently
killed the addon. Both new directories are added to the workflow's PATHS
and push-trigger list, so nothing is mounted that CI does not deliver.
The mount set in this file now matches the live host exactly.
Note for a follow-up: dynamite-, hemp-, naturalist-lite-, smart-crafting-,
tow-boat- and trees-features-addon are mounted but absent from PATHS, so
CI never refreshes them.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015Gf1kZypRDfPL1YiWUS1LC
