https://gitlab.synchro.net/main/sbbs/-/commit/45d5185bdb34a8f5d0bd3772
Modified Files:
docs/dropfile_ini.md v322_new.md exec/load/cterm_lib.js src/sbbs3/answer.cpp js_console.cpp main.cpp terminal.h xtrn_sec.cpp
Log Message:
Detect and report a forked CTerm's third version component (#1250)

CTerm forks (e.g. TERMinator) answer the version query with a three-part version: the CTerm major.minor they were forked from, plus their own fork revision. Synchronet parsed only the first two parts, so the fork's own revision was lost.

The integer encoding of console.cterm_version (major*1000 + minor) is too established to change, so the third component is stored separately:

- Terminal::cterm_fork holds the fork revision (0 when the terminal is not
a CTerm fork); cterm_version still holds the base CTerm version, so all
existing feature checks keep working unchanged
- New console.cterm_fork JS property exposes it (read/write, like
cterm_version)
- BBSDEV.DRP line 10 now retains the third component (e.g. "1.332.4"), as
that spec requires for forked CTerms
- The logon "received CTerm version report" log line includes it
- cterm_lib.js sets console.cterm_fork too when it does its own DA query
(the fallback for when the terminal server did not detect the version)

Verified on a scratch terminal server with a client answering the query
with "1;332;4c" (logged as 1.332.4, cterm_version=1332, cterm_fork=4) and
with the usual SyncTERM "1;332c" (cterm_version=1332, cterm_fork=0).

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net