# 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.