Mission Text Sources: Where Goal and HUD Text Comes From and What a DLC Folder Can Change

Track missions/text, 2026-09-25. Files: tools/probe_mission_text.py and re_probes/missions/text/ (objective_strings.json, german.lang.cfile, german_overrides.json, chunk_22.resources, run.log, container.log, and this report). Only the game was read against, as well as re_probes/runtime_87400/module.bin. The game was not started, and nothing was installed.

python tools/probe_mission_text.py              # code + data + list + german: 122 Checks, ~10 s
python tools/probe_mission_text.py container    # Chunk copy + german.lang: 8 Checks, ~1 min

Result in Three Sentences

1. A DLC chunk cannot simply replace or supplement goal text. The language table is loaded exactly once at startup from gameresources + patch_1..4. This happens before any DLC chunk is mounted. It is only reloaded if sys_lang changes. It never happens when loading a map.
2. A goal with plain text or a new #str_ key will display as empty. missionobj.title is not text, but an idStrId. The Decl reader looks up the key in the currently loaded (English) table during parsing. If it does not find it, it writes 0, and 0 is displayed as "".
3. The smallest safe path is to use existing Retail missionobj Decls whose English text fits. Below are 30 checked goals. They are entered in Kiscule (ActionMission.objectives) by Decl name, and no new entries are needed in the container. Custom (German) texts can only go via a detour: You include strings/german.lang in the chunk and type sys_lang german into the console in-game. This path is built and structurally verified, but unconfirmed at runtime.

1. The Chain, Measured

Kiscule ActionMission (objectives = ["cobalt/c2v1/mission_c2v1_main_obj_01_find"])
   │  Decl-Name → idResourceList<missionobj> (Retail: all 338 in gameresources/patch_1..3)
   ▼
missionobj  = Class idDeclObjectiveMerc (0x3dc6108 → 0x2542c08, Field Table 0x22806c0)
   title  : idStrId (+0x88, 4 Byte)   desc : idStrId (+0x0c)   parentMission, material
   │  Decl Reader 0x1281060: FindIndex(Language Table 0x2fe02b0, "#str_…")
   │     found → Field = ID (FNV-1a-Hash of the lowercased key)
   │     not found / plain text → Field = 0
   ▼
Display 0x121d720: ID → Value from CURRENTLY loaded table, unknown → ""
   ▲
Language Table: idLangDict::Load 0x121c260, from strings/<sys_lang>.lang (cfile)

Loader 0xa6de20 has exactly three call sites in the entire .text:

LoadNamedResourceBlock (0xac1730), the location that mounts the DLC chunk when loading a map, does not call the loader. The loader searches for strings/<sys_lang>.lang first as a loose file. For this to work, com_loadlooseLanguages must be set, and that is a CHEAT and not exposed, so it is false. Afterwards, it searches via idResourceList<cfile>::Load in everything that is currently mounted. If the file is missing, it sets sys_lang back to english. idLangDict::Load replaces the table instead of mixing it (pointers and count are zeroed). If two keys result in the same ID, it reports "Computed a duplicate ID" and aborts (int3 after the error call).

Regarding which container is decisive for text: the base archives at startup. The DLC chunk only plays a role if sys_lang is switched while it is mounted.

Retail confirms this from the data side (daten):

• .lang files exist only in gameresources and patch_1..4, totaling exactly 10 languages. german and japanese are allowed in sys_lang but do not exist anywhere.
• dlc_1..3 contain 0 .lang, 0 mission, 0 missionobj, and 0 cfile. DLC mission texts were loaded via base/. Therefore, Retail never loads a cfile from a DLC chunk.
• Of the 338 Retail missionobj, 55 reference title keys missing from english.lang. According to the idStrId rule, their titles would be empty. They are listed in objective_strings.json under nicht_verwenden_leerer_titel (do not use empty titles).

2. What a DLC Chunk Can and Cannot Do

3. The Safe Way: 30 Retail Targets

Every line has been verified: The Decl exists in the start mount, its title key provides exactly this text in english.lang, and image material lies as a material Decl also in the start mount (two targets have none). Full data with description text, archive, and material is available in objective_strings.json.

Matching the four user wishes:

