Wolfenstein Modloader Buy me a coffeeKaffee spendieren

In plain wordsIn einfachen Worten

This page is the task description given to a research worker, not a result. The question for Wolfenstein II: The New Colossus: map and devmap answer "unknown command" in the console, even with developer settings on. Is there any registered command that loads a map, and if so, what blocks it? The brief sets strict rules: read-only analysis of a memory image, two independent methods, and checks that must fail if a claim is false.

  • Starting point: map and devmap are rejected even with com_enableDeveloperMode, devMode_enable and g_demoDevMode set to 1.
  • Three answers are allowed: no map command exists, one exists but is gated, or one exists and is reachable.
  • The full command list must include commands known to work, such as writeConfig, conDump and listCvars.
  • A text string in the game file is explicitly not accepted as proof that a command exists.
  • No game launch, no writes to the install; the result is reported in the separate Cmdtable research report.

Diese Seite ist die Aufgabenstellung für einen Forschungs-Worker, kein Ergebnis. Die Frage zu Wolfenstein II: The New Colossus: map und devmap antworten in der Konsole mit „unknown command“, selbst mit Entwickler-Einstellungen. Gibt es irgendeinen registrierten Befehl, der eine Karte lädt, und wenn ja, was blockiert ihn? Das Briefing setzt strenge Regeln: reine Leseanalyse eines Speicherabbilds, zwei unabhängige Methoden und Prüfungen, die fehlschlagen müssen, wenn eine Behauptung falsch ist.

  • Ausgangslage: map und devmap werden abgelehnt, selbst wenn com_enableDeveloperMode, devMode_enable und g_demoDevMode auf 1 stehen.
  • Drei Antworten sind zulässig: Es gibt keinen Kartenbefehl, es gibt einen gesperrten oder es gibt einen erreichbaren.
  • Die Befehlsliste muss bekannte funktionierende Befehle wie writeConfig, conDump und listCvars enthalten.
  • Ein Text im Spielprogramm gilt ausdrücklich nicht als Beweis, dass ein Befehl existiert.
  • Kein Spielstart, kein Schreiben in die Installation; das Ergebnis steht im separaten Cmdtable-Forschungsbericht.

Technical detailsTechnische Details

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

Worker w-cmdtable-a1; task cmdtable; research (read-only RE). Read .agent-cache/WORKER.md. Bus: python "%USERPROFILE%/.claude/skills/agent-cache-orchestrator/scripts/acbus.py" (identical copy at %USERPROFILE%/.agents/skills/... ; use one consistently). Two other workers run in parallel on other hosts (astra-map-v3 = map bundle, astra-save-v3 = save serialization). Stay inside your ownership.

Objective

Enumerate the TNC retail command registry from the captured runtime image and settle one question with evidence: is there ANY registered command in the retail build that loads a map by name, and if so under which name and which gate?

Measured baseline you must explain, not contradict blindly: at runtime both map and devmap answer unknown command, even with com_enableDeveloperMode=1, devMode_enable=1, g_demoDevMode=1. Known to work at runtime: writeConfig, conDump, listCvars, listCvars - help. See docs/stand.md and re_probes/agent_reports/custom_save_registration.md.

Three outcomes are all acceptable; pick the one the evidence supports: (a) no map-loading command is registered -> the save/bundle route is the only route; (b) one is registered but flag-gated -> name the flag, the check, and whether a cvar or launch argument can satisfy it; (c) it is registered and reachable -> give the exact console syntax and the argument format it parses.

Sources / starting points

  • re_probes/runtime_87400/module.bin (92,188,672 bytes, layout "virtual RVA": file offset == RVA; image base 140695279042560 = 0x7FF6xxxxxxxx, pid 87400, captured 2026-09-23 00:26). manifest.json lists every section with rva/vsize. .text rva 0x1000, .rdata rva 0x1E62000, .data rva 0x2E39000.
  • Absolute pointers inside .data are runtime VAs: RVA = VA - base.
  • capstone 5.0.7 is vendored, no install needed: PYTHONPATH=re_probes/python_deps python ...
  • id Tech heritage: idCmdSystemLocal::AddCommand(name, fn, flags, description, argCompletion) keeps commandDef_t nodes {next, name*, args, function, argCompletion, flags, description*} in a linked list plus a hash table. The public Doom 3 / idTech 4 source is a legitimate reference for the layout; verify the actual struct against this binary, do not assume it.
  • Two independent attacks, use both and cross-check:
    1. data-driven: find the command name strings in .rdata, find .data words pointing at them, walk the surrounding struct, then walk next.
    2. code-driven: disassemble .text for lea rcx,[rip+<name-string>] feeding a common call target; that target is the registration function. Enumerate all its call sites to get every registered name plus its flags argument.
  • Existing string work: tools/probe_strings.py, tools/probe_devmode.py, tools/cvar_table.py (same technique for the cvar table, likely reusable).

Ownership

tools/probe_cmdtable.py (new), re_probes/cmdtable/ (new dir, all artifacts), re_probes/agent_reports/cmdtable.md (new).

Forbidden / do not touch

No launching the game, no writing to the Steam install, no writing to "%USERPROFILE%/Saved Games", no process attach or memory writes. Read module.bin read-only. Do not edit anything owned by others: tools/build_tnc_map_alias_v3.py, tools/verify_tnc_map_alias_v3.py, re_probes/map_alias_v3/, tools/build_custom_save_candidate.py, tools/probe_details_checksum.py, tools/verify_custom_save_candidate.py, re_probes/custom_save_candidates/, docs/, wolfsdk/, config.json. Do not pip install anything.

Hard constraints

Python 3.11, stdlib plus the vendored capstone only. The probe must be reproducible from the command line and must not depend on a running game.

Acceptance criteria

  • tools/probe_cmdtable.py prints and dumps re_probes/cmdtable/commands.json: one record per registered command with name, flags (raw int and decoded), description if present, function RVA.
  • The table is complete enough to contain every command already measured as working (writeConfig, conDump, listCvars, exec, bind, toggle, screenshot). If one of those is missing, the enumeration is wrong - say so and fix it, do not ship a partial list as complete.
  • Explicit verdict on map, devmap, spawn, teleport, god, noclip, killMonsters, reloadDecls, listCmds with the evidence per name.
  • If a map command exists, decode its flag word against the flags of a command known to work and a command known to be rejected, and state exactly what makes the difference.

Verification expectations

Every important assurance needs a check that FAILS if the assurance is false:

  • Positive control: the list must contain the commands measured as working.
  • Negative control: feed the same parser a deliberately wrong base/section offset and show it produces garbage or refuses - a parser that "finds" a plausible table at the wrong offset is not evidence.
  • Cross-check: the two attacks (data walk and call-site scan) must agree on the command set. Report the diff if they do not; the diff is the finding.
  • The string "devmap" existing in .rdata is NOT evidence that the command is registered. docs/stand.md already lists it from static strings and the runtime contradicts it. Distinguish "string present" from "AddCommand called" from "dispatchable at runtime".

Failure honesty

If the registry layout does not yield, report the exact obstacle with offsets and what you tried. A clear negative with evidence is a good result here and unblocks the other two workers. Do not produce a speculative command list.

Coordination / deliverable

Checkpoint at meaningful milestones (registration function located; table walked; controls passed). Publish as bus facts only what the other workers would otherwise rediscover - above all the verdict on map/devmap, because it decides whether the save-forging route is necessary at all. Final report in German, concise, in re_probes/agent_reports/cmdtable.md. Finish the bus task when done; a master verifies.