Wolfenstein Modloader Buy me a coffeeKaffee spendieren

Wiki / Research briefsForschungsaufträge

Research brief: Texdbkey

OpenOffen Original page in the GitHub wikiOriginalseite im GitHub-Wiki

In plain wordsIn einfachen Worten

This page is a task description for Wolfenstein II: The New Colossus. Its texture databases (.texdb) store textures under numeric keys with no names, so a new or renamed texture cannot be added without knowing how the key is formed. An earlier rule was refuted because it matched only about 5 % of entries. The worker was asked to find the real rule in the game code, prove it on a large sample across at least three databases, or, if no rule exists, say whether a custom texture can reuse an existing key.

  • This was called the last unsolved format blocker for custom textures.
  • A .texdb has no asset names; chunk_24.texdb is about 1 GB with 8,586 entries.
  • The old rule 'key = hash_0x60 << 4 | level' matched only about 5 %, so it is refuted.
  • A 1:1 mapping does exist (106 keys for 107 streamed images in chunk_8), so some rule must exist.
  • Proof must be counted as n/n; 5 % is coincidence, 100 % is a rule.

Diese Seite ist eine Aufgabenbeschreibung für Wolfenstein II: The New Colossus. Die Texturdatenbanken (.texdb) speichern Texturen unter Zahlenschlüsseln ohne Namen, daher kann man keine neue oder umbenannte Textur einfügen, ohne zu wissen, wie der Schlüssel entsteht. Eine frühere Regel wurde widerlegt, weil sie nur etwa 5 % der Einträge traf. Der Worker sollte die echte Regel im Spielcode finden und an einer großen Stichprobe aus mindestens drei Datenbanken beweisen, oder, falls es keine Regel gibt, klären, ob eine eigene Textur einen vorhandenen Schlüssel mitbenutzen kann.

  • Das galt als letzte ungelöste Formathürde für eigene Texturen.
  • Eine .texdb enthält keine Asset-Namen; chunk_24.texdb hat rund 1 GB und 8.586 Einträge.
  • Die alte Regel 'Schlüssel = hash_0x60 << 4 | Level' traf nur etwa 5 % und ist widerlegt.
  • Eine 1:1-Zuordnung existiert (106 Schlüssel für 107 gestreamte Bilder in chunk_8), also muss es eine Regel geben.
  • Belege müssen als n/n gezählt werden; 5 % ist Zufall, 100 % eine Regel.

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-texdbkey-a1; task texdbkey; research (read-only RE). Read .agent-cache/WORKER.md. Bus: python "%USERPROFILE%/.claude/skills/agent-cache-orchestrator/scripts/acbus.py" Parallel: w-cvartable-a1 reads the same image read-only. Astra workers on another host are idle pending a runtime test. Stay in your lane.

Objective

Find the TexDB lookup key. This is now the LAST unsolved format blocker for custom textures in Wolfenstein II - everything around it fell today.

Answer with code evidence:

  1. How does the engine turn an image resource into a TexDB lookup? Which function, which key, which input?
  2. Can a renamed or newly added image be given a key that resolves? If yes, the derivation. If no, exactly what stops it.

What is already measured - build on it, do not redo it

  • re_probes/agent_reports/texdb_rewrite.md: the .texdb is a flat key/offset database with NO asset names in it. Header, table and payload are gapless. chunk_24.texdb is ~1 GB, 8586 entries. Names cannot be rewritten there.
  • REFUTED today, do not build on it: the rule "texdb key = hash_0x60 << 4 | level" from an earlier worker. w-datahash-a1 measured it over ALL 24 base/*.texdb (24713 distinct key>>4): chunk_8 4/138, gameresources 650/12194, chunk_1 38/732, chunk_16 20/357 - about 5 %, not 100 %. Control: +0x50 matches in 0 cases. Evidence in re_probes/datahash/hash60_survey.txt.
  • The 1:1 mapping does exist (chunk_8.texdb: 106 ids for 107 $streamed images), so there IS a rule - the old one just is not it.
  • entry+0x60 for image entries is a value assigned by the build tool. No reader recomputes it (all 13 read sites compare against another stored field, see re_probes/agent_reports/datahash.md). It may still be an INPUT to the key.
  • The level/mip part of the old rule may well be right; it is the other half that fails. Test the halves separately.

Sources / starting points

  • re_probes/runtime_87400/module.bin - read-only capture of the RUNNING, SteamStub-unpacked NewColossus_x64vk.exe. Virtual RVA layout: file offset == RVA. Sections and image base in manifest.json. .pdata gives function bounds.
  • Follow the method that worked five times today: go through the code, not through hash sweeps over data. Read re_probes/agent_reports/idclhash.md and datahash.md first - they hand you the container parser (idResourceStorage::OpenContainer 0xACB780-0xACC441), the payload reader (ReadResourceData 0xACD7C0-0xACDCFD), FarmHash64 at 0x1363B80 and MurmurHash64B at 0x12BB970. The texture path very likely branches off near ReadResourceData or the streaming path at 0xACD8DB.
  • Error/usage strings in .rdata mentioning texdb / texture / streamed, and their xrefs, are a second way in.
  • tools/probe_texdb.py (read-only) can already parse header, offsets and streams. tools/probe_datahash.py has a working murmur64b and the hash60 survey code. Reuse rather than rewrite.
  • capstone 5.0.7 vendored: PYTHONPATH=re_probes/python_deps python ...
  • Corpus, READ ONLY: /steamapps/common/Wolfenstein.II.The.New.Colossus

Ownership

tools/probe_texdbkey.py (new), re_probes/texdbkey/ (new dir), re_probes/agent_reports/texdbkey.md (new).

Forbidden / do not touch

No game launch, no process attach, no writes under the Steam install or "%USERPROFILE%/Saved Games". Do not touch other workers' files: tools/probe_idclhash.py, tools/probe_datahash.py, tools/probe_cmdtable.py, tools/probe_saveverify.py, tools/probe_cvartable.py, tools/probe_texdb.py, tools/tnc_.py, tools/vtpixel.py, re_probes/{idclhash,datahash,cmdtable,saveverify,cvartable,vtrest,map_alias_v3}/, docs/, wolfsdk/*, config.json. No pip install.

Hard constraints

Python 3.11, stdlib plus vendored capstone. Reproducible from the command line, no running game required.

Acceptance criteria

  • Positive control at today's bar: reproduce the stored key for a large sample of real image entries across at least three different .texdb, and state the count as n/n. 5 % is a coincidence, 100 % is a rule.
  • Negative controls: the derivation must fail on a wrong mip level, a wrong input field, and a deliberately altered name or hash.
  • If the key turns out to be assigned by the build tool with no derivable rule, say so - and then answer the practical question instead: can a custom entry simply REUSE an existing retail key, and what breaks if two entries share one? That answer is worth as much as the derivation.

Verification expectations

Every important assurance needs a check designed to fail if it is false. A rule that matches 5 % is not a rule; the refuted hypothesis above is exactly what that looks like, so calibrate against it. Keep "key found in the table" and "key computed from the resource" strictly apart.

Failure honesty

A clean negative with the exact obstacle is a good result. Report failed hypotheses with their hit rates, the way hash60_survey.txt does.

Coordination / deliverable

Checkpoint at milestones. Publish a bus fact when the verdict is known - textures are the last format blocker, so both masters want this. Concise German report in re_probes/agent_reports/texdbkey.md. Finish the bus task when done.