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).

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 landed on 2026-08-11. 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. --binaries-only skips the 74 GiB content pass and takes a few seconds, which is usually all you need to answer "did the executable move".

tools/game_snapshot.py snapshot <root> --lock-out config/hce-build.lock.json 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.

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 cannot parse fail identically on CU2, CU3 and CU4 — a long-standing decoder gap, not an update regression (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.