03 — SCREENSHOTSThe console itself
Captured from the live install supervising XCSV EXILE. Nothing staged — that is the real server, mid-session.
Rust · egui / eframe · Windows
An operations console for a live Arma 3 Exile server. Every feature in it exists because something actually broke and cost hours to diagnose — the checks it runs are that diagnosis, encoded so it never has to happen twice.
On 2026-08-01 the server entered a restart loop. The visible errors were all database errors, and they were all lies.
The real cause was three server PBOs repacked with a leading backslash
on every entry path — \bootstrap\fn_preInit.sqf instead of
bootstrap\fn_preInit.sqf. Arma resolves <prefix> +
\bootstrap\…, finds nothing, and Exile's server core silently never
loads. The mission ends, -autoInit restarts it, and round it goes.
Because extDB2 locks itself after a successful init, every database error
after the first pass is a symptom.
A PBO corrupted this way still passes a checksum verify. That is why it went unnoticed for six hours. The corruption is arithmetically visible — exactly one byte larger per entry:
| PBO | Good | Broken | Delta | Entries |
|---|---|---|---|---|
| exile_server.pbo | 506,736 | 507,018 | +282 | 285 |
| safex_server.pbo | 22,956 | 22,967 | +11 | 11 |
| Server.pbo | 4,818 | 4,822 | +4 | 4 |
GUARD's integrity gate finds this in one second and refuses to start the server while any PBO fails.
Process state, memory against the 12 GB x64 target, uptime, RPT size, and
automated pre-flight checks: restart-loop detection, x64/extDB3 launch state,
missing -filePatching, database and world init, HC join evidence,
runaway log growth, PBO integrity.
Parses every addon PBO's header and entry table and judges it. Refuses to start the server while any fails. This is the check that would have caught the outage in one second instead of six hours.
Server FPS, FPS floor, players, vehicles, memory and CPU as live
sparklines, read from infiSTAR's meta_data.log. Frame-rate
independent smoothing, so the needles move rather than jump.
Live RCon player list with per-player message, kick and ban controls, plus
BattlEye connection history — the only local record of who reached a
publicly listed box — and infiSTAR player_check rows.
Read-only extDB3-backed MariaDB console with grouped operator presets:
real players, living characters, recent deaths, territories, base assets,
vehicle ownership, stale vehicle timestamps, garage split, money summary,
market listings and unclaimed prizes. Custom SQL is still limited to
SELECT and SHOW.
A full BattlEye RCon console over UDP, implemented from the protocol up: CRC32-framed packets, multi-part reply reassembly, server-message acknowledgement, and the 25-second keepalive the server requires.
Virtualised panes over the RPT and infiSTAR logs with filtering and level colouring. Incremental scanning — the naive version re-read a 400 MB file every two seconds on the UI thread.
Scheduled restarts with in-game warnings, issuing #shutdown
rather than #restart so the x64 process actually exits and memory
is returned before the next run.
One button starts database → integrity gate → server → headless client → local model. One button stops them cleanly in reverse. Survives a machine reboot.
A top-bar rag chip watches the local project-memory index and
pulses when a RAG search was just used, so the operator can see at a glance
whether the agent memory layer is alive.
Captured from the live install supervising XCSV EXILE. Nothing staged — that is the real server, mid-session.
-filePatching is mandatory.A3XAI reads
a3xai_config.sqf as a loose file; without the flag it silently ends
the mission during world init and the server loops.arma3server_x64.exe, extDB3, and
-maxMem=12288; GUARD verifies that launch shape.#shutdown, not #restart.The latter reloads
the mission inside the same process and never returns memory. On x64, the
right answer is still a clean process exit and relaunch.Starting mission: and verify the
actual end state instead.-cpuCount
and -exThreads only affect asset loading. SQF spawn
does not create a thread. More cores do not help; a headless client does.The RCon password grants kick, ban and shutdown on a public server. It is not in source and must not be. Settings live beside the executable, gitignored, DPAPI-protected at rest, with an encrypt-on-load migration for anything previously stored in the clear.
They arrive from the network and are attacker-controlled. Anything interpolated into a shell command goes through a quote-doubling escaper, with a test that walks the output byte-by-byte proving no lone quote can terminate the literal.
Classifier and explainer only. No tools, no actions, output treated as untrusted data and never load-bearing. Request bodies go to a temp file so no prompt content reaches a command line. If it is down, everything else still works.
Notification processes spawn with CREATE_NO_WINDOW off the UI
thread, so nothing steals focus mid-game and a dead SMTP host cannot freeze
the console.
cargo build --release
cargo test --release
.\tools\deploy.ps1 # test, build, archive the outgoing binary, deploy
.\tools\deploy.ps1 -SkipTests
.\tools\deploy.ps1 -Keep 20 # retain 20 archived builds (default 10)
.\tools\capture.ps1 -AllTabs -Viewport small,normal,wide
.\tools\doctor.ps1 # 24 executable assertions
.\tools\doctor.ps1 -Json # machine-readable, exit codes
deploy.ps1 refuses to deploy if tests fail, archives the binary it
replaces as XCSV_GUARD_v<version>_<timestamp>.exe, prunes to
the newest N, writes current-release metadata, updates the taskbar shortcut
to the live Desktop exe, and regenerates a SHA256 manifest.
The live location always holds exactly one binary.
Four repositories, one system. Nothing here stands alone.