The file C:\Users\decid\Documents\projects\rebno\docs\adr\0013-perception-gating.md has been updated successfully. (file state is current in your context — no need to Read it back)

within chat proximity). **Friendship grants metadata markers only** (e.g. a friend's marker when
visible), **never raw in-world avatar or chat sight** — with one deliberate exception: an active
**Duo** lets its two partners always see each other (including on hidden tiles), and thus each
other's chat (chat inherits avatar visibility). This is the co-op carve-out. The whole thing is a
*new* system — legacy had no equivalent — and an intentional exception to ReBNO's otherwise
parity-first scope principle.

---
status: accepted
---

# Perception gating — per-player visibility is server-computed from progression + spatial state

Legacy BNO is fully client-authoritative (the Master only relays): hidden tiles self-reveal
client-side, public chat is a proximity rebroadcast, and appearance/inventory are unvalidated, so
the original could not meaningfully enforce *who sees what*. ReBNO is server-authoritative, so we
adopt **perception gating** as a core pillar: what a player perceives — which avatars they see,
whose chat they receive, which map markers and friend-location text are shown — is **computed
server-side from that player's own progression + spatial state**, never trusted from the client.

The rule has a deliberate boundary: **avatar and chat visibility are spatial/progression-only**
(you see a Navi only if you share their contiguous hidden-tile body / reachable geometry, and
within chat proximity). **Relationships (friend / Duo) grant metadata markers only** (e.g. a Duo
partner's worldwide map marker), **never raw in-world avatar or chat sight.** This is a *new*
system — legacy had no equivalent — and an intentional exception to ReBNO's otherwise parity-first
scope principle.

## Consequences

- The server performs **interest management**: it computes a per-recipient visibility set and
  filters position + chat broadcasts accordingly — not a single room-wide rebroadcast.
- **Contiguous-hidden-tile-body** membership becomes server-tracked state.
- **Chat routing is visibility-filtered** (can't see the avatar → don't receive the chat).
- **Markers are a separate, relationship-aware metadata channel**, decoupled from avatar streams.
- Higher server CPU + per-recipient payloads than legacy's blind rebroadcast — acceptable at the
  <50 CCU target.
- Open question (tracked in `CONTEXT.md`): whether the Duo camera renders the Digger when they
  stand on hidden tiles the Spotter has not reached.

## Considered alternatives

- **Faithful client-relay (legacy model)** — rejected: client-authoritative, unenforceable, and
  contradicts CLAUDE.md Hard Rule 1.
- **Room-wide broadcast with client-side hiding** — rejected: leaks position/chat to the client
  and is trivially cheatable.

See `CONTEXT.md` → "Perception gating" for the living definition.

-within chat proximity). **Relationships (friend / Duo) grant metadata markers only** (e.g. a Duo

-partner's worldwide map marker), **never raw in-world avatar or chat sight.** This is a *new*

-system — legacy had no equivalent — and an intentional exception to ReBNO's otherwise parity-first

+within chat proximity). **Friendship grants metadata markers only** (e.g. a friend's marker when

+visible), **never raw in-world avatar or chat sight** — with one deliberate exception: an active

+**Duo** lets its two partners always see each other (including on hidden tiles), and thus each

+other's chat (chat inherits avatar visibility). This is the co-op carve-out. The whole thing is a

+*new* system — legacy had no equivalent — and an intentional exception to ReBNO's otherwise


Edit

- Open question (tracked in `CONTEXT.md`): whether the Duo camera renders the Digger when they
  stand on hidden tiles the Spotter has not reached.

- **Duo carve-out:** active Duo partners always see each other (including on hidden tiles either
  stands on) — the one relationship that overrides spatial visibility; the server enforces the
  pairing.


- **Duo carve-out:** active Duo partners always see each other (including on hidden tiles either
  stands on) — the one relationship that overrides spatial visibility; the server enforces the
  pairing.

---
status: accepted
---

# Perception gating — per-player visibility is server-computed from progression + spatial state

Legacy BNO is fully client-authoritative (the Master only relays): hidden tiles self-reveal
client-side, public chat is a proximity rebroadcast, and appearance/inventory are unvalidated, so
the original could not meaningfully enforce *who sees what*. ReBNO is server-authoritative, so we
adopt **perception gating** as a core pillar: what a player perceives — which avatars they see,
whose chat they receive, which map markers and friend-location text are shown — is **computed
server-side from that player's own progression + spatial state**, never trusted from the client.

The rule has a deliberate boundary: **avatar and chat visibility are spatial/progression-only**
(you see a Navi only if you share their contiguous hidden-tile body / reachable geometry, and
within chat proximity). **Friendship grants metadata markers only** (e.g. a friend's marker when
visible), **never raw in-world avatar or chat sight** — with one deliberate exception: an active
**Duo** lets its two partners always see each other (including on hidden tiles), and thus each
other's chat (chat inherits avatar visibility). This is the co-op carve-out. The whole thing is a
*new* system — legacy had no equivalent — and an intentional exception to ReBNO's otherwise
parity-first scope principle.

## Consequences

- The server performs **interest management**: it computes a per-recipient visibility set and
  filters position + chat broadcasts accordingly — not a single room-wide rebroadcast.
- **Contiguous-hidden-tile-body** membership becomes server-tracked state.
- **Chat routing is visibility-filtered** (can't see the avatar → don't receive the chat).
- **Markers are a separate, relationship-aware metadata channel**, decoupled from avatar streams.
- Higher server CPU + per-recipient payloads than legacy's blind rebroadcast — acceptable at the
  <50 CCU target.
- Open question (tracked in `CONTEXT.md`): whether the Duo camera renders the Digger when they
  stand on hidden tiles the Spotter has not reached.

## Considered alternatives

- **Faithful client-relay (legacy model)** — rejected: client-authoritative, unenforceable, and
  contradicts CLAUDE.md Hard Rule 1.
- **Room-wide broadcast with client-side hiding** — rejected: leaks position/chat to the client
  and is trivially cheatable.

See `CONTEXT.md` → "Perception gating" for the living definition.

-- Open question (tracked in `CONTEXT.md`): whether the Duo camera renders the Digger when they

-  stand on hidden tiles the Spotter has not reached.

+- **Duo carve-out:** active Duo partners always see each other (including on hidden tiles either

+  stands on) — the one relationship that overrides spatial visibility; the server enforces the


CONTEXT + ADR done. Now applying the confirmed edits to `LEGACY_FEATURE_REFERENCE.md` — fixing the 4 drift items with concrete numbers and tagging the intent items:


  - variants: UP/LEFT/RIGHT/DOWN
  - consult legacy code for exact acceleration behavior

  - variants: UP/LEFT/RIGHT/DOWN
  - 5-8 tuning (pinned by recon): player `+2 / −1, cap 6` (~180 px/s peak); NPCs & data drops (`pcode_mover`) `+1.5 / −0.5, cap 5`


ignore the '/clear', accident. --- moving platforms pre-departure blink anim: it will need new animations per platform. --- back to intent: 3. incorrect. it might just have a different name, but it de…


ReBNO feature parity and platform expansion


The file C:\Users\decid\Documents\projects\rebno\docs\LEGACY_FEATURE_REFERENCE.md has been updated successfully. (file state is current in your context — no need to Read it back)

  - variants: UP/LEFT/RIGHT/DOWN
  - 5-8 tuning (pinned by recon): player `+2 / −1, cap 6` (~180 px/s peak); NPCs & data drops (`pcode_mover`) `+1.5 / −0.5, cap 5`

# BNO LEGACY-->REBNO FEATURE TRIAGE

## Non-interactive Floor Tile Types
- BORDERED: player stops at edges, cannot walk off
- BORDERLESS: player can walk off and fall into the void
- HIDDEN: invisible by default. reveals when player collides, eventually times out and re-hides after collision ends
- GLOW: same player collision behavior as hidden, but always visible + transitions to and from glowing
- MOVER: applies acceleration to entities (players, NPCs, data item drops) up to a peak velocity
  - all forms can push player off the exiting end and into the void
  - variants: UP/LEFT/RIGHT/DOWN
  - consult legacy code for exact acceleration behavior
- PLATFORM: moving platform carries entities with it
  - stops for some number of seconds at each end of its travel
  - currently only exhibits up/down or left/right movement patterns
  - movement needs to be client-driven but synced deterministically to server time, so all players see all platforms in the same locations at the same time.
- DYNAMIC: has neighbor-sensitive sprites and TSide sprites. variants:
  - LONE
  - TOP/LEFT/RIGHT/BOTTOM NEIGHBORED
  - T/L/R/B ENDPIECE
  - TL/TR/BR/BL CORNER
  - L+R BRIDGE
  - U+D BRIDGE
  - SURROUNDED
  - SPECIAL: if surrounded on two sides but missing the diagonal between those two, draws corner sprite art wherever such diagonals are missing. consult legacy code for exact behavior
  - NOTE: most patterned tiles treat other non-hidden, non-transparent tiles as same-species neighbors
- SLIPPERY: player travels in one cardinal direction until they hit an obstacle or non-slippery floor tile
  - uncontrollable velocity starts when player is only touching slippery-type tiles
  - direction is determined based on player's velocity at the moment they stop touching non-slippery tiles
  - player decelerates when they contact non-slippery tiles
  - consult legacy code for exact behavior
- FLICKER: tile disappears and reappears. flickers before disappearing
  - present-time and gone-time randomize. consult legacy code
- QUARTERED: tiles that are 0.5h and 0.5w of normal tiles

### Non-interactive Floor Tile Examples
- BORDERED (done): BNCentral base tile
- HIDDEN BORDERED: generic dark tile with glass top i.e. used in BNCentral.
  - Legacy glass shine visually flickered every other frame --> change to ~50% opacity, no flicker
- BORDERLESS GLOW: Bahoo floor tile
  - A special variant exists with a pulsing glow animation. hints at nearby hidden tiles/platforms. is effectively just Borderless
- BORDERED MOVER: BNCentral mover tile
- BORDERLESS MOVER: white mover tile present in most zones
- QUARTERED BORDERLESS MOVER: Bahoo has them
- DYNAMIC BORDERED MOVER: Floes of Ghennam icy water tiles
- BORDERED PLATFORM: BNCentral platforms
- BORDERLESS PLATFORM: Bahoo platforms
- HIDDEN BORDERED PLATFORM: also in most zones. same aesthetic as hidden bordered tile.
- DYNAMIC BORDERED: Floes of Ghennam snow tiles
- DYNAMIC BORDERED MOVER: Floes of Ghennam water tiles
- DYNAMIC SLIPPERY BORDERED: Floes of Ghennam ice tiles
- BORDERLESS FLICKER: White, prominently in Emptiness' Hull

## Interactive Floor Tiles
- HEXPORTER: Conduit for the "hexport" mode of travel
  - Can have any of up/down/left/right departure directions enabled. Player picks by facing that way before interacting
  - Can be a "station" for receiving incoming hexporting players
  - Can have no departure directions enabled-->station only
- HEXSLING: Forwards hexporting players in a new direction
  - Never a station, never a conduit
  - Can similarly have any of up/down/left/right directions enabled. Must have at least one
  - If only one or two directions, immediately sends the player in a new direction. Prefers whichever direction the player wasn't traveling
  - If 3 or 4 directions, pauses the player's hexport motion. Player chooses using directional input
- HEXBRIDGE: Floating cylinder
  - Acts like air in its default state. Cannot be walked on
  - Once a player has hexported to a hexbridge, it spawns a glowing energy tile around it. May then be walked on
  - As a hexport target, sends the player back in the direction from which they came
  - NOTE: Activation state is per-player. Player cannot see or walk on the hexbridges that other players have activated
- WARP: Intra-zone teleportation. Requires the `WrpPlugn` navi expansion
  - Does nothing without `WrpPlugn`
  - With the expansion, step on the glowing area (not just anywhere on the tile) to be warped to its destination. Consult legacy code for exact behavior
  - If its destination is another warp, that warp will not activate until the player first steps off
  - There's a "dead" version that serves as a 1-way warp destination
  - Any two connected warps are not necessarily connected both ways
  - Example A: warps in Bahoo use logical two-way connections
  - Example B: warps in Noiya are elusive, some send you somewhere different if you try to go back
- SPECTRAL GATE: Equip Spectrum Data. Requires the `MskPlugn` navi expansion
	- When player interacts, opens the spectrum menu for customizing their player sprite

