Build Lock

Current build: 2026.08.11.1121610.2-Rel-i343-Meteorite-2607-CU4 (Steam), Unreal Engine 5.5.4 Locked: 2026-08-18 Lock file: config/hce-build.lock.json

Every finding in docs/ is only true of the build it was measured on, and the game updates without asking. Before CU3 each note restated its own hash, which meant eight places to update and eight chances to miss one. This is the single place that answers "what am I running, and is it what the notes describe".

---

Headline hashes

The tag-DLL hash is what selects a live-mode profile: the RVAs of the simulation's tag table and string-id registry in crates/blam-live/src/tagtable.rs belong to this exact binary (tag_table_and_string_ids.md). A tag DLL whose hash matches no profile is not refused: four code anchors recover the same globals from the module on disk (signatures/README.md, "The tag module's anchors"). The Xbox app's copy of the DLL differs from Steam's only in its header and signature (native/blam_console/mjolnir_blam_console.c), so its hash matches no measured profile and the anchors apply. The Xbox app also ships its own exe; this lock covers the Steam install only.

The lock file carries all 252 shipped files — every binary, all 31 IoStore container sets (.utoc/.ucas/.pak) and the bundled video, 74 GiB in total.

Not locked, on purpose:

• Binaries/Win64/ue4ss/ and Content/Paks/LogicMods/ — what we installed, not what shipped.
• *_P.pak/.ucas/.utoc override containers — installed mods by the pak loader's own naming convention. One (pakchunk990-MJOLNIRWORLD-Windows_P) had leaked into the CU3 lock, which surfaced when the vanilla CU3 depot download matched all 252 shipped files and "missed" exactly the three we had installed ourselves.
• Binaries/Win64/dwmapi.dll — the UE4SS proxy. It sits next to the executable rather than inside ue4ss/, so it looks shipped and is not. A lock that differs between a modded and a vanilla install cannot answer the question it exists to answer.
• *.dmp, *.log — local residue.

---

What CU4 changed

CU4 shipped on Steam on 2026-08-17 (its exe is stamped 2026-08-11, the build date). Verifying the CU3 lock against it reported 49 changed files and none added or removed: the host executable, the simulation DLL, 17 of the 31 container sets (global, pakchunk0, and most level chunks), and a third-party sweep (nine boost DLLs, libHttpClient, OpenColorIO, tbb, CrashReportClient).

CU3 was overwritten in place, but its depot manifest was still on Steam's CDN: tools/steam_depot_fetch.py recovered it bit-for-bit (all 252 shipped files matched this lock), both builds are snapshotted, and the CU3 → CU4 tag diff ran for real. See game_update_pipeline.md for the pipeline and what that diff found.

---

Using it

Regenerate after a game update, or verify an install against the committed lock:

python tools/build_lock.py "<install root>" --generated <date> -o config/hce-build.lock.json

python tools/build_lock.py "<install root>" --verify config/hce-build.lock.json

--verify reports the version mismatch first, then every changed and missing file, and exits nonzero if the install is not the locked build. It always hashes every file the lock lists: --binaries-only applies only when writing a lock. Without --verify it skips the 74 GiB content pass and prints a binaries-only lock in a few seconds; its version and host_sha256 are usually all you need to answer "did the executable move":

python tools/build_lock.py "<install root>" --binaries-only

A snapshot (HCE_SNAPSHOTS can stand in for --store) hashes the same files once and produces both the snapshot and the lock, so after an update prefer it to running the full pass twice:

python tools/game_snapshot.py --store D:/hce-snapshots snapshot "<install root>" --lock-out config/hce-build.lock.json

Paths are recorded relative to the install root, so two machines on the same build produce identical locks.

---

What has been re-verified on CU4

Verified on the CU4 binaries above (2026-08-18):

Verified in the running game (CU4, 2026-08-18):

defs/hce/tag-definitions.json and defs/hce/scripting.json are regenerated from the CU4 containers and stamped CU4 — the first corpus regeneration since CU2, which also retires the CU2-label caveat the previous revision of this note carried.

New tag content in CU4, per the CU3 → CU4 tagdiff: exactly one tag, the a10/unsc_cryo_capsule animation graph. The oddly named Cinematics/020la_sword/.../jorge_turret graph is present all the way back in vanilla CU2 — it is launch-era content, not update content. The two tags the full validation could not parse on 2026-08-18 failed identically on CU2, CU3 and CU4 — a long-standing decoder gap, not an update regression. It was fixed on 2026-08-19 (86f109dc), and both now parse end to end (see the pipeline note's known issues).

What is still CU3-or-earlier-measured

These notes carry an older build stamp and have not been re-measured against CU4. Most describe file formats, which move far less often than code addresses — and the CU4 corpus validating 100% structurally is indirect evidence the container and tag layout notes still hold — but nothing here should be cited as CU4-verified:

• halosimulation_tag_release.md — offsets into the simulation DLL, which is a different binary on CU4. Most likely to have drifted. blam-live locating and reading a live payload correctly is evidence the layout assumptions held, not the offsets.
• multiplayer_investigation_notes.md — the runtime reflection passes, session state captures and Ghidra results.
• The 13 root world package paths hardcoded in mjolnir_maps and tools/mcp/game/game.mjs were enumerated on CU3 and have not been re-enumerated, though A30 loading and playing on CU4 says the list is not entirely stale.
• tag_data_pipeline.md, tag_body_format.md, iostore_packaging.md — container and tag layout.
• ue_texture_format.md, wwise_audio_format.md, blam_script.md.