Lobby: detect, hash and match installed archives

[CubeB]

From the ROADMAP: mod management is the stated reason the launcher exists. Before a network game starts, every player should be running the same data.

Needed

• Detect the installed .hpi, .ufo, .ccx and .gp3 files in the data directory, in the order the VFS loads them (src/rwe/vfs).
• Hash them. Community packs are large (the V maps .ufo from A zlib chunk with no trailer is read to its declared size #35 is 2.1 GB), so cache hashes by path, size and modification time, and hash in the background.
• Show each player's set in the lobby, and refuse to start when they differ, naming the file that differs.

Where. launcher/src/ (launcher, game-server, master-server, common), and the engine's rwe_bridge JSON IPC if the engine should report what it actually loaded.

Done when two launchers with different archives cannot start a game together, and the lobby says which archive is the problem.

🤖 Generated with Claude Code

https://claude.ai/code/session_018moxVoyHDBoHqkw8uqS3HX

[HectorBailey]

Questions before starting:

1. Who computes the hashes. The launcher already tells the engine its data paths (add-data-path over the bridge, --data-path on launch). The engine is the one that knows the VFS load order and can read every archive it will actually mount, so the honest source is a new bridge command, say data-manifest, returning [{path, size, mtime, hash}] in load order. The issue says the IPC contract must not change (Launcher dependency refresh: Electron 22, React 16, and two open dependabot PRs #11), but adding a command is additive. Is a new command acceptable, or must the launcher hash the files itself in TypeScript and only mirror the engine's load order?
2. Which hash and how much of the file. A full SHA-256 of a 2 GB .ufo is seconds on a warm cache and minutes cold. Two cheaper options: hash the HPI directory block only (HpiHeader.directorySize bytes from start), which changes whenever any entry changes; or full-file hashing cached by (path, size, mtime). The first is fast and catches every real difference short of someone rewriting a file's bytes in place with the same directory; the second is airtight. Which do you want, or the first with the second as a background verification?
3. What "match" means. Exact set equality in load order, or set equality ignoring order (a .ufo renamed still loads the same content)? And are the base archives (totala*.hpi, rev31.gp3) compared too, or only the community .ufo/.ccx/.gp3 packs on the assumption everyone has the same game?
4. Where the refusal lives. The game-server is the one place that sees every player's manifest. I'd have it refuse start with the first differing entry named, and the lobby show each player's list with the odd one out marked. Fine?

[CubeB]

1. A new bridge command is fine. data-manifest adds to the contract rather than changing it, and the engine is the one that knows what it mounts and in what order.
2. Hash whole files, and cache by (path, size, mtime). Compute them in the background when the launcher starts, and have the lobby show "checking" until a file is done. A pack is only slow the first time. A directory-block hash would miss a file rewritten with the same sizes. That's rare, but it would surface as a desync mid-game, which is the worst place to find it.
3. Match exactly, in load order, and include the base archives. Order changes content: a later archive overrides an earlier one's files, so the same set in a different order can load different data. rev31.gp3 and the .ccx files differ between releases and patch levels, so they're compared too.
4. Yes to refusing in the game-server, naming the first differing entry, with the odd one out marked in each player's list in the lobby.

🤖 Generated with Claude Code

https://claude.ai/code/session_018moxVoyHDBoHqkw8uqS3HX