Files

T

arcattackandClaude Opus 4.8 f914fc040a context-system: complete migration -> CLAUDE.md is now a 160-line router (zero context lost)

Full migration of the 2236-line monolithic CLAUDE.md into the progressive-context
knowledge graph (per spark-lesson / expert-seed.md), so the deep RE knowledge loads
on-demand instead of every session.

ZERO CONTEXT LOST:
- docs/PROGRESS_LOG.md = the complete old CLAUDE.md, VERBATIM (byte-identical) -- the
  lossless safety net + the "full detail" quick-lookup fallback.
- 18 context/*.md topic files (1343 lines) digest every section (§1-3 -> project-overview,
  §4 -> content-archives, §5 -> asset-formats/bgf-format, §5a -> source-completeness,
  §5b/§8 -> wintesla-port, §7/§10 -> locomotion, §10a -> build-and-run, §10b ->
  reconstruction-method, §10c -> combat-damage + reconstruction-gotchas, §10d -> subsystems,
  render notes -> rendering, gauges -> gauges-hud, MP -> multiplayer, §9 -> open-questions).
- reference/glossary.yaml (53 terms). decomp-reference.md = the offsets/ClassIDs/addresses hub.

CLAUDE.md (160 lines) = router: identity, answer/reason protocols, quick-lookup table,
evidence tiers (T0 engine-truth / T1 decompiled+verified / T2 reconstructed+runtime /
T3 guarded / T4 hypothesis), conventions + DO-NOT (the systemic bug classes), structure.
Retains the load-bearing work directives (build recipe pointer, "keep current" mandate).

Knowledge graph validates CLEAN (scratchpad/checkctx.py -- all [[links]] + quick-lookup +
docs refs resolve; [[name]] -> topic file or glossary term). docs/*.md ledgers stay as the
detailed logs; context/*.md are the curated digests that route into them.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-07-07 22:19:50 -05:00

2.8 KiB

Raw Permalink Blame History

id, title, status, source_sections, related_topics, key_terms

title

status

source_sections

related_topics

key_terms

pod-hardware

Pod Hardware — the fixed target (7 monitors, D3D9, RIO)

established

PROGRESS_LOG.md §3; the PLATFORM PROFILE + GAUGE DEV-COMPOSITE notes

gauges-hud

rendering

project-overview

pod

RIO

MFD

IG-board

SVGA16

Pod Hardware (the fixed target)

The port must run on (a) a dev box and (b) the fixed arcade pod. The pod is a hard constraint that bounds the graphics API. Full detail: docs/PROGRESS_LOG.md §3.

Displays

2 video cards → 7 monitors: main 3D view 800×600; radar 640×480; five monochrome MFDs driven as one 1280×480 horizontally-spanned surface. [T1]
Requires old NVIDIA drivers for the MFD horizontal spanning — a hard constraint that bounds the graphics API → Target Direct3D 9 (lowest common denominator that runs on old-driver pods AND modern cards; one codepath). NOT Vulkan/D3D11+. CUDA is irrelevant (compute, not display). [T1]

Cockpit I/O (RIO)

Joystick X/Y, throttle, pedals, buttons over serial COM (L4RIO, L4SERIAL). Must be remapped to keyboard/gamepad on a dev box; real wiring is a pod bring-up task (Phase 8). The engine is a PUSH model — LBE4ControlsManager groups are fed by all devices (RIO on the pod, DirectInput on dev); the MechControlsMapper interprets them (locomotion). [T2]

Multi-surface gauge path (intact, pod-only by default)

The pod multi-surface path EXISTS and is intact: DPLRenderer::FindBestAdapterIndices (multi- adapter selector, honors PRIMGAUGE/SECGAUGE/MFDGAUGE/SPANDISABLE), SVGA16::BuildWindows (a fullscreen D3D device + window per gauge/MFD surface, MFD span = width×2), L4GaugeRenderer (gated on L4GAUGE). content/SETENV.BAT is the authentic pod env preset (L4CONTROLS=RIO,KEYBOARD; L4GAUGE=640x480x16; L4PLASMA=com2). [T2]

Platform profile switch

-platform pod|dev (or BT_PLATFORM env; default DEV) selects a runtime env preset WITHOUT forking the codepath. DEV = keyboard + single 800×600 window. POD = RIO input (keyboard fallback off serial) + multi-surface gauges (from SETENV.BAT/L4GAUGE on real hardware). -platform pod does NOT auto-enable L4GAUGE (each surface needs its own fullscreen device on the pod's 2 cards). Off-pod, the 6 MFD surfaces render in a dev window via BT_DEV_GAUGES (gauges-hud). [T2]

MFD surface model

All cockpit surfaces are bit-plane MASKS over ONE shared SVGA16 pixelBuffer: sec=palette low byte; Heat=0x4000, Mfd2=0x0400, Comm=0x8000, Mfd1=0x0100, Mfd3=0x1000; Eng1-3 = engineering-mode alt planes; overlay=0x00C0 (shares the sec surface). See gauges-hud. [T2]

Key Relationships

Renders: gauges-hud (the MFD surfaces), rendering (the main 3D view).
Input: locomotion (the mapper).
Bring-up: Phase 8 (get pod specifics from Nick — open-questions).

2.8 KiB Raw Permalink Blame History Unescape Escape