• "Eliminate the officers": #1 Kill all enemies or #3 Kill Everyone.
• "Find the documents": #10 Find New Orleans Dossier or #8 Search for Intel.
• "Survive three waves": #14 Stall Nazis, #6 Wreak Havoc or #2 Kill them all.
• "Reach the exit": #24 Find exit, #25 Find a way out or #23 Escape.

Negative finding: None of the 338 Retail target titles contain "survive", "wave", or "documents". Also, among all 23,224 strings, there is no short "Survive …". The only hit is a Doom rest in #str_menu_root_coop_help.

HUD frame texts are set by the game itself; they do not belong to the target. All following candidates exist. Which pair the HUD actually uses is unproven. #str_new_objective = "NEW OBJECTIVE", #str_objective_completed = "OBJECTIVE COMPLETED", #str_notification_newobj = "New objective:", #str_notification_completedobj = "Objective completed:", #str_notification_completedmission = "MISSION COMPLETED!".

4. The experiment for own German texts: strings/german.lang

Two files are built:

• german.lang.cfile, 478,384 bytes, sha256 e4ecac70…c540e9. This is english.lang from patch_4 with four changed values. These are exactly the keys that c2v1s targets (and the wave-Kiscule of the Kiscule-track for obj_01) already use:

The file has the same format as Retail: Kraken LEVEL_NORMAL, declen = plaintext length, AES-128-CBC and HMAC-SHA256 with the name strings/german.lang in the key. This path reproduces all 10 Retail .lang bytes identically, with their Salt and IV. The key set is identical (23,224). Thus no ID changes, and a duplicate-ID crash is excluded. Only the four lines differ; the rest is byte-identical. The Ü already appears in Retail texts ("Übercommander"), so the glyph is present.

• chunk_22.resources, 7,129 entries, sha256 8ad65ab7…e5814c. This is the installed dlc_0-chunk (byte-identical with re_probes/dlc4_override/chunk_22.resources, sha256 cadfbfce…) with cfile:strings/german.lang as the last entry. All 7,128 old lines (without offset) and payloads are unchanged. probe_datahash and probe_idclhash are green. The entry for plaintext is decrypted from the container. To apply this to the Kiscule-chunk: python tools/probe_mission_text.py container re_probes/missions/kiscule/chunk_22.resources.

Own texts set: python tools/probe_mission_text.py deutsch --set "#str_…=Text" …. Only existing keys are allowed, and no ", \, tab or line break. A new key is rejected (Section 2).

What remains open at runtime (the user tests, the master installs):

• whether idResourceList<cfile>::Load finds a cfile from a chunk mounted during map loading. Retail never does this (0 cfiles in dlc_1..3). It is plausible because the extkisclule of the chunks load via the same resource manager.
• whether the language switch mid-map has side effects. Language output: according to vo_localizeLangs_ROW ("other language will use english") falls back to English VO for German. Whether a runtime switch reloads VO is unknown.
• which HUD texts are redrawn: The first objective message appears ~4.6 s after start and thus before every console command. Objectives that start or are completed after the switch should show the new text.

sys_lang is exposed (settable in Retail), but not ARCHIVE. After every restart, the language reverts to english. If started without a mounted chunk, german cannot be found and resets to english. Reverting means: sys_lang english or a restart.

Runbook (only if the Master installed the Chunk)

1. Start the game with +com_enableDeveloperMode 1 and begin the Gestapo Office mission normally.
2. After loading, open the console and enter sys_lang german.
3. Expect in qconsole.log: Reading strings/german.lang as UTF-8, followed by … strings read with the same count as when starting with english.lang. Then, in the pause menu or at the next objective message: "Eliminate the officers" instead of "Enter the offices".
4. Control test: If it says Reading strings/english.lang, then german.lang was not found in the mounted chunk. This is a precise negative finding for "cfile from DLC Chunk", no reason to fiddle with the container.
5. Revert: sys_lang english or restart.

5. Tests

run.log: 122/122, container.log: 8/8.

6. Open

• Runtime of the german.lang path (Section 4). Everything else is statically proven.
• Whether a new missionobj Decl in the Chunk (Title = any existing key from all 23,224, e.g., #str_useable_exitlevel = "Exit level") is loaded. Retail DLC chunks contain none. This would be the next stage beyond the 338 Retail objectives, but was not built.
• g_debugMissions (proposed by anatomy as runtime aid) is CHEAT and not exposed, so according to cvartable it is not settable in Retail.