-  - consult legacy code for exact acceleration behavior

+  - 5-8 tuning (pinned by recon): player `+2 / −1, cap 6` (~180 px/s peak); NPCs & data drops (`pcode_mover`) `+1.5 / −0.5, cap 5`


- movement needs to be client-driven but synced deterministically to server time, so all players see all platforms in the same locations at the same time.

  - movement needs to be client-driven but synced deterministically to server time, so all players see all platforms in the same locations at the same time.
  - **[ReBNO-INTENT]** legacy platforms are pure LOCAL sim (vspeed/hspeed ±3 px/step, `random(60)` end-pause), NOT synced — ReBNO must add the determinism (seed RNG / drive by server time)
  - **[ReBNO-INTENT]** ReBNO QoL: blink a departure tell (~5 blinks) before moving (needs a new per-platform animation)


  - movement needs to be client-driven but synced deterministically to server time, so all players see all platforms in the same locations at the same time.
  - **[ReBNO-INTENT]** legacy platforms are pure LOCAL sim (vspeed/hspeed ±3 px/step, `random(60)` end-pause), NOT synced — ReBNO must add the determinism (seed RNG / drive by server time)
  - **[ReBNO-INTENT]** ReBNO QoL: blink a departure tell (~5 blinks) before moving (needs a new per-platform animation)

# BNO LEGACY-->REBNO FEATURE TRIAGE

## Non-interactive Floor Tile Types
- BORDERED: player stops at edges, cannot walk off
- BORDERLESS: player can walk off and fall into the void
- HIDDEN: invisible by default. reveals when player collides, eventually times out and re-hides after collision ends
- GLOW: same player collision behavior as hidden, but always visible + transitions to and from glowing
- MOVER: applies acceleration to entities (players, NPCs, data item drops) up to a peak velocity
  - all forms can push player off the exiting end and into the void
  - variants: UP/LEFT/RIGHT/DOWN
  - 5-8 tuning (pinned by recon): player `+2 / −1, cap 6` (~180 px/s peak); NPCs & data drops (`pcode_mover`) `+1.5 / −0.5, cap 5`
- PLATFORM: moving platform carries entities with it
  - stops for some number of seconds at each end of its travel
  - currently only exhibits up/down or left/right movement patterns
  - movement needs to be client-driven but synced deterministically to server time, so all players see all platforms in the same locations at the same time.
- DYNAMIC: has neighbor-sensitive sprites and TSide sprites. variants:
  - LONE
  - TOP/LEFT/RIGHT/BOTTOM NEIGHBORED
  - T/L/R/B ENDPIECE
  - TL/TR/BR/BL CORNER
  - L+R BRIDGE
  - U+D BRIDGE
  - SURROUNDED
  - SPECIAL: if surrounded on two sides but missing the diagonal between those two, draws corner sprite art wherever such diagonals are missing. consult legacy code for exact behavior
  - NOTE: most patterned tiles treat other non-hidden, non-transparent tiles as same-species neighbors
- SLIPPERY: player travels in one cardinal direction until they hit an obstacle or non-slippery floor tile
  - uncontrollable velocity starts when player is only touching slippery-type tiles
  - direction is determined based on player's velocity at the moment they stop touching non-slippery tiles
  - player decelerates when they contact non-slippery tiles
  - consult legacy code for exact behavior
- FLICKER: tile disappears and reappears. flickers before disappearing
  - present-time and gone-time randomize. consult legacy code
- QUARTERED: tiles that are 0.5h and 0.5w of normal tiles

### Non-interactive Floor Tile Examples
- BORDERED (done): BNCentral base tile
- HIDDEN BORDERED: generic dark tile with glass top i.e. used in BNCentral.
  - Legacy glass shine visually flickered every other frame --> change to ~50% opacity, no flicker
- BORDERLESS GLOW: Bahoo floor tile
  - A special variant exists with a pulsing glow animation. hints at nearby hidden tiles/platforms. is effectively just Borderless
- BORDERED MOVER: BNCentral mover tile
- BORDERLESS MOVER: white mover tile present in most zones
- QUARTERED BORDERLESS MOVER: Bahoo has them
- DYNAMIC BORDERED MOVER: Floes of Ghennam icy water tiles
- BORDERED PLATFORM: BNCentral platforms
- BORDERLESS PLATFORM: Bahoo platforms
- HIDDEN BORDERED PLATFORM: also in most zones. same aesthetic as hidden bordered tile.
- DYNAMIC BORDERED: Floes of Ghennam snow tiles
- DYNAMIC BORDERED MOVER: Floes of Ghennam water tiles
- DYNAMIC SLIPPERY BORDERED: Floes of Ghennam ice tiles
- BORDERLESS FLICKER: White, prominently in Emptiness' Hull

## Interactive Floor Tiles
- HEXPORTER: Conduit for the "hexport" mode of travel
  - Can have any of up/down/left/right departure directions enabled. Player picks by facing that way before interacting
  - Can be a "station" for receiving incoming hexporting players
  - Can have no departure directions enabled-->station only
- HEXSLING: Forwards hexporting players in a new direction
  - Never a station, never a conduit
  - Can similarly have any of up/down/left/right directions enabled. Must have at least one
  - If only one or two directions, immediately sends the player in a new direction. Prefers whichever direction the player wasn't traveling
  - If 3 or 4 directions, pauses the player's hexport motion. Player chooses using directional input
- HEXBRIDGE: Floating cylinder
  - Acts like air in its default state. Cannot be walked on
  - Once a player has hexported to a hexbridge, it spawns a glowing energy tile around it. May then be walked on
  - As a hexport target, sends the player back in the direction from which they came
  - NOTE: Activation state is per-player. Player cannot see or walk on the hexbridges that other players have activated
- WARP: Intra-zone teleportation. Requires the `WrpPlugn` navi expansion
  - Does nothing without `WrpPlugn`
  - With the expansion, step on the glowing area (not just anywhere on the tile) to be warped to its destination. Consult legacy code for exact behavior
  - If its destination is another warp, that warp will not activate until the player first steps off
  - There's a "dead" version that serves as a 1-way warp destination
  - Any two connected warps are not necessarily connected both ways
  - Example A: warps in Bahoo use logical two-way connections
  - Example B: warps in Noiya are elusive, some send you somewhere different if you try to go back
- SPECTRAL GATE: Equip Spectrum Data. Requires the `MskPlugn` navi expansion
	- When player interacts, opens the spectrum menu for customizing their player sprite

+  - **[ReBNO-INTENT]** legacy platforms are pure LOCAL sim (vspeed/hspeed ±3 px/step, `random(60)` end-pause), NOT synced — ReBNO must add the determinism (seed RNG / drive by server time)

+  - **[ReBNO-INTENT]** ReBNO QoL: blink a departure tell (~5 blinks) before moving (needs a new per-platform animation)


- NOTE: most patterned tiles treat other non-hidden, non-transparent tiles as same-species neighbors

  - NOTE: most patterned tiles treat other non-hidden, non-transparent tiles as same-species neighbors
  - (5-8 reality: this is approximate — code uses explicit per-tile allow-lists in `cornercheckg` / `cornerchecki`; pin the exact lists when porting)


  - NOTE: most patterned tiles treat other non-hidden, non-transparent tiles as same-species neighbors
  - (5-8 reality: this is approximate — code uses explicit per-tile allow-lists in `cornercheckg` / `cornerchecki`; pin the exact lists when porting)

# BNO LEGACY-->REBNO FEATURE TRIAGE

## Non-interactive Floor Tile Types
- BORDERED: player stops at edges, cannot walk off
- BORDERLESS: player can walk off and fall into the void
- HIDDEN: invisible by default. reveals when player collides, eventually times out and re-hides after collision ends
- GLOW: same player collision behavior as hidden, but always visible + transitions to and from glowing
- MOVER: applies acceleration to entities (players, NPCs, data item drops) up to a peak velocity
  - all forms can push player off the exiting end and into the void
  - variants: UP/LEFT/RIGHT/DOWN
  - 5-8 tuning (pinned by recon): player `+2 / −1, cap 6` (~180 px/s peak); NPCs & data drops (`pcode_mover`) `+1.5 / −0.5, cap 5`
- PLATFORM: moving platform carries entities with it
  - stops for some number of seconds at each end of its travel
  - currently only exhibits up/down or left/right movement patterns
  - movement needs to be client-driven but synced deterministically to server time, so all players see all platforms in the same locations at the same time.
  - **[ReBNO-INTENT]** legacy platforms are pure LOCAL sim (vspeed/hspeed ±3 px/step, `random(60)` end-pause), NOT synced — ReBNO must add the determinism (seed RNG / drive by server time)
  - **[ReBNO-INTENT]** ReBNO QoL: blink a departure tell (~5 blinks) before moving (needs a new per-platform animation)
- DYNAMIC: has neighbor-sensitive sprites and TSide sprites. variants:
  - LONE
  - TOP/LEFT/RIGHT/BOTTOM NEIGHBORED
  - T/L/R/B ENDPIECE
  - TL/TR/BR/BL CORNER
  - L+R BRIDGE
  - U+D BRIDGE
  - SURROUNDED
  - SPECIAL: if surrounded on two sides but missing the diagonal between those two, draws corner sprite art wherever such diagonals are missing. consult legacy code for exact behavior
  - NOTE: most patterned tiles treat other non-hidden, non-transparent tiles as same-species neighbors
- SLIPPERY: player travels in one cardinal direction until they hit an obstacle or non-slippery floor tile
  - uncontrollable velocity starts when player is only touching slippery-type tiles
  - direction is determined based on player's velocity at the moment they stop touching non-slippery tiles
  - player decelerates when they contact non-slippery tiles
  - consult legacy code for exact behavior
- FLICKER: tile disappears and reappears. flickers before disappearing
  - present-time and gone-time randomize. consult legacy code
- QUARTERED: tiles that are 0.5h and 0.5w of normal tiles

### Non-interactive Floor Tile Examples
- BORDERED (done): BNCentral base tile
- HIDDEN BORDERED: generic dark tile with glass top i.e. used in BNCentral.
  - Legacy glass shine visually flickered every other frame --> change to ~50% opacity, no flicker
- BORDERLESS GLOW: Bahoo floor tile
  - A special variant exists with a pulsing glow animation. hints at nearby hidden tiles/platforms. is effectively just Borderless
- BORDERED MOVER: BNCentral mover tile
- BORDERLESS MOVER: white mover tile present in most zones
- QUARTERED BORDERLESS MOVER: Bahoo has them
- DYNAMIC BORDERED MOVER: Floes of Ghennam icy water tiles
- BORDERED PLATFORM: BNCentral platforms
- BORDERLESS PLATFORM: Bahoo platforms
- HIDDEN BORDERED PLATFORM: also in most zones. same aesthetic as hidden bordered tile.
- DYNAMIC BORDERED: Floes of Ghennam snow tiles
- DYNAMIC BORDERED MOVER: Floes of Ghennam water tiles
- DYNAMIC SLIPPERY BORDERED: Floes of Ghennam ice tiles
- BORDERLESS FLICKER: White, prominently in Emptiness' Hull

## Interactive Floor Tiles
- HEXPORTER: Conduit for the "hexport" mode of travel
  - Can have any of up/down/left/right departure directions enabled. Player picks by facing that way before interacting
  - Can be a "station" for receiving incoming hexporting players
  - Can have no departure directions enabled-->station only
- HEXSLING: Forwards hexporting players in a new direction
  - Never a station, never a conduit
  - Can similarly have any of up/down/left/right directions enabled. Must have at least one
  - If only one or two directions, immediately sends the player in a new direction. Prefers whichever direction the player wasn't traveling
  - If 3 or 4 directions, pauses the player's hexport motion. Player chooses using directional input
- HEXBRIDGE: Floating cylinder
  - Acts like air in its default state. Cannot be walked on
  - Once a player has hexported to a hexbridge, it spawns a glowing energy tile around it. May then be walked on
  - As a hexport target, sends the player back in the direction from which they came
  - NOTE: Activation state is per-player. Player cannot see or walk on the hexbridges that other players have activated
