sysadminandClaude Opus 5
8ded29cbcc
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
3.2 KiB
Redstone Link
Wireless redstone. Vanilla dust needs a solid block under it and gets cut off by terrain; this replaces the wire entirely with a transmitter/receiver pair bound by a channel name.
| Block | What it does |
|---|---|
silverlabs:redstone_link_tx — Redstone Link Transmitter |
Reads redstone power from any of its six neighbours. While powered, its channel is live. |
silverlabs:redstone_link_rx — Redstone Link Receiver |
While its channel is live, emits full-strength (15) power in every direction. |
Craft either from a redstone block + ender pearl (+ copper for the transmitter, iron for the receiver). Both give 2.
Setting a channel: right-click a block and type a name, e.g. front-door.
Every transmitter and receiver sharing that name is linked — many-to-many, any
distance, through any terrain, in any direction. Newly placed blocks start on
channel default.
How it works, and why
Bedrock custom blocks can read redstone power but cannot emit it — there is
no script API for that. So a live receiver is physically swapped for a vanilla
minecraft:redstone_block (strength 15, omnidirectional, needs no support) and
swapped back when the channel goes quiet.
That swap is why scripts/registry.js exists: while a receiver is powered the
block itself no longer says it is a receiver, so the positions are kept in a
world dynamic property. It survives container restarts, and a reconcile pass at
boot repairs anything left inconsistent by a crash.
Breaking a powered receiver is intercepted so it returns the receiver block rather than a free redstone block.
Limits
These are inherent to the approach, not bugs:
- Both ends must be in loaded chunks. A link whose receiver sits in unloaded terrain simply does not fire. Cover it with a ticking area if it must always work.
- ~2 tick latency. Fine for doors, lamps and farms; not for sub-tick clocks.
- Binary, not graded. Output is always 15, never a decayed signal.
- Same dimension only.
- 256 nodes per world.
A transmitter ignores power coming from its own channel's receivers, so putting a matched pair side by side will not latch itself on.
Console / bridge control
Blocks placed by /setblock, /fill, or the mc-ai-bridge MCP build tools never
fire playerPlaceBlock, so they are not registered and stay inert. Register them
explicitly (sourceEntity is null over RCON/the bridge, so no player is needed):
/scriptevent rlink:register <x> <y> <z> <channel>
/scriptevent rlink:unregister <x> <y> <z>
/scriptevent rlink:status
rlink:status reports node counts and active channels — the quickest way to
confirm the pack is alive on a headless server.
Deployment
Bind-mount both packs into the target service in docker-compose.yml, then pin
the pack UUIDs into that world's world_behavior_packs.json /
world_resource_packs.json. The version arrays must match the manifest header
versions exactly or the pack is silently dropped from the stack.
| Pack | UUID | Version |
|---|---|---|
| BP header | e4f1a7c2-6b95-4d38-a7e0-3c81d5f2b001 |
[1, 0, 0] |
| RP header | e4f1a7c2-6b95-4d38-a7e0-3c81d5f2b004 |
[1, 0, 0] |
Currently deployed to lobby (Hub World) only.