Written by Claude (Opus 5), an LLM made by Anthropic, posted at andy5995's direction.
The help browser's lightbar leans on ANSI for two separate jobs, so it comes out unusable wherever the escapes do not render:
- The highlight is reverse video and nothing else, so without it the selected row differs from its neighbours by a single leading space.
- The list repaints in place using cursor-home and erase-line. Without those, each arrow keypress appends another copy of the whole list and the screen scrolls away.
Two routes reach that state.
Local play on a legacy Windows console. The console cannot render ANSI, so the game strips the escapes rather than printing them as text (the fallback added for #98). The stripped frame is what the player gets.
Door play, depending on the caller's terminal. The game writes ANSI to a door session unconditionally: the dropfile's ANSI/graphics flag is parsed but never consulted. A caller whose terminal has no ANSI support, or who has graphics turned off in their BBS profile, sees the raw escape sequences instead — every screen, not only this one. Whether to honour that flag is a wider question than the lightbar, so it may deserve its own issue.
The -reset editor is already fine on a legacy console: it falls back to the line-based editor, which loses its colours but stays readable.
Three changes worth considering, and they stand on their own:
- Mark the selected row with a character as well as the colour. Reverse video alone gives nothing to a monochrome terminal or to a reader with colour-vision deficiency, so I would suggest this one regardless of platform.
- Offer a numbered list in place of the lightbar when the session cannot render ANSI, which also removes the repaint.
- Decide what the parsed ANSI flag should do, so a door caller without ANSI is not sent escapes.
What I actually checked: I read the code and ran the strip function over a representative lightbar frame, which turned
\x1b[H\x1b[2K\x1b[96mHelp\x1b[0m\n \x1b[7m Combat \x1b[0m\n Economy\n\x1b[J
into
Help\n Combat \n Economy\n
I have not run the game against a legacy console or against a non-ANSI door caller, so the on-screen behaviour above is inferred from that output and from reading the code, rather than observed.
The help browser's lightbar leans on ANSI for two separate jobs, so it comes out unusable wherever the escapes do not render:
Two routes reach that state.
Local play on a legacy Windows console. The console cannot render ANSI, so the game strips the escapes rather than printing them as text (the fallback added for #98). The stripped frame is what the player gets.
Door play, depending on the caller's terminal. The game writes ANSI to a door session unconditionally: the dropfile's ANSI/graphics flag is parsed but never consulted. A caller whose terminal has no ANSI support, or who has graphics turned off in their BBS profile, sees the raw escape sequences instead — every screen, not only this one. Whether to honour that flag is a wider question than the lightbar, so it may deserve its own issue.
The
-reseteditor is already fine on a legacy console: it falls back to the line-based editor, which loses its colours but stays readable.Three changes worth considering, and they stand on their own:
What I actually checked: I read the code and ran the strip function over a representative lightbar frame, which turned
into
I have not run the game against a legacy console or against a non-ANSI door caller, so the on-screen behaviour above is inferred from that output and from reading the code, rather than observed.