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
77 lines
3.2 KiB
Markdown
77 lines
3.2 KiB
Markdown
# 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.
|