- WARP: Intra-zone teleportation. Requires the `WrpPlugn` navi expansion
  - Does nothing without `WrpPlugn`
  - With the expansion, step on the glowing area (not just anywhere on the tile) to be warped to its destination. Consult legacy code for exact behavior
  - If its destination is another warp, that warp will not activate until the player first steps off
  - There's a "dead" version that serves as a 1-way warp destination
  - Any two connected warps are not necessarily connected both ways
  - Example A: warps in Bahoo use logical two-way connections
  - Example B: warps in Noiya are elusive, some send you somewhere different if you try to go back
- SPECTRAL GATE: Equip Spectrum Data. Requires the `MskPlugn` navi expansion
	- When player interacts, opens the spectrum menu for customizing their player sprite

+  - (5-8 reality: this is approximate — code uses explicit per-tile allow-lists in `cornercheckg` / `cornerchecki`; pin the exact lists when porting)


- FLICKER: tile disappears and reappears. flickers before disappearing
  - present-time and gone-time randomize. consult legacy code

- FLICKER: tile disappears and reappears. flickers before disappearing
  - present-time and gone-time randomize. consult legacy code
  - **[ReBNO-INTENT for sync]** EXISTS in legacy (under a non-obvious object name, prominent in Emptiness' Hull) but is NOT server-synced; ReBNO must sync it deterministically. (recon: `.planning/legacy-recon/13-flicker-tile.md`)


- FLICKER: tile disappears and reappears. flickers before disappearing
  - present-time and gone-time randomize. consult legacy code
  - **[ReBNO-INTENT for sync]** EXISTS in legacy (under a non-obvious object name, prominent in Emptiness' Hull) but is NOT server-synced; ReBNO must sync it deterministically. (recon: `.planning/legacy-recon/13-flicker-tile.md`)

# BNO LEGACY-->REBNO FEATURE TRIAGE

## Non-interactive Floor Tile Types
- BORDERED: player stops at edges, cannot walk off
- BORDERLESS: player can walk off and fall into the void
- HIDDEN: invisible by default. reveals when player collides, eventually times out and re-hides after collision ends
- GLOW: same player collision behavior as hidden, but always visible + transitions to and from glowing
- MOVER: applies acceleration to entities (players, NPCs, data item drops) up to a peak velocity
  - all forms can push player off the exiting end and into the void
  - variants: UP/LEFT/RIGHT/DOWN
  - 5-8 tuning (pinned by recon): player `+2 / −1, cap 6` (~180 px/s peak); NPCs & data drops (`pcode_mover`) `+1.5 / −0.5, cap 5`
- PLATFORM: moving platform carries entities with it
  - stops for some number of seconds at each end of its travel
  - currently only exhibits up/down or left/right movement patterns
  - movement needs to be client-driven but synced deterministically to server time, so all players see all platforms in the same locations at the same time.
  - **[ReBNO-INTENT]** legacy platforms are pure LOCAL sim (vspeed/hspeed ±3 px/step, `random(60)` end-pause), NOT synced — ReBNO must add the determinism (seed RNG / drive by server time)
  - **[ReBNO-INTENT]** ReBNO QoL: blink a departure tell (~5 blinks) before moving (needs a new per-platform animation)
- DYNAMIC: has neighbor-sensitive sprites and TSide sprites. variants:
  - LONE
  - TOP/LEFT/RIGHT/BOTTOM NEIGHBORED
  - T/L/R/B ENDPIECE
  - TL/TR/BR/BL CORNER
  - L+R BRIDGE
  - U+D BRIDGE
  - SURROUNDED
  - SPECIAL: if surrounded on two sides but missing the diagonal between those two, draws corner sprite art wherever such diagonals are missing. consult legacy code for exact behavior
  - NOTE: most patterned tiles treat other non-hidden, non-transparent tiles as same-species neighbors
  - (5-8 reality: this is approximate — code uses explicit per-tile allow-lists in `cornercheckg` / `cornerchecki`; pin the exact lists when porting)
- SLIPPERY: player travels in one cardinal direction until they hit an obstacle or non-slippery floor tile
  - uncontrollable velocity starts when player is only touching slippery-type tiles
  - direction is determined based on player's velocity at the moment they stop touching non-slippery tiles
  - player decelerates when they contact non-slippery tiles
  - consult legacy code for exact behavior
- FLICKER: tile disappears and reappears. flickers before disappearing
  - present-time and gone-time randomize. consult legacy code
- QUARTERED: tiles that are 0.5h and 0.5w of normal tiles

### Non-interactive Floor Tile Examples
- BORDERED (done): BNCentral base tile
- HIDDEN BORDERED: generic dark tile with glass top i.e. used in BNCentral.
  - Legacy glass shine visually flickered every other frame --> change to ~50% opacity, no flicker
- BORDERLESS GLOW: Bahoo floor tile
  - A special variant exists with a pulsing glow animation. hints at nearby hidden tiles/platforms. is effectively just Borderless
- BORDERED MOVER: BNCentral mover tile
- BORDERLESS MOVER: white mover tile present in most zones
- QUARTERED BORDERLESS MOVER: Bahoo has them
- DYNAMIC BORDERED MOVER: Floes of Ghennam icy water tiles
- BORDERED PLATFORM: BNCentral platforms
- BORDERLESS PLATFORM: Bahoo platforms
- HIDDEN BORDERED PLATFORM: also in most zones. same aesthetic as hidden bordered tile.
- DYNAMIC BORDERED: Floes of Ghennam snow tiles
- DYNAMIC BORDERED MOVER: Floes of Ghennam water tiles
- DYNAMIC SLIPPERY BORDERED: Floes of Ghennam ice tiles
- BORDERLESS FLICKER: White, prominently in Emptiness' Hull

## Interactive Floor Tiles
- HEXPORTER: Conduit for the "hexport" mode of travel
  - Can have any of up/down/left/right departure directions enabled. Player picks by facing that way before interacting
  - Can be a "station" for receiving incoming hexporting players
  - Can have no departure directions enabled-->station only
- HEXSLING: Forwards hexporting players in a new direction
  - Never a station, never a conduit
  - Can similarly have any of up/down/left/right directions enabled. Must have at least one
  - If only one or two directions, immediately sends the player in a new direction. Prefers whichever direction the player wasn't traveling
  - If 3 or 4 directions, pauses the player's hexport motion. Player chooses using directional input
- HEXBRIDGE: Floating cylinder
  - Acts like air in its default state. Cannot be walked on
  - Once a player has hexported to a hexbridge, it spawns a glowing energy tile around it. May then be walked on
  - As a hexport target, sends the player back in the direction from which they came
  - NOTE: Activation state is per-player. Player cannot see or walk on the hexbridges that other players have activated
- WARP: Intra-zone teleportation. Requires the `WrpPlugn` navi expansion
  - Does nothing without `WrpPlugn`
  - With the expansion, step on the glowing area (not just anywhere on the tile) to be warped to its destination. Consult legacy code for exact behavior
  - If its destination is another warp, that warp will not activate until the player first steps off
  - There's a "dead" version that serves as a 1-way warp destination
  - Any two connected warps are not necessarily connected both ways
  - Example A: warps in Bahoo use logical two-way connections
  - Example B: warps in Noiya are elusive, some send you somewhere different if you try to go back
- SPECTRAL GATE: Equip Spectrum Data. Requires the `MskPlugn` navi expansion
	- When player interacts, opens the spectrum menu for customizing their player sprite

+  - **[ReBNO-INTENT for sync]** EXISTS in legacy (under a non-obvious object name, prominent in Emptiness' Hull) but is NOT server-synced; ReBNO must sync it deterministically. (recon: `.planning/legacy-recon/13-flicker-tile.md`)


- QUARTERED: tiles that are 0.5h and 0.5w of normal tiles

- QUARTERED: tiles that are 0.5h and 0.5w of normal tiles
  - (5-8: `btilemini` / BahooTileMini = 22×20 px — ½×½ of 44×40. NB the object literally named `qtile` is full-size, NOT the quartered one)


- QUARTERED: tiles that are 0.5h and 0.5w of normal tiles
  - (5-8: `btilemini` / BahooTileMini = 22×20 px — ½×½ of 44×40. NB the object literally named `qtile` is full-size, NOT the quartered one)

# BNO LEGACY-->REBNO FEATURE TRIAGE

## Non-interactive Floor Tile Types
- BORDERED: player stops at edges, cannot walk off
- BORDERLESS: player can walk off and fall into the void
- HIDDEN: invisible by default. reveals when player collides, eventually times out and re-hides after collision ends
- GLOW: same player collision behavior as hidden, but always visible + transitions to and from glowing
- MOVER: applies acceleration to entities (players, NPCs, data item drops) up to a peak velocity
  - all forms can push player off the exiting end and into the void
  - variants: UP/LEFT/RIGHT/DOWN
  - 5-8 tuning (pinned by recon): player `+2 / −1, cap 6` (~180 px/s peak); NPCs & data drops (`pcode_mover`) `+1.5 / −0.5, cap 5`
- PLATFORM: moving platform carries entities with it
  - stops for some number of seconds at each end of its travel
  - currently only exhibits up/down or left/right movement patterns
  - movement needs to be client-driven but synced deterministically to server time, so all players see all platforms in the same locations at the same time.
  - **[ReBNO-INTENT]** legacy platforms are pure LOCAL sim (vspeed/hspeed ±3 px/step, `random(60)` end-pause), NOT synced — ReBNO must add the determinism (seed RNG / drive by server time)
  - **[ReBNO-INTENT]** ReBNO QoL: blink a departure tell (~5 blinks) before moving (needs a new per-platform animation)
- DYNAMIC: has neighbor-sensitive sprites and TSide sprites. variants:
  - LONE
  - TOP/LEFT/RIGHT/BOTTOM NEIGHBORED
  - T/L/R/B ENDPIECE
  - TL/TR/BR/BL CORNER
  - L+R BRIDGE
  - U+D BRIDGE
  - SURROUNDED
  - SPECIAL: if surrounded on two sides but missing the diagonal between those two, draws corner sprite art wherever such diagonals are missing. consult legacy code for exact behavior
  - NOTE: most patterned tiles treat other non-hidden, non-transparent tiles as same-species neighbors
  - (5-8 reality: this is approximate — code uses explicit per-tile allow-lists in `cornercheckg` / `cornerchecki`; pin the exact lists when porting)
- SLIPPERY: player travels in one cardinal direction until they hit an obstacle or non-slippery floor tile
  - uncontrollable velocity starts when player is only touching slippery-type tiles
  - direction is determined based on player's velocity at the moment they stop touching non-slippery tiles
  - player decelerates when they contact non-slippery tiles
  - consult legacy code for exact behavior
- FLICKER: tile disappears and reappears. flickers before disappearing
  - present-time and gone-time randomize. consult legacy code
  - **[ReBNO-INTENT for sync]** EXISTS in legacy (under a non-obvious object name, prominent in Emptiness' Hull) but is NOT server-synced; ReBNO must sync it deterministically. (recon: `.planning/legacy-recon/13-flicker-tile.md`)
- QUARTERED: tiles that are 0.5h and 0.5w of normal tiles

### Non-interactive Floor Tile Examples
- BORDERED (done): BNCentral base tile
- HIDDEN BORDERED: generic dark tile with glass top i.e. used in BNCentral.
  - Legacy glass shine visually flickered every other frame --> change to ~50% opacity, no flicker
- BORDERLESS GLOW: Bahoo floor tile
  - A special variant exists with a pulsing glow animation. hints at nearby hidden tiles/platforms. is effectively just Borderless
- BORDERED MOVER: BNCentral mover tile
- BORDERLESS MOVER: white mover tile present in most zones
- QUARTERED BORDERLESS MOVER: Bahoo has them
- DYNAMIC BORDERED MOVER: Floes of Ghennam icy water tiles
- BORDERED PLATFORM: BNCentral platforms
- BORDERLESS PLATFORM: Bahoo platforms
- HIDDEN BORDERED PLATFORM: also in most zones. same aesthetic as hidden bordered tile.
- DYNAMIC BORDERED: Floes of Ghennam snow tiles
- DYNAMIC BORDERED MOVER: Floes of Ghennam water tiles
- DYNAMIC SLIPPERY BORDERED: Floes of Ghennam ice tiles
- BORDERLESS FLICKER: White, prominently in Emptiness' Hull

## Interactive Floor Tiles
- HEXPORTER: Conduit for the "hexport" mode of travel
  - Can have any of up/down/left/right departure directions enabled. Player picks by facing that way before interacting
  - Can be a "station" for receiving incoming hexporting players
  - Can have no departure directions enabled-->station only
- HEXSLING: Forwards hexporting players in a new direction
  - Never a station, never a conduit
  - Can similarly have any of up/down/left/right directions enabled. Must have at least one
  - If only one or two directions, immediately sends the player in a new direction. Prefers whichever direction the player wasn't traveling
  - If 3 or 4 directions, pauses the player's hexport motion. Player chooses using directional input
- HEXBRIDGE: Floating cylinder
  - Acts like air in its default state. Cannot be walked on
  - Once a player has hexported to a hexbridge, it spawns a glowing energy tile around it. May then be walked on
  - As a hexport target, sends the player back in the direction from which they came
  - NOTE: Activation state is per-player. Player cannot see or walk on the hexbridges that other players have activated
- WARP: Intra-zone teleportation. Requires the `WrpPlugn` navi expansion
  - Does nothing without `WrpPlugn`
  - With the expansion, step on the glowing area (not just anywhere on the tile) to be warped to its destination. Consult legacy code for exact behavior
  - If its destination is another warp, that warp will not activate until the player first steps off
  - There's a "dead" version that serves as a 1-way warp destination
  - Any two connected warps are not necessarily connected both ways
  - Example A: warps in Bahoo use logical two-way connections
  - Example B: warps in Noiya are elusive, some send you somewhere different if you try to go back
- SPECTRAL GATE: Equip Spectrum Data. Requires the `MskPlugn` navi expansion
	- When player interacts, opens the spectrum menu for customizing their player sprite

+  - (5-8: `btilemini` / BahooTileMini = 22×20 px — ½×½ of 44×40. NB the object literally named `qtile` is full-size, NOT the quartered one)


- Legacy glass shine visually flickered every other frame --> change to ~50% opacity, no flicker

  - Legacy glass shine visually flickered every other frame --> change to ~50% opacity, no flicker
  - **[ReBNO-INTENT]** legacy `hiddentile` has BOTH a 50%-opacity path and a blink path; ReBNO standardizes on always-50%, no blink


  - Legacy glass shine visually flickered every other frame --> change to ~50% opacity, no flicker
  - **[ReBNO-INTENT]** legacy `hiddentile` has BOTH a 50%-opacity path and a blink path; ReBNO standardizes on always-50%, no blink

# BNO LEGACY-->REBNO FEATURE TRIAGE

## Non-interactive Floor Tile Types
- BORDERED: player stops at edges, cannot walk off
- BORDERLESS: player can walk off and fall into the void
- HIDDEN: invisible by default. reveals when player collides, eventually times out and re-hides after collision ends
- GLOW: same player collision behavior as hidden, but always visible + transitions to and from glowing
- MOVER: applies acceleration to entities (players, NPCs, data item drops) up to a peak velocity
  - all forms can push player off the exiting end and into the void
  - variants: UP/LEFT/RIGHT/DOWN
  - 5-8 tuning (pinned by recon): player `+2 / −1, cap 6` (~180 px/s peak); NPCs & data drops (`pcode_mover`) `+1.5 / −0.5, cap 5`
- PLATFORM: moving platform carries entities with it
  - stops for some number of seconds at each end of its travel
  - currently only exhibits up/down or left/right movement patterns
  - movement needs to be client-driven but synced deterministically to server time, so all players see all platforms in the same locations at the same time.
  - **[ReBNO-INTENT]** legacy platforms are pure LOCAL sim (vspeed/hspeed ±3 px/step, `random(60)` end-pause), NOT synced — ReBNO must add the determinism (seed RNG / drive by server time)
  - **[ReBNO-INTENT]** ReBNO QoL: blink a departure tell (~5 blinks) before moving (needs a new per-platform animation)
- DYNAMIC: has neighbor-sensitive sprites and TSide sprites. variants:
  - LONE
  - TOP/LEFT/RIGHT/BOTTOM NEIGHBORED
  - T/L/R/B ENDPIECE
  - TL/TR/BR/BL CORNER
  - L+R BRIDGE
  - U+D BRIDGE
  - SURROUNDED
  - SPECIAL: if surrounded on two sides but missing the diagonal between those two, draws corner sprite art wherever such diagonals are missing. consult legacy code for exact behavior
  - NOTE: most patterned tiles treat other non-hidden, non-transparent tiles as same-species neighbors
  - (5-8 reality: this is approximate — code uses explicit per-tile allow-lists in `cornercheckg` / `cornerchecki`; pin the exact lists when porting)
- SLIPPERY: player travels in one cardinal direction until they hit an obstacle or non-slippery floor tile
  - uncontrollable velocity starts when player is only touching slippery-type tiles
  - direction is determined based on player's velocity at the moment they stop touching non-slippery tiles
  - player decelerates when they contact non-slippery tiles
  - consult legacy code for exact behavior
- FLICKER: tile disappears and reappears. flickers before disappearing
  - present-time and gone-time randomize. consult legacy code
  - **[ReBNO-INTENT for sync]** EXISTS in legacy (under a non-obvious object name, prominent in Emptiness' Hull) but is NOT server-synced; ReBNO must sync it deterministically. (recon: `.planning/legacy-recon/13-flicker-tile.md`)
- QUARTERED: tiles that are 0.5h and 0.5w of normal tiles
  - (5-8: `btilemini` / BahooTileMini = 22×20 px — ½×½ of 44×40. NB the object literally named `qtile` is full-size, NOT the quartered one)

### Non-interactive Floor Tile Examples
- BORDERED (done): BNCentral base tile
- HIDDEN BORDERED: generic dark tile with glass top i.e. used in BNCentral.
  - Legacy glass shine visually flickered every other frame --> change to ~50% opacity, no flicker
- BORDERLESS GLOW: Bahoo floor tile
  - A special variant exists with a pulsing glow animation. hints at nearby hidden tiles/platforms. is effectively just Borderless
- BORDERED MOVER: BNCentral mover tile
- BORDERLESS MOVER: white mover tile present in most zones
- QUARTERED BORDERLESS MOVER: Bahoo has them
- DYNAMIC BORDERED MOVER: Floes of Ghennam icy water tiles
- BORDERED PLATFORM: BNCentral platforms
- BORDERLESS PLATFORM: Bahoo platforms
- HIDDEN BORDERED PLATFORM: also in most zones. same aesthetic as hidden bordered tile.
- DYNAMIC BORDERED: Floes of Ghennam snow tiles
- DYNAMIC BORDERED MOVER: Floes of Ghennam water tiles
- DYNAMIC SLIPPERY BORDERED: Floes of Ghennam ice tiles
- BORDERLESS FLICKER: White, prominently in Emptiness' Hull

## Interactive Floor Tiles
- HEXPORTER: Conduit for the "hexport" mode of travel
  - Can have any of up/down/left/right departure directions enabled. Player picks by facing that way before interacting
  - Can be a "station" for receiving incoming hexporting players
  - Can have no departure directions enabled-->station only
- HEXSLING: Forwards hexporting players in a new direction
  - Never a station, never a conduit
  - Can similarly have any of up/down/left/right directions enabled. Must have at least one
  - If only one or two directions, immediately sends the player in a new direction. Prefers whichever direction the player wasn't traveling
  - If 3 or 4 directions, pauses the player's hexport motion. Player chooses using directional input
- HEXBRIDGE: Floating cylinder
  - Acts like air in its default state. Cannot be walked on
  - Once a player has hexported to a hexbridge, it spawns a glowing energy tile around it. May then be walked on
  - As a hexport target, sends the player back in the direction from which they came
  - NOTE: Activation state is per-player. Player cannot see or walk on the hexbridges that other players have activated
- WARP: Intra-zone teleportation. Requires the `WrpPlugn` navi expansion
  - Does nothing without `WrpPlugn`
  - With the expansion, step on the glowing area (not just anywhere on the tile) to be warped to its destination. Consult legacy code for exact behavior
  - If its destination is another warp, that warp will not activate until the player first steps off
  - There's a "dead" version that serves as a 1-way warp destination
  - Any two connected warps are not necessarily connected both ways
  - Example A: warps in Bahoo use logical two-way connections
  - Example B: warps in Noiya are elusive, some send you somewhere different if you try to go back
- SPECTRAL GATE: Equip Spectrum Data. Requires the `MskPlugn` navi expansion
	- When player interacts, opens the spectrum menu for customizing their player sprite

+  - **[ReBNO-INTENT]** legacy `hiddentile` has BOTH a 50%-opacity path and a blink path; ReBNO standardizes on always-50%, no blink


<task-notification>
<task-id>a81c5cf178f395d4f</task-id>
<tool-use-id>toolu_019zGusDdbHhWhv6QAE49TTC</tool-use-id>
<output-file>C:\Users\decid\AppData\Local\Temp\claude\C--Users-decid-Documents-projects-rebno\27ced91a-de41-488a-b2a2-10f1c09be4bb\tasks\a81c5cf178f395d4f.output</output-file>
<status>completed</status>
<summary>Agent "Recon: find flicker tile object" completed</summary>
<result>FOUND IT — the prior passes were wrong. Report written to `.planning/legacy-recon/13-flicker-tile.md`.

**Object name: `magictile`** (object id 467, sprite 928 `MagicTile`). Not named anything flicker-ish, which is why two passes missed it; `hiddentile` (id 121) was the likely decoy.

- **Borderless white**: confirmed at the pixel level — `MagicTile` is 44×40, every opaque pixel is pure white (255,255,255), rest is GameMaker magenta transparency-key. No border ring. (The grey `whitetile` id 119 is the static bordered floor — likely what got conflated before.)
- **Behavior** (room speed 30 fps): Present **45–75 steps** (`ceil(random(30))+45`, randomized) → **flicker tell** = 30 on/off toggles over **1.0 s** (`alarm[0]=1` each step, ~15 Hz strobe) → **Gone 30–60 steps** (`ceil(random(30))+30`, randomized) → loops. Collision mask swaps `Tile1`↔`sprite44` so the floor is genuinely passable while gone.
- **Sync: LOCAL / UNSYNCED.** Driven entirely by client-side `alarm[]` + client `random()`; no packet read/write, only referenced by its own object and `tileborder` helper. Needs ReBNO server-authoritative present/gone state — otherwise peers see solid/gone at different moments.
- **Emptiness' Hull placement**: room `0048-Emptiness_Hull` (zone 3), **35 `magictile` instances** — a prominent deliberate hazard set, matching the owner.

Evidence: `objects/0467-magictile/events/{Create,Alarm,Alarm-1}.gml` (logic), `Alarm.dnd.json` (verified transcompile is faithful), `sprites/0928-MagicTile/frames/img_000.bmp` (white/borderless), `rooms/0048-Emptiness_Hull/instances.json` (×35), `scripts/0085-tileborder.gml` (only other reference — not networking).</result>
<usage><subagent_tokens>45849</subagent_tokens><tool_uses>20</tool_uses><duration_ms>148876</duration_ms></usage>
</task-notification>


Hexsling drift fix:


  - If only one or two directions, immediately sends the player in a new direction. Prefers whichever direction the player wasn't traveling
  - If 3 or 4 directions, pauses the player's hexport motion. Player chooses using directional input

  - 5-8 actual (ReBNO ports as-is): only **exactly one** enabled direction auto-sends (fixed priority up>down>left>right); **two or more** pause the orb and wait for the player's directional input
  - (the earlier "prefers whichever direction the player wasn't traveling" was inaccurate for 5-8 — that reversal is the HEXBRIDGE zero-arrow bounce, a different object)


  - 5-8 actual (ReBNO ports as-is): only **exactly one** enabled direction auto-sends (fixed priority up>down>left>right); **two or more** pause the orb and wait for the player's directional input
  - (the earlier "prefers whichever direction the player wasn't traveling" was inaccurate for 5-8 — that reversal is the HEXBRIDGE zero-arrow bounce, a different object)

# BNO LEGACY-->REBNO FEATURE TRIAGE

## Non-interactive Floor Tile Types
- BORDERED: player stops at edges, cannot walk off
- BORDERLESS: player can walk off and fall into the void
- HIDDEN: invisible by default. reveals when player collides, eventually times out and re-hides after collision ends
- GLOW: same player collision behavior as hidden, but always visible + transitions to and from glowing
- MOVER: applies acceleration to entities (players, NPCs, data item drops) up to a peak velocity
  - all forms can push player off the exiting end and into the void
  - variants: UP/LEFT/RIGHT/DOWN
  - 5-8 tuning (pinned by recon): player `+2 / −1, cap 6` (~180 px/s peak); NPCs & data drops (`pcode_mover`) `+1.5 / −0.5, cap 5`
- PLATFORM: moving platform carries entities with it
  - stops for some number of seconds at each end of its travel
  - currently only exhibits up/down or left/right movement patterns
  - movement needs to be client-driven but synced deterministically to server time, so all players see all platforms in the same locations at the same time.
  - **[ReBNO-INTENT]** legacy platforms are pure LOCAL sim (vspeed/hspeed ±3 px/step, `random(60)` end-pause), NOT synced — ReBNO must add the determinism (seed RNG / drive by server time)
  - **[ReBNO-INTENT]** ReBNO QoL: blink a departure tell (~5 blinks) before moving (needs a new per-platform animation)
- DYNAMIC: has neighbor-sensitive sprites and TSide sprites. variants:
  - LONE
  - TOP/LEFT/RIGHT/BOTTOM NEIGHBORED
  - T/L/R/B ENDPIECE
  - TL/TR/BR/BL CORNER
  - L+R BRIDGE
  - U+D BRIDGE
  - SURROUNDED
  - SPECIAL: if surrounded on two sides but missing the diagonal between those two, draws corner sprite art wherever such diagonals are missing. consult legacy code for exact behavior
  - NOTE: most patterned tiles treat other non-hidden, non-transparent tiles as same-species neighbors
  - (5-8 reality: this is approximate — code uses explicit per-tile allow-lists in `cornercheckg` / `cornerchecki`; pin the exact lists when porting)
- SLIPPERY: player travels in one cardinal direction until they hit an obstacle or non-slippery floor tile
  - uncontrollable velocity starts when player is only touching slippery-type tiles
  - direction is determined based on player's velocity at the moment they stop touching non-slippery tiles
  - player decelerates when they contact non-slippery tiles
  - consult legacy code for exact behavior
- FLICKER: tile disappears and reappears. flickers before disappearing
  - present-time and gone-time randomize. consult legacy code
  - **[ReBNO-INTENT for sync]** EXISTS in legacy (under a non-obvious object name, prominent in Emptiness' Hull) but is NOT server-synced; ReBNO must sync it deterministically. (recon: `.planning/legacy-recon/13-flicker-tile.md`)
- QUARTERED: tiles that are 0.5h and 0.5w of normal tiles
  - (5-8: `btilemini` / BahooTileMini = 22×20 px — ½×½ of 44×40. NB the object literally named `qtile` is full-size, NOT the quartered one)

### Non-interactive Floor Tile Examples
- BORDERED (done): BNCentral base tile
- HIDDEN BORDERED: generic dark tile with glass top i.e. used in BNCentral.
  - Legacy glass shine visually flickered every other frame --> change to ~50% opacity, no flicker
  - **[ReBNO-INTENT]** legacy `hiddentile` has BOTH a 50%-opacity path and a blink path; ReBNO standardizes on always-50%, no blink
- BORDERLESS GLOW: Bahoo floor tile
  - A special variant exists with a pulsing glow animation. hints at nearby hidden tiles/platforms. is effectively just Borderless
- BORDERED MOVER: BNCentral mover tile
- BORDERLESS MOVER: white mover tile present in most zones
- QUARTERED BORDERLESS MOVER: Bahoo has them
- DYNAMIC BORDERED MOVER: Floes of Ghennam icy water tiles
- BORDERED PLATFORM: BNCentral platforms
- BORDERLESS PLATFORM: Bahoo platforms
- HIDDEN BORDERED PLATFORM: also in most zones. same aesthetic as hidden bordered tile.
- DYNAMIC BORDERED: Floes of Ghennam snow tiles
- DYNAMIC BORDERED MOVER: Floes of Ghennam water tiles
- DYNAMIC SLIPPERY BORDERED: Floes of Ghennam ice tiles
- BORDERLESS FLICKER: White, prominently in Emptiness' Hull

## Interactive Floor Tiles
- HEXPORTER: Conduit for the "hexport" mode of travel
  - Can have any of up/down/left/right departure directions enabled. Player picks by facing that way before interacting
  - Can be a "station" for receiving incoming hexporting players
  - Can have no departure directions enabled-->station only
- HEXSLING: Forwards hexporting players in a new direction
  - Never a station, never a conduit
  - Can similarly have any of up/down/left/right directions enabled. Must have at least one
  - If only one or two directions, immediately sends the player in a new direction. Prefers whichever direction the player wasn't traveling
  - If 3 or 4 directions, pauses the player's hexport motion. Player chooses using directional input
- HEXBRIDGE: Floating cylinder
  - Acts like air in its default state. Cannot be walked on
  - Once a player has hexported to a hexbridge, it spawns a glowing energy tile around it. May then be walked on
  - As a hexport target, sends the player back in the direction from which they came
  - NOTE: Activation state is per-player. Player cannot see or walk on the hexbridges that other players have activated
- WARP: Intra-zone teleportation. Requires the `WrpPlugn` navi expansion
  - Does nothing without `WrpPlugn`
  - With the expansion, step on the glowing area (not just anywhere on the tile) to be warped to its destination. Consult legacy code for exact behavior
  - If its destination is another warp, that warp will not activate until the player first steps off
  - There's a "dead" version that serves as a 1-way warp destination
  - Any two connected warps are not necessarily connected both ways
  - Example A: warps in Bahoo use logical two-way connections
  - Example B: warps in Noiya are elusive, some send you somewhere different if you try to go back
- SPECTRAL GATE: Equip Spectrum Data. Requires the `MskPlugn` navi expansion
	- When player interacts, opens the spectrum menu for customizing their player sprite

-  - If only one or two directions, immediately sends the player in a new direction. Prefers whichever direction the player wasn't traveling

-  - If 3 or 4 directions, pauses the player's hexport motion. Player chooses using directional input

+  - 5-8 actual (ReBNO ports as-is): only **exactly one** enabled direction auto-sends (fixed priority up>down>left>right); **two or more** pause the orb and wait for the player's directional input

+  - (the earlier "prefers whichever direction the player wasn't traveling" was inaccurate for 5-8 — that reversal is the HEXBRIDGE zero-arrow bounce, a different object)


Prompt:
<task-notification>
<task-id>a81c5cf178f395d4f</task-id>
<tool-use-id>toolu_019zGusDdbHhWhv6QAE49TTC</tool-use-id>
<output-file>C:\Users\decid\AppData\Local\Temp\claude\C--Users-decid-Documents-projects-rebno\27ced91a-de41-488a-b2a2-10f1c09be4bb\tasks\a81c5cf178f395d4f.output</output-file>
<status>completed</status>
<summary>Agent "Recon: find flicker tile object" completed</summary>
<result>FOUND IT — the prior passes were wrong. Report written to `.planning/legacy-recon/13-flicker-tile.md`.

**Object name: `magictile`** (object id 467, sprite 928 `MagicTile`). Not named anything flicker-ish, which is why two passes missed it; `hiddentile` (id 121) was the likely decoy.

- **Borderless white**: confirmed at the pixel level — `MagicTile` is 44×40, every opaque pixel is pure white (255,255,255), rest is GameMaker magenta transparency-key. No border ring. (The grey `whitetile` id 119 is the static bordered floor — likely what got conflated before.)
- **Behavior** (room speed 30 fps): Present **45–75 steps** (`ceil(random(30))+45`, randomized) → **flicker tell** = 30 on/off toggles over **1.0 s** (`alarm[0]=1` each step, ~15 Hz strobe) → **Gone 30–60 steps** (`ceil(random(30))+30`, randomized) → loops. Collision mask swaps `Tile1`↔`sprite44` so the floor is genuinely passable while gone.
- **Sync: LOCAL / UNSYNCED.** Driven entirely by client-side `alarm[]` + client `random()`; no packet read/write, only referenced by its own object and `tileborder` helper. Needs ReBNO server-authoritative present/gone state — otherwise peers see solid/gone at different moments.
- **Emptiness' Hull placement**: room `0048-Emptiness_Hull` (zone 3), **35 `magictile` instances** — a prominent deliberate hazard set, matching the owner.

Evidence: `objects/0467-magictile/events/{Create,Alarm,Alarm-1}.gml` (logic), `Alarm.dnd.json` (verified transcompile is faithful), `sprites/0928-MagicTile/frames/img_000.bmp` (white/borderless), `rooms/0048-Emptiness_Hull/instances.json` (×35), `scripts/0085-tileborder.gml` (only other reference — not networking).</result>
<usage><subagent_tokens>45849</subagent_tokens><tool_uses>20</tool_uses><duration_ms>148876</duration_ms></usage>
</task-notification>


Flicker **found: `magictile`** (obj 467) — borderless white, present 45–75 steps → ~1 s strobe tell → gone 30–60 steps, **35 instances in Emptiness' Hull**, client-`random()` **local/unsynced**. So: legacy-real, ReBNO must server-sync it. Pinning the object + numbers in the doc, then committing the whole reconcile batch:


  - present-time and gone-time randomize. consult legacy code
  - **[ReBNO-INTENT for sync]** EXISTS in legacy (under a non-obvious object name, prominent in Emptiness' Hull) but is NOT server-synced; ReBNO must sync it deterministically. (recon: `.planning/legacy-recon/13-flicker-tile.md`)

  - 5-8: object **`magictile`** (borderless white, 44×40). Present 45–75 steps → ~1.0 s flicker tell (~15 Hz strobe) → gone 30–60 steps → loops; collision is passable while gone
  - **[ReBNO-INTENT for sync]** EXISTS in legacy as `magictile` (35 instances in Emptiness' Hull) but driven by client-side `random()` — LOCAL/unsynced; ReBNO must drive present/gone deterministically server-side. (recon: `.planning/legacy-recon/13-flicker-tile.md`)


  - 5-8: object **`magictile`** (borderless white, 44×40). Present 45–75 steps → ~1.0 s flicker tell (~15 Hz strobe) → gone 30–60 steps → loops; collision is passable while gone
  - **[ReBNO-INTENT for sync]** EXISTS in legacy as `magictile` (35 instances in Emptiness' Hull) but driven by client-side `random()` — LOCAL/unsynced; ReBNO must drive present/gone deterministically server-side. (recon: `.planning/legacy-recon/13-flicker-tile.md`)

# BNO LEGACY-->REBNO FEATURE TRIAGE

## Non-interactive Floor Tile Types
- BORDERED: player stops at edges, cannot walk off
- BORDERLESS: player can walk off and fall into the void
- HIDDEN: invisible by default. reveals when player collides, eventually times out and re-hides after collision ends
- GLOW: same player collision behavior as hidden, but always visible + transitions to and from glowing
- MOVER: applies acceleration to entities (players, NPCs, data item drops) up to a peak velocity
  - all forms can push player off the exiting end and into the void
  - variants: UP/LEFT/RIGHT/DOWN
  - 5-8 tuning (pinned by recon): player `+2 / −1, cap 6` (~180 px/s peak); NPCs & data drops (`pcode_mover`) `+1.5 / −0.5, cap 5`
- PLATFORM: moving platform carries entities with it
  - stops for some number of seconds at each end of its travel
  - currently only exhibits up/down or left/right movement patterns
  - movement needs to be client-driven but synced deterministically to server time, so all players see all platforms in the same locations at the same time.
  - **[ReBNO-INTENT]** legacy platforms are pure LOCAL sim (vspeed/hspeed ±3 px/step, `random(60)` end-pause), NOT synced — ReBNO must add the determinism (seed RNG / drive by server time)
  - **[ReBNO-INTENT]** ReBNO QoL: blink a departure tell (~5 blinks) before moving (needs a new per-platform animation)
- DYNAMIC: has neighbor-sensitive sprites and TSide sprites. variants:
  - LONE
  - TOP/LEFT/RIGHT/BOTTOM NEIGHBORED
  - T/L/R/B ENDPIECE
  - TL/TR/BR/BL CORNER
  - L+R BRIDGE
  - U+D BRIDGE
  - SURROUNDED
  - SPECIAL: if surrounded on two sides but missing the diagonal between those two, draws corner sprite art wherever such diagonals are missing. consult legacy code for exact behavior
  - NOTE: most patterned tiles treat other non-hidden, non-transparent tiles as same-species neighbors
  - (5-8 reality: this is approximate — code uses explicit per-tile allow-lists in `cornercheckg` / `cornerchecki`; pin the exact lists when porting)
- SLIPPERY: player travels in one cardinal direction until they hit an obstacle or non-slippery floor tile
  - uncontrollable velocity starts when player is only touching slippery-type tiles
  - direction is determined based on player's velocity at the moment they stop touching non-slippery tiles
  - player decelerates when they contact non-slippery tiles
  - consult legacy code for exact behavior
- FLICKER: tile disappears and reappears. flickers before disappearing
  - present-time and gone-time randomize. consult legacy code
  - **[ReBNO-INTENT for sync]** EXISTS in legacy (under a non-obvious object name, prominent in Emptiness' Hull) but is NOT server-synced; ReBNO must sync it deterministically. (recon: `.planning/legacy-recon/13-flicker-tile.md`)
- QUARTERED: tiles that are 0.5h and 0.5w of normal tiles
  - (5-8: `btilemini` / BahooTileMini = 22×20 px — ½×½ of 44×40. NB the object literally named `qtile` is full-size, NOT the quartered one)

### Non-interactive Floor Tile Examples
- BORDERED (done): BNCentral base tile
- HIDDEN BORDERED: generic dark tile with glass top i.e. used in BNCentral.
  - Legacy glass shine visually flickered every other frame --> change to ~50% opacity, no flicker
  - **[ReBNO-INTENT]** legacy `hiddentile` has BOTH a 50%-opacity path and a blink path; ReBNO standardizes on always-50%, no blink
- BORDERLESS GLOW: Bahoo floor tile
  - A special variant exists with a pulsing glow animation. hints at nearby hidden tiles/platforms. is effectively just Borderless
- BORDERED MOVER: BNCentral mover tile
- BORDERLESS MOVER: white mover tile present in most zones
- QUARTERED BORDERLESS MOVER: Bahoo has them
- DYNAMIC BORDERED MOVER: Floes of Ghennam icy water tiles
- BORDERED PLATFORM: BNCentral platforms
- BORDERLESS PLATFORM: Bahoo platforms
- HIDDEN BORDERED PLATFORM: also in most zones. same aesthetic as hidden bordered tile.
- DYNAMIC BORDERED: Floes of Ghennam snow tiles
- DYNAMIC BORDERED MOVER: Floes of Ghennam water tiles
- DYNAMIC SLIPPERY BORDERED: Floes of Ghennam ice tiles
- BORDERLESS FLICKER: White, prominently in Emptiness' Hull

## Interactive Floor Tiles
- HEXPORTER: Conduit for the "hexport" mode of travel
  - Can have any of up/down/left/right departure directions enabled. Player picks by facing that way before interacting
  - Can be a "station" for receiving incoming hexporting players
  - Can have no departure directions enabled-->station only
- HEXSLING: Forwards hexporting players in a new direction
  - Never a station, never a conduit
  - Can similarly have any of up/down/left/right directions enabled. Must have at least one
  - 5-8 actual (ReBNO ports as-is): only **exactly one** enabled direction auto-sends (fixed priority up>down>left>right); **two or more** pause the orb and wait for the player's directional input
  - (the earlier "prefers whichever direction the player wasn't traveling" was inaccurate for 5-8 — that reversal is the HEXBRIDGE zero-arrow bounce, a different object)
- HEXBRIDGE: Floating cylinder
  - Acts like air in its default state. Cannot be walked on
  - Once a player has hexported to a hexbridge, it spawns a glowing energy tile around it. May then be walked on
  - As a hexport target, sends the player back in the direction from which they came
  - NOTE: Activation state is per-player. Player cannot see or walk on the hexbridges that other players have activated
- WARP: Intra-zone teleportation. Requires the `WrpPlugn` navi expansion
  - Does nothing without `WrpPlugn`
  - With the expansion, step on the glowing area (not just anywhere on the tile) to be warped to its destination. Consult legacy code for exact behavior
  - If its destination is another warp, that warp will not activate until the player first steps off
  - There's a "dead" version that serves as a 1-way warp destination
  - Any two connected warps are not necessarily connected both ways
  - Example A: warps in Bahoo use logical two-way connections
  - Example B: warps in Noiya are elusive, some send you somewhere different if you try to go back
- SPECTRAL GATE: Equip Spectrum Data. Requires the `MskPlugn` navi expansion
	- When player interacts, opens the spectrum menu for customizing their player sprite

-  - present-time and gone-time randomize. consult legacy code

-  - **[ReBNO-INTENT for sync]** EXISTS in legacy (under a non-obvious object name, prominent in Emptiness' Hull) but is NOT server-synced; ReBNO must sync it deterministically. (recon: `.planning/legacy-recon/13-flicker-tile.md`)

+  - 5-8: object **`magictile`** (borderless white, 44×40). Present 45–75 steps → ~1.0 s flicker tell (~15 Hz strobe) → gone 30–60 steps → loops; collision is passable while gone

+  - **[ReBNO-INTENT for sync]** EXISTS in legacy as `magictile` (35 instances in Emptiness' Hull) but driven by client-side `random()` — LOCAL/unsynced; ReBNO must drive present/gone deterministically server-side. (recon: `.planning/legacy-recon/13-flicker-tile.md`)


**Flicker** tiles *do*
exist (under a non-obvious object name, prominent in Emptiness' Hull) — but **neither is synced**
in legacy.

**Flicker** tiles *do*
exist (object `magictile` — 35 instances in Emptiness' Hull) — but **neither is synced** in legacy
(`magictile` uses client-side `random()`).


The file C:\Users\decid\Documents\projects\rebno\CONTEXT.md has been updated successfully. (file state is current in your context — no need to Read it back)

**Flicker** tiles *do*
exist (under a non-obvious object name, prominent in Emptiness' Hull) — but **neither is synced**
in legacy.

**Flicker** tiles *do*
exist (object `magictile` — 35 instances in Emptiness' Hull) — but **neither is synced** in legacy
(`magictile` uses client-side `random()`).

World state ReBNO will drive by shared server time so every client renders it identically: moving

**Platform** positions, animation loops, **Flicker** cycles, **Glow** activation. Legacy ran

platforms as **pure local sim** (±3 px/step, `random(60)` end-pause); **Flicker** tiles *do*

-exist (under a non-obvious object name, prominent in Emptiness' Hull) — but **neither is synced**

-in legacy. So ReBNO must *add* the determinism (seed the RNG / drive by server time). _ReBNO QoL:

+exist (object `magictile` — 35 instances in Emptiness' Hull) — but **neither is synced** in legacy

+(`magictile` uses client-side `random()`). So ReBNO must *add* the determinism (seed the RNG / drive by server time). _ReBNO QoL:

moving platforms blink a departure tell (~5 blinks) before moving — needs a new per-platform

animation._ Not per-player. (Movers and slippery ice have no unique state — just a looping


PowerShell

cd 'C:\Users\decid\Documents\projects\rebno'; git add CONTEXT.md docs/LEGACY_FEATURE_REFERENCE.md docs/adr/0013-perception-gating.md .planning/legacy-recon/12-feature-reference-reconcile.md .planning/legacy-recon/13-flicker-tile.md; git status --short

Stage reconcile batch + canonical-note edits


warning: in the working copy of 'CONTEXT.md', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'docs/adr/0013-perception-gating.md', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of '.planning/legacy-recon/12-feature-reference-reconcile.md', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of '.planning/legacy-recon/13-flicker-tile.md', LF will be replaced by CRLF the next time Git touches it
A  .planning/legacy-recon/12-feature-reference-reconcile.md
A  .planning/legacy-recon/13-flicker-tile.md
M  CONTEXT.md
M  docs/LEGACY_FEATURE_REFERENCE.md
M  docs/adr/0013-perception-gating.md


cd 'C:\Users\decid\Documents\projects\rebno'; git commit -m @'
docs: reconcile LEGACY_FEATURE_REFERENCE vs 5-8 code + fold final canonical notes

Tile/interactive mechanics reconciled against client-5-8 (recon docs 12-13): all match
except 8 items, now classified legacy-drift vs ReBNO-intent and pinned with concrete
numbers. Drift fixes: mover accel profiles, hexsling 1-dir-auto rule, quartered=btilemini,
dynamic per-tile allow-lists. ReBNO-intent tagged: platform+flicker server-sync, hidden-glass
always-50%. Flicker tile located (object `magictile`, 35x in Emptiness' Hull, local/unsynced).

CONTEXT/ADR-0013 corrections: Duo is the one perception-gating exception (partners always see
each other incl. hidden tiles); adds Gateway term, Digital Abyss no-nametag/VOID-chat rules,
Home-Portal-set-only-at-portal, Duo Beacon fatal-fall break, platform departure-blink tell.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
'@; git log --oneline -2

Commit reconcile batch and final notes


[main 3f0183d] docs: reconcile LEGACY_FEATURE_REFERENCE vs 5-8 code + fold final canonical notes
 5 files changed, 284 insertions(+), 28 deletions(-)
 create mode 100644 .planning/legacy-recon/12-feature-reference-reconcile.md
 create mode 100644 .planning/legacy-recon/13-flicker-tile.md
3f0183d docs: reconcile LEGACY_FEATURE_REFERENCE vs 5-8 code + fold final canonical notes
e7927bc docs: capture BNO domain model — CONTEXT.md glossary + legacy recon + perception-gating ADR


Committed — **`3f0183d`**. The grill is complete.

## Session outcome

**Mutual understanding: locked.** `CONTEXT.md` is a full domain glossary; 13 legacy-code recon docs back every claim in `.planning/legacy-recon/`; two clean commits.

**What BNO is** — a social-exploration **Metroidvania-of-connectivity**: no combat, economy, or quests; progression = reach a Zone's Central Portal → Zone Link → Area Links → Navi-Expansion keys → next zone. MMBN is skin, not mechanics.

**The rebuild's defining truth** — legacy is **fully client-authoritative** (Master = relay). ReBNO rebuilds the entire rule layer server-side. Recorded as ADR 0013 (**Perception gating**) + the scope principle & mandated divergences in `PROJECT.md`.

**Everything resolved:**
- Q1–Q7 + all closing notes folded in
- 8 tile-mechanic mismatches classified (drift fixed with real numbers; intent tagged `[ReBNO-INTENT]`)
- Duo confirmed as the *one* perception-gating exception (partners always see each other, incl. hidden tiles)
- Flicker tile found (`magictile`); NPC dialogue confirmed intact (no data loss); Message Data confirmed ~25% (mostly net-new)
- New ReBNO features captured: Quick Portal, Duo Beacon, Message Data, Gateways, Fall Safety Buffer, platform departure-blink

**Importer hand-offs recon surfaced for future phases:** parse `instances.json[].creationCode` for NPC dialogue; server-sync `magictile` + platforms (seed RNG); harden appearance/inventory validation; Message Data is a build-from-scratch (extend the 5-field format with recipient/lock/expiry).

No open blockers. The only deferred archaeology — pre-5-8 hexsling history — you explicitly closed ("port 5-8 as-is"). Ready for planning whenever you are.


did you ever do followup recon on the first few questions that didn't get any, to flesh out their context entries? --- note: Gateways are not a new feature, just a rename of an existing feature. fall safety buffer is similarly not new, though its visual element and additional rules will be new.


<owl_reachability_notice>
You have an active owl perch. When spawning subagents or doing work, use run_in_background: true so you stay reachable for incoming messages.
</owl_reachability_notice>


CAVEMAN MODE ACTIVE (full). Drop articles/filler/pleasantries/hedging. Fragments OK. Code/commits/security: write normal.


Fair question — and the honest answer is **partially**. Let me be precise:

- **Q2 (shared/per-player, sync, visibility)** and **Q3 (world hierarchy, travel)** *did* get recon coverage — the initial 3 agents (globals/feature-ids/behavioral) plus the reconcile pass fleshed those out (zones=rooms, areas=`ac_*`, portals, gateways, platform/flicker sync, hidden-tile cull).
- **Q1 (core identity — "no combat")** did **not** get a dedicated pass. I asserted "no combat system" from *absence of evidence* + your confirmation, but never ran a deliberate search to prove it. The whole project identity rests on that claim — it deserves verification.

So: launching a **no-combat confirmation + completeness sweep** now (per recon-before-grill). And fixing two mislabels you flagged — **Gateways** and **Fall Safety Buffer** are *not* new; only the buffer's visual + extra rules are:


Edit

**Gateway**:
An **inter-zone portal with NO associated Link Data** — an on-foot connector you walk through to
reach an adjacent zone before (or without) holding that zone's Zone Link. Distinct from a
**Central Portal** (which *grants* Link Data) and from Link-Data fast-travel. (This is the
"travel there on foot" path; ReBNO may add special cross-zone hexport Gateways.)

**Gateway**:
The **formal name** (a rename of an existing legacy feature — NOT new) for an **inter-zone portal
with NO associated Link Data**: an on-foot connector you walk through to reach an adjacent zone
before (or without) holding that zone's Zone Link (legacy `teleparent` / `to<Zone>` objects).
Distinct from a **Central Portal** (which *grants* Link Data) and from Link-Data fast-travel.
(ReBNO *may* additionally introduce special cross-zone hexport Gateways — that part is TBD.)


**Gateway**:
An **inter-zone portal with NO associated Link Data** — an on-foot connector you walk through to
reach an adjacent zone before (or without) holding that zone's Zone Link. Distinct from a
**Central Portal** (which *grants* Link Data) and from Link-Data fast-travel. (This is the
"travel there on foot" path; ReBNO may add special cross-zone hexport Gateways.)

**Gateway**:
The **formal name** (a rename of an existing legacy feature — NOT new) for an **inter-zone portal
with NO associated Link Data**: an on-foot connector you walk through to reach an adjacent zone
before (or without) holding that zone's Zone Link (legacy `teleparent` / `to<Zone>` objects).
Distinct from a **Central Portal** (which *grants* Link Data) and from Link-Data fast-travel.
(ReBNO *may* additionally introduce special cross-zone hexport Gateways — that part is TBD.)

Intra-zone teleportation via Warp tiles. Inert without the expansion.

-An **inter-zone portal with NO associated Link Data** — an on-foot connector you walk through to

-reach an adjacent zone before (or without) holding that zone's Zone Link. Distinct from a

-**Central Portal** (which *grants* Link Data) and from Link-Data fast-travel. (This is the

-"travel there on foot" path; ReBNO may add special cross-zone hexport Gateways.)

+The **formal name** (a rename of an existing legacy feature — NOT new) for an **inter-zone portal

+with NO associated Link Data**: an on-foot connector you walk through to reach an adjacent zone

+before (or without) holding that zone's Zone Link (legacy `teleparent` / `to<Zone>` objects).

+Distinct from a **Central Portal** (which *grants* Link Data) and from Link-Data fast-travel.

+(ReBNO *may* additionally introduce special cross-zone hexport Gateways — that part is TBD.)

A player-to-player teleport system. It refuses to teleport a user into a Zone where that user


**Fall Safety Buffer** (ReBNO):
The legacy fall-immunity counter (`dafalls`, ≤5 safe) reimagined as a **visible, depleting GUI
bar**. Solo: ~5 safe falls, then each fatal fall is a chance (~10%). In a **Duo**, Spotter +
Digger **share one combined buffer** (~10), after which the chance drops to ~5% (see **Duo Net**).

**Fall Safety Buffer** (existing legacy mechanic; ReBNO adds the visual + new rules):
The **existing** legacy fall-immunity counter (`dafalls`, ≤5 safe) — **not new**. ReBNO adds a
**visible, depleting GUI bar** plus new rules. Solo: ~5 safe falls, then each fatal fall is a
chance (~10%). In a **Duo**, Spotter + Digger **share one combined buffer** (~10), after which the
chance drops to ~5% (see **Duo Net**). _(The shared pool, refill model, and Quick-Portal
interaction below are the new parts; the underlying immunity counter is parity.)_


**Fall Safety Buffer** (ReBNO):
The legacy fall-immunity counter (`dafalls`, ≤5 safe) reimagined as a **visible, depleting GUI
bar**. Solo: ~5 safe falls, then each fatal fall is a chance (~10%). In a **Duo**, Spotter +
Digger **share one combined buffer** (~10), after which the chance drops to ~5% (see **Duo Net**).

**Fall Safety Buffer** (existing legacy mechanic; ReBNO adds the visual + new rules):
The **existing** legacy fall-immunity counter (`dafalls`, ≤5 safe) — **not new**. ReBNO adds a
**visible, depleting GUI bar** plus new rules. Solo: ~5 safe falls, then each fatal fall is a
chance (~10%). In a **Duo**, Spotter + Digger **share one combined buffer** (~10), after which the
chance drops to ~5% (see **Duo Net**). _(The shared pool, refill model, and Quick-Portal
interaction below are the new parts; the underlying immunity counter is parity.)_

"trapped" flag, NOT an exemption. _In-Abyss rules: players **see each other but with no

nametags**, and **chat is disabled** — the chat input line permanently reads `VOID`._

-The legacy fall-immunity counter (`dafalls`, ≤5 safe) reimagined as a **visible, depleting GUI

-bar**. Solo: ~5 safe falls, then each fatal fall is a chance (~10%). In a **Duo**, Spotter +

-Digger **share one combined buffer** (~10), after which the chance drops to ~5% (see **Duo Net**).

+**Fall Safety Buffer** (existing legacy mechanic; ReBNO adds the visual + new rules):

+The **existing** legacy fall-immunity counter (`dafalls`, ≤5 safe) — **not new**. ReBNO adds a

+**visible, depleting GUI bar** plus new rules. Solo: ~5 safe falls, then each fatal fall is a

+chance (~10%). In a **Duo**, Spotter + Digger **share one combined buffer** (~10), after which the

+chance drops to ~5% (see **Duo Net**). _(The shared pool, refill model, and Quick-Portal

+interaction below are the new parts; the underlying immunity counter is parity.)_

_Refill model (ReBNO): the buffer refills by **teleporting through an inter-zone portal** or by

**escaping the Digital Abyss** (post-port: possible recharge stations). See **Quick Portal**,

which consumes and locks the buffer while active._


Now the confirmation + completeness recon:


Agent

Recon: no-combat + completeness sweep

Prompt:
Reverse-engineering extracted GameMaker 5.3a source of "BN Online". GML under `C:\Users\decid\Documents\projects\rebno\extracted\` (`client-5-8`, server `server-5-4`). Plain-text — don't hex-inspect.

TWO-PART MISSION — verify a foundational claim, then find anything we missed.

PART 1 — CONFIRM "NO COMBAT SYSTEM." The entire project identity asserts BNO is a pure social-exploration Metroidvania with **no combat**. This was assumed from absence of evidence, never proven. Deliberately search to confirm or refute: look for HP/health, damage, attack, enemy/foe, virus/busting, battle/fight, chips/folder (MMBN combat staples), weapons, death-by-combat, PvP damage, score-from-kills. Distinguish true combat from non-combat hazards already known (falling into the void, the Digital Abyss). VERDICT: is there any combat/battle/damage system, or is the no-combat claim confirmed?

PART 2 — COMPLETENESS SWEEP (a "what did we miss?" critic). The following systems are ALREADY documented (in `.planning/legacy-recon/01-13` + `CONTEXT.md`) — do NOT re-cover them:
identity; zones/areas/gateways; hexport/warp/portals/home-portal/central-portal/fast-travel; Digital Abyss + fall safety; Navi Expansions (HxpPlugn/RmtPlugn/MskPlugn/DuoPlugn/WrpPlugn) + TakABrak; Mod/admin items (RCE + fenced) + operator console; Link Data; Spectrum Data + avatar (palette swap + Phoenix); floor/interactive tiles (bordered/borderless/hidden/glow/mover/platform/dynamic/slippery/flicker=magictile/quartered/hexporter/hexsling/hexbridge/spectral-gate); Duo/Spotter/Digger/Duo-Net/Watch/request system; chat (proximity) + message boards + Message Data + Friend Data + presence; NPCs/hints; collectable economy + onboarding/OCS; save formats (.bno/.bnu/MB_Log.bnb) + inventory iv_itemdb.

Now scan the codebase (object list, script list, room list, global vars) for any **major gameplay system, mechanic, or feature NOT in that list**. Candidates to check for: day/night or time-of-day, weather, sound/music systems with gameplay effect, hazard/trap objects beyond tiles, vehicles/mounts, scripted cutscenes/events, achievements, seasonal/event content, any object cluster you can't explain. List each uncovered system with object/script names + a one-line description.

OUTPUT: Write `C:\Users\decid\Documents\projects\rebno\.planning\legacy-recon\14-nocombat-completeness.md` — Part 1 verdict (with evidence) + Part 2 table of any uncovered systems (or "none found — coverage complete"). Return a ~10-line summary leading with the no-combat verdict and the count of newly-found systems. Evidence-based; flag guesses.


<owl_reachability_notice>
You have an active owl perch. Launch this Agent with run_in_background: true so you stay reachable for incoming messages while it works.
</owl_reachability_notice>


Async agent launched successfully.
agentId: a59b0e4ab4c9d24f4 (internal ID - do not mention to user. Use SendMessage with to: 'a59b0e4ab4c9d24f4' to continue this agent.)
The agent is working in the background. You will be notified automatically when it completes.
Do not duplicate this agent's work — avoid working with the same files or topics it is using. Work on non-overlapping tasks, or briefly tell the user what you launched and end your response.
output_file: C:\Users\decid\AppData\Local\Temp\claude\C--Users-decid-Documents-projects-rebno\27ced91a-de41-488a-b2a2-10f1c09be4bb\tasks\a59b0e4ab4c9d24f4.output
Do NOT Read or tail this file via the shell tool — it is the full subagent JSONL transcript and reading it will overflow your context. If the user asks for progress, say the agent is still running; you'll get a completion notification.

Recon: no-combat + completeness sweep

Prompt:
Reverse-engineering extracted GameMaker 5.3a source of "BN Online". GML under `C:\Users\decid\Documents\projects\rebno\extracted\` (`client-5-8`, server `server-5-4`). Plain-text — don't hex-inspect.

TWO-PART MISSION — verify a foundational claim, then find anything we missed.

PART 1 — CONFIRM "NO COMBAT SYSTEM." The entire project identity asserts BNO is a pure social-exploration Metroidvania with **no combat**. This was assumed from absence of evidence, never proven. Deliberately search to confirm or refute: look for HP/health, damage, attack, enemy/foe, virus/busting, battle/fight, chips/folder (MMBN combat staples), weapons, death-by-combat, PvP damage, score-from-kills. Distinguish true combat from non-combat hazards already known (falling into the void, the Digital Abyss). VERDICT: is there any combat/battle/damage system, or is the no-combat claim confirmed?

PART 2 — COMPLETENESS SWEEP (a "what did we miss?" critic). The following systems are ALREADY documented (in `.planning/legacy-recon/01-13` + `CONTEXT.md`) — do NOT re-cover them:
identity; zones/areas/gateways; hexport/warp/portals/home-portal/central-portal/fast-travel; Digital Abyss + fall safety; Navi Expansions (HxpPlugn/RmtPlugn/MskPlugn/DuoPlugn/WrpPlugn) + TakABrak; Mod/admin items (RCE + fenced) + operator console; Link Data; Spectrum Data + avatar (palette swap + Phoenix); floor/interactive tiles (bordered/borderless/hidden/glow/mover/platform/dynamic/slippery/flicker=magictile/quartered/hexporter/hexsling/hexbridge/spectral-gate); Duo/Spotter/Digger/Duo-Net/Watch/request system; chat (proximity) + message boards + Message Data + Friend Data + presence; NPCs/hints; collectable economy + onboarding/OCS; save formats (.bno/.bnu/MB_Log.bnb) + inventory iv_itemdb.

Now scan the codebase (object list, script list, room list, global vars) for any **major gameplay system, mechanic, or feature NOT in that list**. Candidates to check for: day/night or time-of-day, weather, sound/music systems with gameplay effect, hazard/trap objects beyond tiles, vehicles/mounts, scripted cutscenes/events, achievements, seasonal/event content, any object cluster you can't explain. List each uncovered system with object/script names + a one-line description.

OUTPUT: Write `C:\Users\decid\Documents\projects\rebno\.planning\legacy-recon\14-nocombat-completeness.md` — Part 1 verdict (with evidence) + Part 2 table of any uncovered systems (or "none found — coverage complete"). Return a ~10-line summary leading with the no-combat verdict and the count of newly-found systems. Evidence-based; flag guesses.


did you ever do followup recon on the first few questions that didn't get any, to flesh out their context entries? --- note: Gateways are not a new feature, just a rename of an existing feature. fall…


Done this turn:
- **Corrected** `CONTEXT.md`: **Gateway** = rename of an existing feature (not new); **Fall Safety Buffer** = existing legacy `dafalls` mechanic (only its visual + shared-pool/refill/Quick-Portal rules are new).
- **Launched** the gap recon — confirms/refutes "no combat" and sweeps for any uncatalogued gameplay system.

When it lands I'll fold the verdict + commit doc 14 with the Gateway/Buffer fixes (and grill anything new it surfaces). Standing by.


<task-notification>
<task-id>a59b0e4ab4c9d24f4</task-id>
<tool-use-id>toolu_01NukrJbjjHVBbNiTdseBQ8y</tool-use-id>
<output-file>C:\Users\decid\AppData\Local\Temp\claude\C--Users-decid-Documents-projects-rebno\27ced91a-de41-488a-b2a2-10f1c09be4bb\tasks\a59b0e4ab4c9d24f4.output</output-file>
<status>completed</status>
<summary>Agent "Recon: no-combat + completeness sweep" completed</summary>
<result>Report written to `C:\Users\decid\Documents\projects\rebno\.planning\legacy-recon\14-nocombat-completeness.md`.

**NO-COMBAT VERDICT: CONFIRMED — there is no combat, battle, damage, or PvP system anywhere in client or server.** This is now proven, not assumed.

Evidence (Part 1):
- Grep for `hp|health|damage|enemy|virus|weapon|chip|folder|combat|hurt|respawn|revive` across all `.gml` → **0 hits**. Same for `score|lives|gameover|pvp|duel`.
- All 17 `"Battle"`/`"fight"`/`"attack"` matches are the product name "Battle Network Online" — no combat verb.
- The complete chat-command dispatcher (`scripts/0008-ChtCmdRec.gml`) is entirely social/movement: goto, watch, join/summon/add/whisper, message-board help. No attack/challenge command.
- The only "removal" mechanic is the void-fall: stepping on a non-collision cell *teleports* you to the Digital Abyss (Duo Net saves you if paired). It's a positional teleport with a fall-counter (`global.dafalls`), **no HP or damage** — the already-documented hazard, not combat.

Completeness sweep (Part 2): **0 newly-found systems — coverage complete.** All 320 client objects / 366 scripts / 17 rooms resolve to documented systems (ac_* gateways, tiles/platforms, message boards, NPCs, Link/Spectrum data, inventory, watch/request). Explicitly checked-and-absent: day/night, weather, gameplay sound/music, vehicles, cutscenes, achievements, traps beyond void-fall.

One clarification flag: `jokershell` ("Joker Shell", J-key) looked like a possible flight/movement feature but is an **admin noclip mode gated behind mod item #909 + clipboard `"UNLIM"`** — it's inside the already-documented fenced-Mod/RCE scope, not a player feature. Noted so it isn't mistaken for new gameplay.</result>
<usage><subagent_tokens>73151</subagent_tokens><tool_uses>28</tool_uses><duration_ms>196584</duration_ms></usage>
</task-notification>


<owl_messages>
<owl_message from="ling-w14" priority="info">[WORKING_PERCH_NOTICE] Subagent working perch created.
Perch: ling-w14
Agent type: general-purpose
To message it: $OWL send ling-w14 ling</owl_message>
</owl_messages>

[OWL SYSTEM] Informational owl messages above — no acknowledgment needed. Continue your current task.

<owl_reachability_notice>
You have an active owl perch. When spawning subagents or doing work, use run_in_background: true so you stay reachable for incoming messages.
</owl_reachability_notice>


**No-combat: CONFIRMED — proven, not assumed.** Zero hits for HP/damage/enemy/virus/chip/PvP across client+server; the 17 "Battle" matches are all the product name. **Completeness sweep: 0 uncatalogued systems** — all 320 objects / 366 scripts / 17 rooms resolve to documented mechanics. The project-identity claim is now code-backed. Marking it verified + committing:


Edit

and solve puzzles built from interwoven traversal mechanics. **No combat system.**
_Avoid_: "MMBN game", "battle game" (the IP is skin, not mechanics).

and solve puzzles built from interwoven traversal mechanics. **No combat system.**
_Avoid_: "MMBN game", "battle game" (the IP is skin, not mechanics).
_Code-verified (recon 14): zero combat / HP / damage / PvP across client + server; the only
removal mechanic is the void-fall → **Digital Abyss**. A full-codebase completeness sweep (320
objects / 366 scripts / 17 rooms) found **no uncatalogued gameplay system** — coverage complete._


and solve puzzles built from interwoven traversal mechanics. **No combat system.**
_Avoid_: "MMBN game", "battle game" (the IP is skin, not mechanics).
_Code-verified (recon 14): zero combat / HP / damage / PvP across client + server; the only
removal mechanic is the void-fall → **Digital Abyss**. A full-codebase completeness sweep (320
objects / 366 scripts / 17 rooms) found **no uncatalogued gameplay system** — coverage complete._

combat: uncover hidden platforms/pathways/portals, beat timing-sensitive movement challenges,

+_Code-verified (recon 14): zero combat / HP / damage / PvP across client + server; the only

+removal mechanic is the void-fall → **Digital Abyss**. A full-codebase completeness sweep (320

+objects / 366 scripts / 17 rooms) found **no uncatalogued gameplay system** — coverage complete._

The ground-up rebuild of BNO on a modern web stack. Primary goal: **full feature parity with


PowerShell

cd 'C:\Users\decid\Documents\projects\rebno'; git add CONTEXT.md .planning/legacy-recon/14-nocombat-completeness.md; git commit -m @'
docs: verify no-combat identity + completeness sweep; fix Gateway/Fall-Buffer labels

Recon 14 proves the core identity claim: zero combat/HP/damage/PvP across client + server
(0 grep hits; the only removal mechanic is the void-fall to the Digital Abyss). Full-codebase
completeness sweep (320 objects / 366 scripts / 17 rooms) finds no uncatalogued gameplay system.

Also corrects two mislabels: Gateway is a rename of an existing inter-zone-portal feature (not
new), and the Fall Safety Buffer is the existing legacy dafalls mechanic (only its visual + the
shared-pool/refill/Quick-Portal rules are new).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
'@; git log --oneline -3

Commit no-combat verification + label fixes


warning: in the working copy of 'CONTEXT.md', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of '.planning/legacy-recon/14-nocombat-completeness.md', LF will be replaced by CRLF the next time Git touches it
[main c80497d] docs: verify no-combat identity + completeness sweep; fix Gateway/Fall-Buffer labels
 2 files changed, 83 insertions(+), 8 deletions(-)
 create mode 100644 .planning/legacy-recon/14-nocombat-completeness.md
c80497d docs: verify no-combat identity + completeness sweep; fix Gateway/Fall-Buffer labels
3f0183d docs: reconcile LEGACY_FEATURE_REFERENCE vs 5-8 code + fold final canonical notes
e7927bc docs: capture BNO domain model — CONTEXT.md glossary + legacy recon + perception-gating ADR


Committed — **`c80497d`**. That closes the gap you flagged.

## Recon coverage — now complete

- **Q2 / Q3** (shared-state/sync/visibility, world/travel) — were covered by the initial + reconcile passes.
- **Q1 identity** ("no combat") — the one untested early claim, now **code-verified** (recon 14): 0 combat hits, void-fall is the only removal mechanic.
- **Completeness sweep** — every object/script/room resolves to a documented system; **nothing uncatalogued**.

So the early questions that originally preceded recon are all fleshed out and committed.

## Final state
- **3 commits** (`e7927bc` → `3f0183d` → `c80497d`), 14 recon docs in `.planning/legacy-recon/`.
- `CONTEXT.md` — complete, code-backed domain glossary. ADR 0013 + `PROJECT.md` scope section.
- Label fixes folded: **Gateway** = rename (not new); **Fall Safety Buffer** = existing mechanic (only visual + new rules are new).

Mutual understanding is locked and verified end-to-end. No open threads. Ready for planning whenever you want to move on.


in whatever way is a sensible games industry best-practice, please have a subagent amass all the legacy NPC names and dialogue sequences, then compile them into a more organized translation-friendly dialogue doc. --- another clarification about gateways: the player stands on them and uses the action button to engage them, which proceeds to teleport them between zones. it's not a path, and doesn't engage solely on collision. --- note about the term "fatal fall": it means a risky fall that hit the 10%-->would normally lead to the abyss. but some features i.e. duo save the player from the abyss teleport.


in whatever way is a sensible games industry best-practice, please have a subagent amass all the legacy NPC names and dialogue sequences, then compile them into a more organized translation-friendly d…


/clear


Proceed with next steps


On it. Three things — launching the NPC dialogue compilation (the main task) and folding the two clarifications.

For the dialogue doc, games-industry best practice is a **localization kit**: a human-readable doc organized by zone/NPC **plus** a machine-readable string table with stable keys (so translations survive text edits and a CAT/TMS tool can ingest them). Tasking an agent to produce both:


Agent

Compile NPC dialogue localization kit

Prompt:
You are building a translation-ready LOCALIZATION KIT from the legacy NPC dialogue of "BN Online" (extracted GameMaker 5.3a). This is a real deliverable — follow games-industry localization best practice.

SOURCE OF TRUTH (per prior recon `.planning/legacy-recon/10-npc-dialogue-integrity.md`):
- Per-NPC dialogue lives in `extracted/client-5-8/rooms/*/instances.json` → each instance's `creationCode` field (variables like `name`, `say` / `say[0..n]` arrays, `sayings`, `saytype`, plus `pcode_*` movement).
- Object-event defaults (e.g. `objects/0376-npc_greenprog`, the REAPROG object) are the FALLBACK text used only when an instance doesn't override.
- ~66 NPC instances across 11 rooms; 64 carry populated creation code.

DO:
1. Enumerate every NPC object type (Mr. Prog / `npc_greenprog`, REAPROG, and any others). For EACH room (zone), parse `instances.json` and extract every NPC instance's: speaker `name`, all dialogue lines (the `say`/`sayings` array, IN ORDER), `saytype`, and instance position (x,y). Decode what `saytype` values mean (sequential? cycling? random? one-shot?) by reading the NPC object's draw/talk events.
2. Capture dialogue text VERBATIM — exact wording, punctuation, capitalization (translators need source fidelity). Note instances that fall back to object-default text vs. override.
3. FLAG localization hazards per line: (a) embedded **button/command references** (e.g. "ctrl+r", backtick `` ` `` commands) — IMPORTANT: ReBNO is going gamepad-first and retiring these commands, so these strings need a variable/placeholder + a mechanic-aware rewrite, not a literal translation; (b) any player-name or dynamic variable interpolation; (c) do-not-translate tokens; (d) very long lines / manual line-breaks.

PRODUCE TWO ARTIFACTS (create `docs/localization/` if needed):
- `docs/localization/legacy-npc-dialogue.md` — HUMAN-READABLE, organized **Zone → NPC → ordered lines**. Each line shows: stable **string key**, speaker, source (EN) text, context note (where the NPC stands + what its hint refers to, e.g. names an adjacent/hidden zone), saytype, and any hazard flags. Include a short header explaining the key scheme + how to use the kit.
- `docs/localization/legacy-npc-strings.csv` — MACHINE-READABLE source table, one row per line, columns: `key,zone,room,npc_object,instance_id,speaker,sequence,saytype,source_en,context,flags`. Properly CSV-escape commas/quotes/newlines in dialogue. This is the TMS/CAT import artifact.

KEY SCHEME (stable, decoupled from text): `NPC.<ZONE_SLUG>.<NPC_SLUG>.<NN>` (zero-padded sequence). Keep keys stable per (instance, sequence) so re-runs are diff-friendly.

OUTPUT: write both files, then return a ~12-line summary: NPC-instance count, total line count, per-zone breakdown, and the count of strings flagged for button/command rewrite. Evidence-based; if a room has no NPCs say so. Do not paraphrase dialogue.