Wolfenstein Modloader Buy me a coffeeKaffee spendieren

Wiki / Research reportsForschungsberichte

Map/DLC Selection Logic (Static Findings)

Partly solvedTeilweise gelöst Original page in the GitHub wikiOriginalseite im GitHub-Wiki

In plain wordsIn einfachen Worten

Wolfenstein II: The New Colossus describes each map in a spec file that names its main archive chunk and extra dependencies. This report asks what happens when a DLC spec uses the same map name as the base game: which one wins? Static analysis shows the DLC entry is a plausible candidate but does not prove it wins. Save files store the map name and layers but show no sign of choosing between base and DLC. The page ends with one precise in-game test to settle the question.

  • chunkid names a map's main archive; refchunks only adds extra dependencies and does not override the base.
  • Several hypotheses were refuted, for example that layer or basechunkid decides the choice.
  • Save files contain the map name, start point and layers; their checksum is not a map or container ID.
  • Earlier launch tests with +map, +exec and +loadGame were ignored before the menu, so no runtime result exists.
  • The proposed test: load a save of the same map through the menu and look for a unique marker asset in the DLC chunk.

Wolfenstein II: The New Colossus beschreibt jede Karte in einer Spec-Datei, die ihren Haupt-Chunk und zusätzliche Abhängigkeiten nennt. Dieser Bericht fragt: Was passiert, wenn eine DLC-Spec denselben Kartennamen wie das Hauptspiel nutzt – wer gewinnt? Die statische Analyse zeigt, dass der DLC-Eintrag ein plausibler Kandidat ist, beweist aber nicht, dass er gewinnt. Spielstände speichern Kartenname und Layer, zeigen aber keine Auswahl zwischen Hauptspiel und DLC. Die Seite endet mit einem genauen Test im Spiel, der die Frage klären soll.

  • chunkid nennt das Hauptarchiv einer Karte; refchunks fügt nur zusätzliche Abhängigkeiten hinzu und überschreibt das Hauptspiel nicht.
  • Mehrere Hypothesen wurden widerlegt, etwa dass layer oder basechunkid die Wahl entscheidet.
  • Spielstände enthalten Kartenname, Startpunkt und Layer; ihre Prüfsumme ist keine Karten- oder Container-ID.
  • Frühere Starttests mit +map, +exec und +loadGame wurden vor dem Menü ignoriert. Ein Ergebnis aus dem laufenden Spiel gibt es daher nicht.
  • Vorgeschlagener Test: einen Spielstand derselben Karte übers Menü laden und nach einem eindeutigen Marker-Asset im DLC-Chunk suchen.

Technical detailsTechnische Details

Der technische Teil ist auf Englisch – so, wie er im Wiki steht. Unterstrichene Begriffe haben eine Erklärung auf Deutsch.

Result

For identical name, the DLC entry is a plausible primary candidate, but it is not statically proven as the winner against the Base entry. Retail data instead clearly distinguishes between the primary map source (chunkid) and additional dependencies (refchunks).

Savegame data contains the requested map name and Layer/Start metadata. They are therefore a possible input for Map/Layer loading before the actual map asset reading; however, no static finding shows that they write a Base/DLC priority over the Container mount. game.details is display/save metadata, not proven as the selection source.

Retail Specs and Field Meaning

The complete Retail evaluation in docs/patchvorrang.md and docs/dlcmod.md finds:

Source Example Finding
Base base/packagemapspec.json game/wolf/c02/c02p0: chunkid: 1, basechunkid: 0, layer: 0 The base map is primarily described from chunk_1.
Retail DLC 1/2 chunkid: 20/22, basechunkid: 6, layer: -1, refchunks present Own DLC chunk plus explicit dependencies.
Retail DLC 3 chunkid: 24, basechunkid: 6, layer: -1, no refchunks The primary DLC chunk functions as an independent map source.

Parser literals in the EXE lie adjacent to refchunks, chunkid, basechunkid, packagemapspec.json, patchinfo; this supports separate parser inputs, not a priority rule.

The data comparison confirms refchunks as a dependency: registered chunks are significantly less duplicated in the DLC (15 remaining copies), while unregistered dependencies are strong (1,495 copies). Therefore, an entry like refchunks: [26] can additionally mount chunk_26, but does not make it the primary source of the map.

layer and basechunkid are not a safe priority function: basechunkid 6 appears in Base with layer 1, and in DLC with layer -1. The 1:1 relationship only holds within the Retail Base Spec. EXE Cvars like resource_ignoreLayers and com_forceAllMapLayersToLoad show layer filters, but do not prove that layers decide Base vs. DLC name resolution.

