Two problems, one of them mine.
Reverts thrown_banger/bundle/dynamite from geometry.snowball back to
geometry.item_sprite. Syncing these from main to the host produced
"[Geometry][error] geometry not found?" on the client -- geometry.snowball
does not resolve, while the April item_sprite version the host had been
running does. main was newer but had never been deployed, so the change had
never been validated against a running client. Newer is not the same as
correct, and this should have been verified before syncing rather than
assumed from the timestamps.
Separately, the client was reporting "Missing referenced asset" for every
custom block geometry -- tent_panel_l/r, hammock_slab, portal_field,
dragon_basket -- and spamming "A block must have baked material data in order
to tessellate!" 182,683 times, once per frame per unrenderable block. Those
geometry files exist and are valid; the client was serving stale cached copies
of the resource packs that predate them. Dynamite was the one pack that
refreshed, precisely because its version had just been bumped, which is why
dynamite appeared in game and camping supplies did not.
So every RP that ships models/blocks geometry is bumped to force a re-download:
spark_pet, camping_supplies and lobby_transfer, plus dynamite to carry the
geometry revert. Dependent BP manifests follow, and the world pins were set
explicitly rather than by the repin helper, which correctly refused these --
shared/ holds duplicate copies of the same UUIDs at older versions, so
"version on disk" is ambiguous for them.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015Gf1kZypRDfPL1YiWUS1LC
Six addons were bind-mounted in docker-compose.yml but absent from the deploy
workflow, so CI had never deployed them: dynamite, hemp, naturalist-lite,
smart-crafting, tow-boat and trees-features. The host was consequently running
April copies of files that main had moved on from in August -- dynamite's
thrown entities still used item_sprite geometry rather than snowball, and
smart-crafting's recipe still used AlwaysUnlocked rather than unlocking from a
crafting table.
That gap also silently broke dynamite: the world pins had been advanced to RP
1.0.2 while the host stayed on 1.0.1, so the pack was dropped from every world
until the pins were corrected earlier today.
Verified before adding, rather than trusting the workflow: tow-boat and
trees-features are byte-identical between host and main, and for the other
four main is strictly newer (host files date from April, main's from August).
The only host-only files are three strays that checkout -f will not remove --
sloth.bc_ap.json, "secretary_bird.rp_ac .json" (note the space) and
warlus.json -- so nothing is lost by arming the checkout for these paths.
PATHS now covers every directory docker-compose.yml mounts, so a mount can no
longer point at a directory CI never delivers.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015Gf1kZypRDfPL1YiWUS1LC
frog_leg, cooked_frog_leg and snake_egg_block are declared in the behavior
pack and mapped in item_texture.json, but the PNGs were never present, so all
three rendered as missing-texture wherever they appeared. All three already
had lang names, so only the art was absent.
Drawn through scripts/build-textures.py to match the pack's existing style --
small sprite on transparency, muted natural palette, single highlight. The
frog legs share one drumstick routine, raw carrying a green skin tint along
the top contour and cooked a browned crust. snake_egg_block is a clutch of
three eggs reusing the palette of the pack's existing single snake_egg.png,
so the block form reads as a group of the item.
RP bumped to 1.0.3 and mya's pin updated to match, otherwise clients keep
serving the cached pack and never fetch the new files.
Note: naturalist-lite-addon is absent from deploy.yml's PATHS, so CI never
deploys it -- this was applied to the host by hand. That absence is also why
the host sat on RP 1.0.1 while main was already at 1.0.2.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015Gf1kZypRDfPL1YiWUS1LC
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
