https://gitlab.synchro.net/main/sbbs/-/issues/1218#note_10126
Fixed: line 20 now reports `GR` whenever the terminal supports ANSI, dropping the `COLOR` requirement. Line 39 keeps the monochrome distinction, unchanged.
I surveyed how door kits actually read the field before changing it, since the issue turned on whether `GR` on a monochrome terminal is what doors expect. Every reader I could find decides ANSI from line 20 alone:
| Kit | Line 20 | Line 39 |
|---|---|---|
| OpenDoors (`src/odoors/ODInEx1.c`) | `RIP` -> RIP+ANSI, leading `G` -> ANSI, else no ANSI | never read |
| xpdoor (`src/xpdoor/dropfiles.c`) | `GR` -> ANSI+CP437, `NG` -> CP437 only | not consulted for ANSI |
| MBSE doorlib (`src/doorsys.c`) | `termmode = 1` only if the field is exactly `GR` | read into a field named `allwaysN` |
| DoorDriver Plus 7.10, Turbo Pascal (`DDOVR.PAS`) | `if s='GR' then graphics:=3 else if s='RIP' then graphics:=5 else graphics:=1` | unreachable: the file is closed right after line 20 |
| DoorFrame (BASIC) | `Graphics%` / `AnsiOn$` from line 20 | exposes `AnsiSupport$` ("Caller supports ANSI but in NG mode") as information only |
DoorDriver Plus is the clearest case: it stops reading the drop file at line 20,
so lines 21-52 do not exist as far as it is concerned.
Writers and the published field definitions agree that line 20 is about ANSI, not color:
* WWIV `bbs/dropfile.cpp`: `const auto* const ansiStatus = okansi() ? "GR" : "NG";`
with no color condition. Its line 39 is `okansi() ? 'N' : 'Y'`, commented
"ansi ok but graphics turned off".
* MBSE's field reference: line 20 is `ANSI, "GR" is yes, otherwise "NG"`;
line 39 is "Always set to N".
* The original GAP-derived spec describes line 20 only as
`GR=Graph, NG=Non-Graph, 7E=7,E Caller`, saying nothing about color.
On the history: the ANSI-plus-COLOR test is present in the initial v3.00c check-in and no commit ever justified it. 554c2ca395 (days-21-coins, 2020-12-11) touched this exact line for the same symptom, its message citing
"a user getting non-ANSI output from door games even when using an
ANSI-capable terminal", but it only moved the test from `useron.misc` to the negotiated terminal flags and kept the COLOR conjunction. 374282bf81 (skins-28-shop, 2025-03-30) then re-expressed it as `supports(ANSI | COLOR)`. That was the last remaining ANSI-plus-COLOR conjunction in `xtrn_sec.cpp`.
The tradeoff this accepts: a monochrome-ANSI caller will now receive color from doors, because no field a door reads can express "ANSI but no color". What that caller gets today is no ANSI at all, including cursor positioning, which is the worse of the two.
The fix is committed on master and will close this issue when pushed.
-- *Authored by Claude (Claude Code), on behalf of @rswindell*
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)