Existing Test Artifacts

The own primary spec is structurally appropriate:

{
  "name": "game/wolf/c02/c02p0", "chunkid": 26,
  "basechunkid": 6, "layer": -1, "refchunks": [1]
}

It is located in re_probes/tnc_dlc_test/dlc_4/base/packagemapspec.json as well as runtime copies. RESULT.md documents that the loader finds dlc_4 and accepts the spec syntactically. A container with a false header field +0x08 is rejected with container chunk_26.resources has corrupt header; this is an integrity/mount gate, not a priority finding.

The direct probe run did not produce a map loading section: +map, +exec, and +loadGame were ignored before the menu. Therefore, there is currently neither a positive nor a negative runtime result for the same-name collision.

Savegame/Map Metadata

Read findings on existing TNC save states (game.details and checkpoint_mapstart.dat):

  • game.details writes mapName=... along with difficulty, gamePlayTime, mission/material names, and a content-dependent checksum. The same map name appears in multiple slots with different checksums; the checksum value is not a proven map ID or container ID.
  • The relevant GAME-CHALLENGE save for c02p0 has mapName=game/wolf/c02/c02p0. SLOT2 contains additional c02p0 saves.
  • checkpoint_mapstart.dat contains the map name multiple times, as well as the Player start and layer names. For the c02p0 save, among others are layer/base, layer/c02p0, layer/wyatt, layer/code; for the DLC save c00v1, layer/dlc/c0v1 is present. This indicates saved layer/start state data, not the origin (Base/DLC) of a similarly named container.
  • The 4-byte file header is reproducible as an MD5 MD5_BlockChecksum over the payload for .dat files (tools/savehash.py), while game.details remains plaintext. This verifies file integrity but says nothing about map spec priority.

Decision: Savegame metadata can specify the target name and layers to load. No existing dataset proves that it selects a Base/DLC entry before Mount or replaces chunkid/refchunks. This must be observed via the actual save/load menu path with logs.

Single Test: Clear Decision Conditions

  1. Before the run, the Base spec c02p0 must remain unchanged (chunkid 1). The DLC spec must contain the same name with chunkid 26, basechunkid 6, layer -1, refchunks [1], patchlevel 4.
  2. chunk_26 must contain a valid header (+0x08) and a uniquely identifiable Canary resource; an incorrect header ends the test before priority decision.
  3. Load an existing c02p0 game state via the menu/savegame load path. Do not use +map/+exec as the sole abbreviation, since this exact path was ignored before the menu in the previous run.
  4. In the log, first secure Mount/Map assignment and then the Canary proof.

Evaluation:

  • Canary visible + c02p0 loads: DLC map spec was selected for the name and chunk_26 won the collision.
  • c02p0 loads, Canary missing, Base asset remains: DLC spec may have been assumed, but chunk_26 is not the winning source; confirmed Mount speaks to Base priority.
  • GetIsChunkForMapInstalled/missing map: Assignment or dependency count incomplete; no priority verdict.
  • Could not load mapspec: Spec form rejected; no priority verdict.
  • corrupt header/container entry defaulted: Integrity/hash gate; mark the run as non-decisive.
  • Savegame loads a different name than expected: Save/menu state is the confounder; repeat the run before Base/DLC priority is evaluated.

The discriminating comparison is exclusively a uniquely different Canary in the primary chunk_26 against the unchanged Base result. A refchunks: [26] test is not a priority test and counts as a negative control.

Failed or Overly Strong Hypotheses

  • "refchunks overrides the Base Chunk" — refuted as a test design flaw: Refchunks are additional dependencies; the existing refchunk mechanism does not demonstrate override priority.
  • "layer == f(basechunkid) determines selection" — refuted: basechunkid 6 carries both Base layer 1 and DLC layer -1.
  • "game.details checksum is Map/Container ID" — not confirmed: it depends on game content and was not identified as a Map ID or Chunk ID.
  • "Map name in Savegame proves the Container" — not confirmed: the same name appears as a Request/Status in both Base and DLC contexts; origin is not listed as chunkid there.
  • "Header-+0x08 error proves Base Priority" — refuted: the container is discarded before the actual collision occurs.
  • "Direct CLI start determines priority" — failed: the existing run ignored the used startup commands prior to the menu and did not generate a LoadMap section.

This renders the static response testable up to the Mount/Load boundary: The primary candidate is determined by the same-named DLC Map Spec entry with chunkid; whether this entry displaces the Base entry upon collision remains reserved for the above-defined single measurement.