R4 Research Report: Save Structure, Chapter Selection and Loadout (TNC)

Builds on the existing save-structure, checksum and save-verify research. Read-only against the real archives and a backup corpus of save files; no file under the live save folder or the Steam install was written.

Summary

The question was how a TNC save names its chapter/checkpoint, where the live player inventory lives inside it, whether a hand-edited save can start the kit/sandbox map at a chosen spot with a chosen loadout, and which checksums protect a save. The useful answer is that the save file is not the right lever at all: TNC ships a complete, plain-text, already-editable decl-level mission system — the same one every Challenge or Freedom Chronicles menu entry already uses — that picks the map, a named spawn point, the player-character variant and the starting weapon list, with no save editing involved. Editing checkpoint.dat directly remains the inferior path: its live weapon-state block is now fully decoded byte-for-byte (both the reader and writer functions were disassembled), but what the decoded numbers actually mean is still an inference, not read from the consuming code. One previously-unsolved checksum (the plain-text game.details file's own checksum= field) was solved this round. Everything below is read directly from real save/archive files; nothing was tested with the game actually running, beyond citing the project's already-confirmed decl-edit precedent (an unrelated field, pistol magazine size).

1. Map/chapter naming and the decl-level chapter system

A save's two leading identifier-looking fields in checkpoint.dat turned out to be a constant build/version stamp, identical across all 25 real save files checked (five backups plus every save in the live save folder, from two different maps and three different save-slot kinds) — not a per-checkpoint id as an earlier pass had guessed. There is no separate short "checkpoint name" field; which point in the level a save represents is carried by the slot name, the map path, and the live inventory state, not a dedicated id.

The actual mechanism that picks a map, a spawn point, a player-character variant and a starting loadout is a decl type with 105 entries, one per chapter/district/bonus-map/challenge/DLC episode, e.g. (shortened):

chaptervariation:dlc/c2v1
{
    parts = { item[0] = { map = "game/dlc/c02/c2v1"; playerDef = "..."; spawnSpot = "c2v1_gameplay_player_start_1"; } }
    unlockVariations = { ... }
}

spawnSpot names an actual placed entity in the map (the engine's own "player start" class), never a coordinate — the same map routinely carries several named starts (a normal one and a separate one for its Challenge variant). playerDef selects a player-character variant decl (own model, health multipliers) — this is why Chronicles episodes play as a different character and why some story chapters reskin the main character.

Pairing with starting loadout is not one name convention. An exhaustive check against the other 43-entry starting-loadout decl type found only 66 of 105 chapter entries matched by either of two naming conventions. Reading the other 39 individually (not guessed) splits them cleanly: about 11 are abstract template decls never themselves launched, one is a dev-only reference map, 7 real playable entries get their forced loadout through a second, independent mechanism instead (the character variant's own baked-in starting-inventory block), and the remaining ~20 are ordinary continuing story chapters that get no forced loadout at all — they simply keep whatever the player is already carrying. This matters: a loadout reset is the exception at specific scripted points, not a blanket per-chapter grant.

2. Player inventory

Starting/chapter-entry inventory is decl-level and directly editable, same mechanism as every other proven decl edit:

• The one global player entity has exactly one baked-in starting item (a perk tracker) — no weapon is hard-coded onto the base player.
• The 43-entry loadout-decl type covers major story checkpoints, challenge maps and DLC episodes, including a generic fallback explicitly named as a fallback/debug loadout that hands out 9 of the game's weapon families with ammo.

Live/mid-game inventory inside checkpoint.dat is one level deeper than earlier research reached. The weapon-tracking block is fully decoded, byte-exact, both directions: 13 weapon slots x 3 big-endian 32-bit values = 156 bytes, no per-field tags, confirmed identical across all 25 real save files, with both the reading and writing engine functions disassembled and shown to be exact mirrors of each other. What the numbers mean is still inferred, not proven: across all 25 files every nonzero value observed is exactly 3 (one single exception has a 3 in a different slot) — never a spread of values — which fits a capped per-weapon tier/counter much better than continuously-varying "ammo in reserve." The field's actual consumer was not read (would need a decompiler).

3. Starting a sandbox map at a chosen spot/loadout — without editing the save

Editing the save directly for this purpose is a known dead end from earlier rounds: even a structurally perfect hand-edited save candidate can't be shown to actually load, because the header checks are only half the loader's gate and a genuinely new map id still needs its full archive bundle present anyway. The decl-level chapter system above needs no save at all:

1. The sandbox/kit map is already reachable through the existing, proven custom-map route (claiming an existing map id via mod-folder precedence).
2. Chosen loadout = edit the matching loadout decl (or point the chapter entry at a different, already-full one, such as the generic fallback that already hands out 9 weapons) — the exact same mechanism as the proven magazine-size mod, just a different decl type.
3. Chosen spot = add one more named player-start entity to the map and point spawnSpot at it, or reuse the convention retail already uses twice for the same map (a normal start and a separate challenge start).
4. Reach it through the normal retail Challenges/Chronicles menu entry for that chapter — not a console command, and not a hand-edited save.

Open and not verifiable offline: which challenge entries are unlocked is almost certainly tracked in an encrypted per-profile file whose key wasn't recovered — reusing an already-unlocked slot (editing its map/spawn/loadout in place, keeping its name) sidesteps this; authoring a brand-new chapter entry does not.

4. Checksums a save carries

The game.details checksum was previously tried as a plain CRC32/Adler32 over the raw file and found to not match; the real formula (a sorted key+value dictionary CRC32, a known id-Tech formula) verifies 26 of 26 real game.details files checked (backups plus the live save folder), including a built-in negative control that mutates the map-name field and confirms the checksum then correctly fails.

Failed hypotheses

• The leading identifier pair in checkpoint.dat is a per-save checkpoint id — refuted, identical across all 25 independently checked saves.
• A name-convention pairing between the chapter-entry decl and the loadout decl covers "near every chapter" — narrowed to 66 of 105 by an exhaustive check; the rest split into template decls, a second independent loadout mechanism, and chapters that keep existing inventory.
• The game.details checksum as plain CRC32/Adler32 — already refuted in an earlier round; this round supplies the actual formula instead of leaving it open.

Open questions

• Whether the weapon-tracker's capped values (0 or 3 only, never anything in between) really are a tier/unlock counter rather than ammo — the field's consuming code was not read.
• Whether a new chapter entry's unlock flag can be set without touching the encrypted progression file — not attempted; reusing an already-unlocked slot avoids the question entirely.
• The next obvious adjacent block (mission/objective state) was identified by name in the save's component stream but not decoded this round.

Recipe for the sandbox map (spot + loadout, no save edit)

1. Mount the sandbox content under an existing, already-complete map id via the proven mod-precedence route.
2. Place one named player-start entity where the player should spawn.
3. Pick (or add) a chapter-entry decl for that map id whose spawnSpot is that entity's name, and whose paired loadout decl is edited to the desired weapon/ammo list.
4. Reach it in retail through the matching Challenges/Chronicles menu entry.

In-game test (for the tester)

A small, low-risk way to confirm the whole chapter/loadout chain without touching a save, using the same pattern as the already-proven magazine-size test:

1. Build a mod that edits one challenge's loadout decl, changing its starting ammo count from its retail value to something obviously different (e.g. 40 to 999).
2. Start the game, go to the main menu's Challenges section, and start that challenge (if not yet unlocked, play the normal episode once first).
3. Check the ammo readout on the HUD immediately at start: seeing the edited value confirms the whole mechanism (map + spawn + loadout via decls, no save involved) live.