"2 chosen maps are only partly downloaded (Population density, Yandex
satellite imagery). Finish" - and Finish did nothing, silently.
Root cause: the banner and the button asked two different questions.
market::unfinished counts a set as unfinished when check_installed's file
count found it short (launcher.log: "popdark says it is installed but holds
293056 of 400268 files", "yandex ... 2371 of 28213"). Finish went through
apply_market, whose market::to_add only reads the markers - .blocks-done.json
listing every block - so it found nothing to add, nothing to remove, and
returned Ok. And even a forced install could not have repaired it: the
installer skips every block the marker lists (install.rs `pending`).
- odian-packs: InstallOptions::recheck_tile_sets. For those sets install_tiles
counts the tiles on disk per block (tiles_on_disk_per_block: z/x/y.ext names
only, so .blocks-done.json and the tile server's .missing negatives never
count), takes off `done` every block holding fewer than the index names
(forget_short_blocks - more is still whole: a PC bakes its own tiles in),
rewrites the marker at once so a stopped run reads as partial, and fetches
just those blocks; finish_block's rename replaces what is there. The
drive-copy path skips its "recorded complete" shortcut for them too.
- launcher: Finish passes market::short_tile_sets(market_checked) through
Inner::market_recheck (taken by install_market_items), apply_market runs when
a re-check is all there is to do, and the log says which sets are repaired.
Counted, not hashed: the index names a block's tiles only by digest, so a
block whose lost tiles were replaced by as many baked ones reads whole.
Spot-check: odian-packs install::tests (a short block is dropped, a whole one
and one with extra baked tiles kept, markers not counted); launcher
market::tests::finish_repairs_the_sets_a_count_found_short with the counts
from the real log.
The dev drive on another PC still showed no live aircraft after ce36cf0. Its
API log, on the drive: "now LIVE on the DHP (the DHP answered, but this PC has
no DHP sign-in yet)". The operator in launcher.json travels with the drive; the
DHP sign-in lives in that PC's Credential Manager and does not. So the launcher
launched as the drive's operator, wrote an empty upstream.token, and the API
and the tile server served the drive's own data - with nothing in the launcher's
window to say why.
run_stack now logs, when live mode has no token: no DHP sign-in on this PC, what
that costs (no live aircraft, no site tiles), and to stop ODIAN and sign in,
per PC.
The dev drive, plugged into another PC that was offline and then connected,
ran two sessions with no live aircraft. Its API log, on the drive, says why:
"upstream: live mode off (ODIAN_UPSTREAM_URL is unset)" - both times.
Root cause: live mode is decided when the stack starts (StackConfig::
upstream_url = Inner::engine_url), and engine_url was only ever learned from a
site probe and held in MEMORY. A launcher opened offline has none, and it probes
again only on window focus (30 s debounce) or the refresh button - so a Launch
pressed after connecting still used the offline answer, the API got no
ODIAN_UPSTREAM_URL, and live_loop (which would have synced the offline edits and
switched the API to the DHP when the network came) never started.
- launch() re-probes the site first when the launcher thinks it is offline (one
probe, 2 s at most on a PC that really is). It is also the update check a
launch from a stale "offline" skipped.
- The Engine API address is kept in launcher.json (LauncherState::engine, keyed
by site like tile_sync) and loaded at start, so a session started offline
still arms live mode and goes live by itself once the network is back - the
path live_loop already handles. Changing the DHP address in Settings drops it.
Spot-check: state::tests - per-site, unchanged-is-no-write, survives save/load,
and a launcher.json from before the field still loads.
A dev web launch on a PC without Node.js - a fresh one, or another PC the dev
drive was plugged into - failed with nothing but "stopped while starting (exit
code: 1)": `cmd /c npm run dev` had no npm to run, so nothing said why.
New nodejs.rs finds the folder holding node.exe AND npm.cmd - this process's
PATH first, then %ProgramFiles%\nodejs, where the installer puts it (an
install adds itself to the SYSTEM PATH, which the running launcher never sees).
Launcher::ensure_node runs before a web run's build/start: with no Node.js it
logs why and runs `winget install --id OpenJS.NodeJS.LTS --exact --source
winget --accept-*-agreements` in its own console (progress, Windows' permission
prompt and any failure stay on screen), then judges by what is on disk - not
by winget's exit code, which is non-zero for "already installed" too. No Node
afterwards stops the launch with the manual step spelled out.
`npm run dev` (web_command) and `npm install` (install_web) now get that folder
first on their PATH, so the launch goes on straight after the install without
restarting the launcher. start_web keeps a guard with a real message.
Spot-check: `winget show --id OpenJS.NodeJS.LTS --exact --source winget` names
the nodejs.org x64 MSI; nodejs::tests cover PATH-first, the fresh-install
folder, npm-without-node, and the argument list.
Two reasons an offline dev run's web client had no map:
1. Vite proxied every tile to the public tile host. web_command now sets
ODIAN_TILE_SERVER_URL=http://127.0.0.1:18081 for the Vite it starts, and
ODIAN_Engine's _WEB/vite.config.ts sends /basemap, /mvt and /netlayer there:
the site while it answers, this PC's installed tiles when it does not - the
same path the .exe already draws from.
2. The power-grid netlayer had no source offline. datasets.json named every
PostGIS overlay but `powerv2_postgis`, so the tile server answered
/netlayer/<ds>/powerv2/* with 404 "powerv2_render_sqlite not found" while
postgis_power_entities / _links / _topology sat in the local snapshot. Added
to POSTGIS_SOURCES; the tile server resolves it through the same
ODIAN_TILE_POSTGIS_DSN as the others.
Spot-check: with the site unreachable, /netlayer/<ds>/powerv2/bbox/8/128/86/131/89.json
answers 200 (721064 B, the same body the site serves) and topology.bin 200.
`npm run tauri dev` died before the window opened: Vite's watcher crashed
with EBUSY on target\debug\deps\odian_launcher_lib.dll. Root cause: the Cargo
workspace builds into target/ at the repo root, not under src-tauri/, and
vite.config.ts only excluded src-tauri - so Vite watched the DLLs the Rust
build holds locked.
Spot-check: a fresh clone, `npm install`, `npm run tauri dev` opens the
launcher window instead of "beforeDevCommand terminated".
A dev run's web client showed no live tracks while the .exe beside it did.
Root cause: the local API relays a request to the DHP only when it carries a
token that API minted itself (main.cpp's forwarder, the guard that keeps it
from being an open proxy). The .exe mints one with ODIAN_MINT_SECRET; the web
client was opened with ?user= only, so every /session/* call it made was
served from this PC's database.
The launcher now mints a token from this stack's API for the run's operator
(stack::mint_web_token) and opens the browser with it in the URL FRAGMENT
(StackConfig::web_url_signed). A fragment never reaches a request line or a
server log, and the launcher's own log still prints the tokenless address.
If the mint fails the web opens as before and the log says it shows this PC's
data only. Needs ODIAN_Engine's _WEB/src/auth.ts to read #token=.
Spot-check: launch dev mode with the web target while online; the API log
reads "now LIVE on the DHP" and the browser shows live tracks.
- Tauri 2 + Svelte 5 hub in ODIAN dark: patch notes and roadmap, install and
update progress, local stack status, settings with DHP and MCP addresses.
- crates/odian-packs: Rust installer for pack format v1 (signed manifests,
resumable verified downloads from a DHP or an ODIAN drive), byte-compatible
with ODIAN_MCP_Server's Python odian_packs.
- Local stack on 127.0.0.1: Postgres -> Engine API -> tile server -> Odian.exe,
one Job Object, clean shutdown; database snapshot restore on a fresh PC only.
- Keycloak sign-in through the DHP's MCP, remembered until Sign out with a
launcher session that renews the Engine token silently.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Kelorastus