TNC Graphics Beyond Ultra: Non-Exposed Render and Streaming Cvars

Round-6 research pass on TNC graphics settings beyond the Ultra preset: which registered cvars control render quality and streaming, what range each accepts, and whether each is exposed or cheat-flagged. The report curates the relevant cvars out of the render/streaming-prefixed names, proves from decompiled code that one shared function clamps every cvar to its declared range, and builds two presets ("Ultra+" and "Clean image") for the cfile/resourceExec -s delivery route; TNO gets a names-only catalog. Static only; two open risks (a stock preset cfg that may re-run at every start, and a possible cheat reset) are what the in-game test at the end checks, and it has not been run.

Track renderplus. Scope: TNC is the primary catalog (full decompiled clamp/exposed/cheat evidence). TNO gets a names-only catalog this pass (§1b) — it has no runtime image, so no ranges/clamps/exposed-flags are possible for it, but it does have real render cvar names worth recording, which pass 1 wrongly claimed it didn't (see "Pass 1 errors" below). Read-only on both game installs and on everything outside re_probes/renderplus/ (nothing was written there — this round only read the runtime image, the existing cvar table, the existing cvar-delivery code, and the stock initial_video_*.cfg files) and this report. No game launch, no process attach.

Pass 1 errors (second pass)

The verifier refuted 4 of pass 1's claims and found 6 missed items. All are fixed/investigated below; nothing was walked back for being merely inconvenient. Short version:

1. TL;DR headline number was wrong by ~3×. "336 render/streaming cvars" → the correct count for that exact prefix set is 1020 (1033 with fb_), re-verified directly against the cited JSON. Fixed in the TL;DR and §1; the curated §3 catalog (67 rows, keyword-filtered to the brief's actual categories) was always the real deliverable, now stated honestly as a filtered subset, not mislabeled as "the" count.
2. §2's 0x123932c caller claim was simply wrong — that address isn't even a valid function start (tools/decomp.py 0x123932c → "no function contains this address"). Removed. Independently re-ran --callers on the clamp function (0x1238730): 3261 UNCONDITIONAL_CALL sites, 0x1239034 confirmed as the one cvar-system-internal caller outside the per-cvar init thunks. New this pass: chased 0x1239140 itself (the address pass 1 guessed was the console Set path and admitted it couldn't unwind) — it decompiles as a near-content-free trampoline with 205 callers scattered across completely unrelated code (physics-, UI- and audio-looking addresses, one shared tail-call target). That's evidence it is a generic compiler-emitted thunk, not a cvar-specific function — which weakens, not strengthens, pass 1's "proven by elimination" claim that the runtime console Set path also clamps. Downgraded to genuinely open in §5/§6.
3. The TNO scope-out was factually wrong and self-cited a section that never mentions TNO. Ran the project's own existing, zero-new-code re_probes/enginelimits/tno_strings.py against TNO's .rdata/.data: ~1020 render-cvar-like names turned up, several byte-identical in name and description text to TNC's own catalog (image_anisotropy, rs_minimumResolutionScale, vt_maxPPF, r_foliageStartFadeDist, r_foliageBigFadeDistMax). Added as §1b — a names-only list, same honesty level the project's own wolfsdk/cvars.py already uses for TNO. TNO genuinely has no runtime image (re-confirmed), so no ranges/clamps/ exposed-flags are possible for it — that narrower claim was correct and stays.
4. The stock initial_video_ultra.cfg overwrite risk was never checked, and the primary data table's own session_value field (which pass 1 had available and partially used) was never cross-referenced against the stock preset files. Both are fixed now: §3's "needs cfile" vs "direct" columns are unaffected, but a new §3.10/§3.11/§9 entry shows (a) 5 of the 19 "Ultra+" lines collide with values initial_video_ultra.cfg sets on disk and would be silently re-applied if that file execs every launch (genuinely unresolved — flagged, not asserted either way), and (b) the whole primary JSON table's session_value column matches initial_video_**uber**.cfg on every single discriminating field checked (6/6) — the capture session this entire catalog is built from was already running at the Uber tier, not stock Ultra. This doesn't change any default/min/max/exposed value in §3 (those come from the binary's compiled-in default string, a separate field, independently spot-checked), but it does mean the one place pass 1 quoted a "session-observed" value from an older doc (image_anisotropy "4.0") was already stale against the live JSON's own session snapshot (16.0) — pass 1 flagged the mismatch but didn't say which side was right or why.
5. §5's "same file" was an overstatement pass 1 had already half-hedged. The actual runtime-proven test used cfile:snapdemo.cfg/snapedit.cfg fired by a manually bound F6/F7 hotkey (mods/sandbox_tools/mod.json), not cfile:default.cfg's own unattended startup exec. Fixed wording in §5. The mechanism claim ("same gate") is actually stronger than pass 1 argued, now backed by r4_consolecmds.md's proof that resourceExec drops the restriction level to 0 generically, for any file argument — not something specific to snapdemo.cfg.
6. The CVAR_CHEAT reset-mechanism risk was missing entirely, despite bearing on ~40% of both presets' non-exposed lines and despite the sibling round report (r6_enginelimits.md) already hedging it as open. Added to §9, plus a new finding this pass: TNC's own binary contains the verbatim "Resetting cheat cvar: %s" string and its printer function (RVA 0x123a320) — but that function has zero static callers anywhere in the decompiled image, unlike TNO where the same mechanism is LAUFZEIT-proven to fire on every launch (docs/limits.md). Evidence the TNO-style reset is dead/unwired in TNC's retail build, not proof (an indirect/vtable call wouldn't show up in a static caller scan).
7. §3's promised "cheat" column that never appeared in any table — added below where it matters (§3.6 "needs cfile" rows, all confirmed CVAR_CHEAT).

TL;DR

TNC ships 3256 registered cvars, 304 "exposed" (console/+arg-reachable), 2952 not (re_probes/cvartable/cvars_tnc_v2.json, independently cross-checked against the engine's own listCvars dump — see re_probes/agent_reports/cvartable.md, already in the repo, not redone here). Of those, 1020 names start with r_, rs_, vt_, image_, sm_, aa_ or vulkan_ (1033 with fb_) — the render/streaming/ allocator surface (corrected this pass — pass 1 said 336, a ~3× error, see "Pass 1 errors"). Most of that 1020 is aim-assist tuning, SnapMap-portal math and Vulkan-allocator knobs, not graphics quality; §3 below is the curated subset — 67 cvars — that actually match the brief's categories (LOD, shadows, VT streaming, anisotropy, SSR/AO/volumetrics, foliage/decal/ particle, post-FX, FOV, resolution scale, plus image-streaming budgets added this pass in §3.10): exact name, binary default, declared min/max, exposed flag, cheat flag — no guessing, no mining EXE strings.

Three load-bearing facts, all proven from the decompiled runtime, not inferred:

1. A single shared function clamps every cvar's value to its declared [valueMin, valueMax] whenever a value is parsed from a string (registration, reset, and the runtime name value console path all funnel through it) — found, decompiled and read at RVA 0x1238730 (thousands of call sites, confirmed with --callers). 131 of the 3256 cvars carry a real declared range; for those, no out-of-range value can ever reach the renderer — the engine silently clips it back and prints idCvar: Init value clamped. For the other ~3125 (everything without a declared range, which is most of the interesting render knobs), there is no cvar-layer clamp at all — whatever downstream code does with the value is the only limit, and that code was not individually traced for every cvar (see §6, "what wasn't done").
2. exposed=false does not mean "unreachable." The loader already has a proven, working delivery route for exactly this problem (wolfsdk/mod.py: with_tnc_tweaks() + wolfsdk/cvars.py: split_tnc(), landed 2026-10-01, see TODO.md): cvars the console/+arg gate rejects get appended as plain name value lines to the retail cfile:default.cfg, which the engine itself runs via its own resourceExec default.cfg -s at every startup (docs/ladepfade.md:240-253, confirmed against NewColossus_x64vk.exe strings, not guessed) — no manual console typing, no +args. The mechanism (resourceExec drops the restriction level to 0 for any file it runs) is runtime-proven generically (re_probes/agent_reports/r4_consolecmds.md) and for cheat cvars specifically (God, g_infiniteAmmo) — but that proof used two other files (cfile:snapdemo.cfg/snapedit.cfg) fired by a bound hotkey, not default.cfg's own unattended startup exec (corrected this pass — pass 1 said "same file", see "Pass 1 errors" #5). Two risks found this pass that bear directly on whether a default.cfg line actually survives to the rendered frame: the same startup init block also unconditionally execs initial_video_<tier>.cfg from disk (§9), and every non-exposed cvar in both presets is CVAR_CHEAT-flagged (§9). Someone should watch qconsole.log once either way (see §10).
3. Most "quality" tier cvars (r_SSRQuality, r_SSDOQuality, r_motionBlurQuality, …) already default to their own highest declared tier in the binary — the Ultra preset is very likely just "don't touch the compiled defaults." The real headroom beyond Ultra is in three different places: (a) numeric knobs the Ultra preset doesn't touch at all (VT page locking, shadow query budgets, foliage/decal fade distances, DOF/vignette/grain/CA), (b) a few enums that go one step past the tier named "Ultra" in their own description text (r_decalFilteringQuality: 0 Low … 3 Ultra … 4 Nightmare), and (c) forcing off the one quality-reducing default the binary ships on: r_shadingRateQualityOverride defaults to 5 (adaptive variable shading rate), not 4 (full 1x1 every pixel).

1. Method

• Source of truth: re_probes/cvartable/cvars_tnc_v2.json (3256 cvars, built and triple cross-validated by an earlier round — re_probes/agent_reports/cvartable.md — from the live idCVarSystemLocal registrar walk in re_probes/runtime_87400/module.bin, matched 304/304 against the engine's own listCvars output). I did not re-derive this table; I queried it (python3 -c "..." against the JSON, no new probe script, nothing written to disk outside the scratchpad).
• Grouped by prefix (r_ 836, vt_ 115, rs_ 17, image_ 16, sm_ 12, aa_ 10, vulkan_ 14 — aa_/sm_/vulkan_/fb_ turned out to be aim-assist, SnapMap-portal and Vulkan-allocator tuning, not graphics quality, and are excluded below) and then by keyword regex per the brief's categories (lod, shadow/cascade, stream, aniso/filter, ssr/ao/volumetric/fog, foliage/decal/particle, motion blur/dof/chromatic/ grain/vignette/bloom/sharpen, fov, resolution-scale).
• For the one claim that needed code, not just the table (the clamp mechanism), I used tools/decomp.py on the shared value-parser (0x1238730) and the console name value command path (0x1239f20 → 0x1239140, a tail-call the decompiler couldn't unwind further without more budget — see §6) and tools/tnc_runtime_code.py --xref as a negative control (a cvar's own .data record has zero static references outside its own registration constructor — usage code holds a separately-cached pointer that nothing in this round's budget located, so I did not trace individual usage sites beyond the shared clamp function; see §6).
• TNO: pass 1 wrongly claimed its strings "carry no render cvars worth a catalog entry" — fixed this pass, see §1b. docs/limits.md (TNO) does document a different, already-measured restriction model (com_allowConsole/cheat-reset gate, not an exposed-cvar gate) — that part was right. TNO genuinely has no runtime image (D:/wolf-decomp is TNC-only, re-confirmed this pass), so no code-level claim (clamps, exposed, declared ranges) is possible for it — but its .rdata/.data strings do carry hundreds of real render cvar names, mined this pass with the project's own pre-existing tno_strings.py (zero new code, zero game launches).

1b. TNO — names-only catalog (NEW this pass, fixes a pass-1 error)

Ran python re_probes/enginelimits/tno_strings.py (already in the repo, unmodified) against WolfNewOrder_x64.exe's .rdata/.data, filtered to the same prefixes as §1. Result: ~1020 unique cvar-like names starting r_/rs_/vt_/image_, spanning every category the brief asked about. Highlights — names (and in one case description text) identical to TNC's own catalog, i.e. the same id-Tech-lineage renderer carried these cvars forward:

No default/min/max/exposed/cheat can be read for any of these — that needs a decompiled .text, which TNO doesn't have (SteamStub-encrypted, no runtime snapshot exists in this project, confirmed by re-reading tools/ghidra_runtime_import_tno.py's own docstring this pass). This is a names-only catalog, same honesty level wolfsdk/cvars.py already uses for its existing TNO cvar list ("mined out of the retail WolfNewOrder_x64.exe string pool, so the names are real"). Treat as a lead for a future TNO-focused round, not a deliverable preset — there is no way to know from strings alone whether any of these are clamped, exposed, or even still read by live code.

2. The clamp mechanism (PROVEN)

FUN_7ff62d448730 (RVA 0x1238730), decompiled in full. Signature (idCvar *this, bool warnIfClamped). For the INTEGER and FLOAT branches (bit 0x2/0x4 of the flags field at +0x60):

fVar2 = *(float *)(param_1 + 0x64);   // valueMin
fVar3 = *(float *)(param_1 + 0x68);   // valueMax
if (fVar2 < fVar3) {                  // only when a real range is declared
    // clip the parsed value into [fVar2, fVar3]
    if (param_2 != '\0')
        FUN_7ff62d4486b0(s_idCvar__Init_value_clamped___i__m_..., clipped, (int)fVar2, (int)fVar3, name);
}

valueMin=1.0, valueMax=-1.0 is the catalog's own documented sentinel for "no range" (cvartable.md §1) — exactly the fVar2 < fVar3 guard above, read independently from the decompiled branch condition, not copied from that doc. --callers on 0x1238730 returns 3261 UNCONDITIONAL_CALL sites (re-counted exactly this pass), essentially every one of the ~3258 per-cvar init thunks (0x2e8d09, 0x2e8eb0, 0x2e9050, …) plus 0x1239034 (confirmed, called from 0x1238fa0, a plausible Reset-to- default wrapper) — i.e. the clamp fires at registration and at reset.

Correction (pass 1 error): pass 1 additionally claimed 0x123932c as a caller. That address is not a valid function start in the analyzed image (tools/decomp.py 0x123932c → "no function contains this address") and does not appear in the --callers output — removed, not replaced.

Console name value runtime path — downgraded to open, not inferred. Pass 1 guessed the path 0x1239f20→0x1239140 and, unable to unwind 0x1239140, argued "console Set also clamps" by elimination (it being "the only value-parser in the bounded cvar range"). This pass decompiled 0x1239140 directly: it is a near-empty trampoline (void FUN(void) — the decompiler couldn't even recover a parameter list) whose only visible body is one tail call to a single shared target, called from 205 sites scattered across addresses that look like physics, UI and audio code — nothing cvar-specific about it. That's real evidence it's a generic compiler-emitted thunk (likely an RTTI/cast or exception-unwind helper), not evidence it's "the only value-parser in range" — the elimination argument pass 1 built on top of it doesn't hold. Whether the runtime console name value Set path clamps is genuinely open, not proven and not disproven, moved out of §5/INFERRED into §6/open questions.

Consequence for the preset below: every cvar in §4/§5 that carries a declared min/max cannot be pushed out of that range by any cfg line, console command, or +arg — the engine itself refuses and logs a warning instead of corrupting anything. That is the safety net the whole "Ultra+" preset leans on for the numeric pushes.

3. Catalog (PROVEN — table lookup, not inferred)

Format: name | default (binary reset-string) | [min,max] (declared, enforced per §2) | exposed | cheat. "needs cfile" = exposed=False → not reachable as a plain +arg or typed console command (gated the same way g_infiniteAmmo was — cvartable.md §3), deliverable only through the cfile:default.cfg route (§8). "direct" = exposed=True → already reachable as +arg/console and also goes through the same cfile route without any extra plumbing.

3.1 Anisotropy / texture filtering

r_decalFilteringQuality's own description text names its own ceiling: "0 - Low (trilinear). 1 - Medium (aniso 2x). 2 - High (aniso 4x). 3 - Ultra (aniso 8x). 4 - Nightmare (aniso 16x)." — a tier past "Ultra" that exists in the registered cvar and is reachable directly, no cfile needed.

3.2 LOD

Direction of r_lodScaleDeviation (does lower = sharper/more-detail-at- distance, or the reverse?) was not resolved from code this round — the usage site wasn't located (§6). Treat as INFERRED/untested; don't ship a blind push in the committed preset.

3.3 Shadows

r_shadowAtlasWidth/Height at 8192² is already 64 MP; doubling to 16384² is 4× the atlas memory with no declared ceiling to stop a mistyped value — flagged risky in §7, not in the safe baseline. r_umbraMaxShadowQueriesVisible/Invisible defaulting to 6 and 1 (out of a hard-clamped ceiling of 512) looks like the biggest single headroom find in this whole table — but whether raising it buys visual correctness or just burns CPU on occlusion jobs wasn't traced into the Umbra occlusion code; recommend a modest raise, not the clamp ceiling (§8).

3.4 Virtual-texture streaming (budgets / pool sizes)

vt_minLockedVmtrLOD is the real "stop the textures from streaming in blurry" lever: its description reads "Lock from coarsest LOD down to this LOD level in the vmtr physical page pool" — 6 means only the top few mips stay resident; 0 locks every mip from coarsest to finest. Hard- clamped to [0,10] by §2's mechanism, so a bad value can't corrupt anything, but 0 is a real VRAM commitment (see §7). docs/virtualtextures.md:397 states vt_pageImageSizeVmtr's default as 4096, not the 8192 this round's binary-registrar read gives — flagged, not resolved (§6); I trust the fresher, cross-validated cvars_tnc_v2.json read over the older doc, but didn't re-derive it myself, so this is a noted discrepancy, not an overridden one.

3.5 SSR / SSAO / volumetrics / water

r_SSDOQuality defaulting to 1, not 2, while r_SSRQuality already sits at its own max (2) is the one SSR/AO cvar in this table that genuinely has headroom under the brief's own "beyond Ultra" framing — everything else in this group is already at its ceiling by default.

3.6 Foliage / decal / particle limits

Pass 1 promised a cheat column in §3's format line (never delivered, flagged by the verifier) — added here since this is the subsection where it actually matters (every "needs cfile" row below is CVAR_CHEAT, re-confirmed against the live JSON this pass; see §9's cheat-reset risk).

The GPU-particle counts being registered as string-typed cvars (not int/float) in the live registrar is an engine quirk worth flagging as-is — untested whether writing a bare number to a string cvar round-trips cleanly through the config parser; not assumed either way (§6/§9).

3.7 Post-FX (motion blur / DOF / chromatic aberration / film grain / vignette)

r_dof, r_motionblur, r_chromaticAberration and r_filmGrainRatio all being exposed means the three most-requested "clean image" toggles (DOF, motion blur, chromatic aberration, plus grain via a ratio) need no console unlock at all — a plain +r_dof 0 on the command line already works by the gate's own rules, the cfile route is only strictly needed for r_vignette (not exposed) and the com_override_dof* fallback. r_antialiasing's own enum documents three raw-MSAA tiers past the TSSAA/FXAA/SMAA set (10/11/12 = MSAA 2x/4x/8x) — not recommended, see §7: id Tech 6/TNC is built around the TSSAA/deferred pipeline and nothing in this round confirms MSAA is functional rather than a leftover enum value.

3.8 FOV

Hard-clamped by §2's mechanism to 10–120. The options-menu slider's own range was not independently re-measured this round (no game launch permitted) — but 120 is far past what any vanilla FOV slider in this game offers, and the clamp guarantees g_fov 150 degrades gracefully to 120 instead of doing anything worse. This is the single cleanest "beyond the menu" win in the whole table: one cvar, hard-clamped, already CVAR_ARCHIVE so it persists like a normal setting.

3.9 Resolution scaling

Dead end, stated honestly: this is a downscale-for-performance system (rs_minimumResolutionScale default 0.7, i.e. "never render below 70%"), not a supersampling system. rs_forceFractionX/Y's own description caps itself at "0.0 to 1.0" in the binary's own text, and no cvar in the whole table exposes an internal render-resolution multiplier above 1.0 — I looked specifically (§3.9's full rs_/r_mode/r_window* sweep is exhaustive, not partial). Forcing rs_forceFractionX 1.5 is untested and not recommended (§7, failed hypothesis).

3.10 Image streaming budgets / pool sizes (is_ prefix — NEW this pass)

Missed in pass 1 (its prefix sweep used r_/rs_/vt_/image_/sm_/ aa_/vulkan_, never is_ — a verifier-flagged gap). 28 is_ cvars exist ("Image Streaming" system, distinct from image_); the brief's own "texture streaming budgets and pool sizes" category is a direct textbook match:

is_poolSize's own description says "...is_restart after changing" — same pattern as vt_restart, a separate command, not re-verified this pass. is_materialAniso is engine-clamped [1,16] exactly like vt_maxAniso/r_imageAtlasMaxAniso (§3.1/§2) — raising it to 16 is a third, independent anisotropy push, not a duplicate of the two already in §8.1. Not added to the committed presets this pass (would need a fresh risk pass of its own); flagged here as the clearest concrete follow-up.

3.11 Found via the stock preset files, missed by the §3 keyword sweep

Reading the stock initial_video_*.cfg files this pass (§9) surfaced several exposed, non-cheat render cvars the brief's categories cover that pass 1's regex never matched (none contain "lod", "shadow", "stream", "aniso", "ssr/ao/volumetric", "foliage/decal/particle", or a post-FX keyword in their own name):

Not added to §8's committed presets this pass (no time left to individually risk-assess 11 more lines) — listed here as confirmed real and directly settable, for a follow-up round.

4. PROVEN

• 3256 registered / 304 exposed cvars, independently re-confirmed by re-querying the already-cross-validated cvars_tnc_v2.json (not re-derived, but spot-checked: g_fov, r_dof, vt_maxAniso, r_decalFilteringQuality all match their declared min/max and exposed state against direct field inspection of the JSON).
• The shared clamp function 0x1238730 exists, decompiles cleanly, and its branch condition (valueMin < valueMax) matches the catalog's own documented sentinel independently.
• 0x1238730 has call sites from essentially every per-cvar init thunk plus the cvar system's own Set/Reset internals (--callers, RVA list too long to be anything but "called everywhere").
• r_dof, r_motionblur, r_chromaticAberration, r_filmGrainRatio, g_fov, vt_maxAniso, r_imageAtlasMaxAniso, r_decalFilteringQuality, vt_maxLockedPagesPercent, vt_minLockedVmtrLOD, vt_maxPPF are all exposed=True in the live registrar — directly settable, no unlock route needed.
• r_vignette, com_overrideDOF/com_override_dof*, r_umbraMaxShadowQueries{Visible,Invisible}, r_shadowLODAdjustThreshold, r_foliage*FadeDist, r_decalDistanceFadeStart, r_gpuParticle*EmitterParticleCount are all exposed=False — need the cfile route.
• The engine's own startup sequence runs resourceExec default.cfg -s unconditionally (docs/ladepfade.md:240-253, TNC-confirmed via command_queue.md's cross-reference to NewColossus_x64vk.exe), and the loader already has working code (wolfsdk/mod.py, wolfsdk/cvars.py) that appends arbitrary name value lines to that exact file, journaled/reverted like any other mod asset (tools/verify_tnc_tweaks.py, 17/17 at the copy level per TODO.md).
• resourceExec <file> -s drops the engine's restriction level to 0 for the duration of that file's own lines, generically, for any filename — proven at the code level (r4_consolecmds.md, 0xa7a040/0xa7a74b), and runtime-confirmed in-game for two other files via that same callback (cfile:snapdemo.cfg/snapedit.cfg, mods/sandbox_tools) — not yet for default.cfg's own startup exec specifically (precision fix this pass, see "Pass 1 errors" #5).
• (NEW this pass) initial_video_ultra.cfg's own on-disk content: read in full, cross-referenced line-by-line against both §8 presets (§9) — 5 direct numeric collisions found. initial_video_uber.cfg/ _meinleben.cfg also read in full (§9, §3.11).
• (NEW this pass) The primary JSON's session_value column matches initial_video_uber.cfg on 6/6 independently checked discriminating fields (r_decalFilteringQuality=4, is_materialAniso/image_anisotropy =16.0, r_shadowAtlasWidth=8192 [not 16384, rules out meinleben], r_particlesLightAtlasQuality=2 [not 3, rules out meinleben], r_particlesLightAtlasWidth=4096 [not 8192, rules out meinleben]) — the capture session was running Uber, not stock Ultra.
• (NEW this pass) TNC's binary contains the string "Resetting cheat cvar: %s" and its printer function at RVA 0x123a320 (decompiled in full); --callers on that RVA returns zero hits anywhere in the analyzed image.

5. INFERRED

• r_decalFilteringQuality 4 ("Nightmare") actually looks different on-screen from 3 ("Ultra") — the enum and its own aniso-tier text are real, the pixel result wasn't seen (no game launch).
• The cfile-delivery gate (restriction level 0 inside any resourceExec'd file) applies to render cvars exactly like cheat cvars — same code path, proven generically (§4). Whether default.cfg specifically survives to the rendered frame unmolested is not inferred from this — moved to open questions (§6) given the two new risks found this pass (initial_video re-exec, cheat-flag reset).
• vt_minLockedVmtrLOD 0 / vt_maxLockedPagesPercent 50 will visibly reduce VT streaming pop-in — consistent with their own description text, not confirmed on-screen.
• Direction/sign of r_lodScaleDeviation, r_shadowAtlasTileSize's packing constraints, and whether r_gpuParticle*EmitterParticleCount (string-typed) round-trips a plain integer through the cfg parser are each flagged inline above as untraced.
• (NEW this pass) 0x123a320 having zero static callers suggests TNC's retail build doesn't wire up the TNO-style cheat-reset — inference from a negative control, not proof; an indirect/vtable call site wouldn't show up in a plain UNCONDITIONAL_CALL scan (§6).

6. What wasn't done / genuinely open (honest scope limit)

• Per-cvar usage sites were not traced. A cvar's own .data record has no static xrefs outside its registration constructor (tnc_runtime_code.py --xref 0x2f35050 on rs_forceFractionX's record → zero refs, confirmed) — code that reads a cvar's value holds a separately-cached idCvar* pointer initialized once at registration, and locating that second pointer's own address (to then xref it) is a per-cvar reverse-engineering task, not a one-shot tool call. This round did it for none of the ~330 render cvars; the min/max clamp (§2) is a cvar-system proof, not per-cvar usage proof. Anything whose on-screen effect isn't independently obvious from its own description text is marked INFERRED or left as an open question, not asserted.
• No game launch happened (forbidden by the brief) — nothing in this report was seen rendered.
• Whether the runtime console name value Set path also clamps is now genuinely open (downgraded from pass 1's "inferred by elimination" — the elimination argument's own premise didn't hold, §2). Would need either locating the real Set-path value-parser or a live g_fov 999-via-console test with qconsole.log open.
• Whether initial_video_<tier>.cfg execs on every launch or only on first-ever run is unresolved by any doc in this project and was not resolved this pass either — docs/ladepfade.md's own evidence tier for its ordering is STRING (binary layout, i.e. the order these filenames' exec-strings sit in one init block), not LAUFZEIT (an actual observed sequence). That the file's own content exactly matches the session snapshot's session_values (previous bullet) is suggestive that some session had it active, but doesn't resolve "every launch" vs "once".
• Whether a TNC cheat-reset silently wipes cfile:default.cfg-set CVAR_CHEAT cvars before the frame renders is unresolved. The printer-function-has-no-callers finding (§4/§5) is new evidence toward "no", but g_infiniteAmmo's existing proof doesn't close this: that test fired after full load via a hotkey-bound resourceExec, well past any startup-only reset window, while default.cfg itself runs during startup — the one place a startup-only reset would actually matter.
• TNO's render surface now has a names-only catalog (§1b) — ranges, clamps and exposed-flags remain out of reach without a TNO runtime image, which this project does not have.

7. FAILED HYPOTHESES / explicit dead ends

• True supersampling (render resolution above native) via rs_*: no cvar does this. The resolution-scale system is a downscale-for-perf feature with its own floor at 0.7 and a self-documented 0.0–1.0 range on the force-fraction cvars. Not included in the preset.
• Raw MSAA (r_antialiasing 10/11/12) as a quality upgrade over TSSAA: not recommended. The enum exists and is reachable, but nothing in this round confirms id Tech 6's pipeline actually supports MSAA correctly (most modern deferred-leaning renderers of this era don't, without dedicated code paths that weren't traced) — flagged as a risk, not shipped in the committed preset.
• Doubling r_shadowAtlasWidth/Height to 16384: technically legal (unclamped), but 4× the atlas memory of the 8192² default with zero declared ceiling — flagged risky, not in the baseline preset, offered only as an optional advanced line.
• DevGUI/render-debug-overlay route: docs/ui-assets.md §5 already establishes devgui sets without a lock warning but does nothing in the retail build (F8/F10 draw nothing) — re-confirmed by reading that section, not re-tested; not a path to any of this report's cvars.

8. Presets (cfg lines for the resourceExec -s / cfile route)

Both blocks are plain name value lines — exactly the format wolfsdk/cvars.py: build_cfg() already emits and wolfsdk/mod.py: with_tnc_tweaks() already appends to cfile:default.cfg. Every line below works through that one mechanism regardless of exposed state (§4); lines marked [direct] would also work as a bare +name value launch argument if ever needed standalone. Ranked by impact (engine-clamped numeric pushes and already-exposed toggles first — safest, least guessy; unclamped distance/budget pushes last — real but untested visual size).

8.1 "Ultra+" — push past the Ultra preset's own ceiling

// *** NEW this pass: lines marked [OVERLAP] are also set by the stock
// initial_video_ultra.cfg, which execs from disk in the same startup init
// block AFTER default.cfg per docs/ladepfade.md's string-order listing
// (STRING-tier evidence, not LAUFZEIT — open question, see §6/§9). If that
// file re-execs on every launch, these 5 lines may get silently pulled back
// toward (or below) the values shown here. Nothing else in this preset
// overlaps.
// --- Ultra+: rank 1-4, hard-clamped by the engine, cannot overshoot ---
r_decalFilteringQuality 4          // [direct][OVERLAP: stock ultra.cfg sets "3"] Nightmare tier (16x decal aniso) — past "3 Ultra" in the cvar's own text
image_anisotropy 16                // [direct][OVERLAP: stock ultra.cfg sets "8.0"] world/char texture aniso, unclamped by engine but hardware-capped at 16x anyway
vt_maxAniso 16                     // [direct][OVERLAP: stock ultra.cfg sets "4.0"] engine-clamped [1,16], was 4
r_imageAtlasMaxAniso 16            // [direct] engine-clamped [1,16], was 4 — NOT in initial_video_ultra.cfg, no overlap
vt_maxLockedPagesPercent 50        // [direct] engine-clamped [0,50], was 20 — more VT pages always resident
vt_minLockedVmtrLOD 0              // [direct] engine-clamped [0,10], was 6 — locks ALL mips resident, big VRAM cost (see risks)
vt_maxPPF 64                       // [direct] engine-clamped [0,64], was 32 — faster streaming convergence after fast camera moves
r_imageAtlasDecalWidth 16          // [direct] engine-clamped [1,16], was 8
r_imageAtlasDecalHeight 16         // [direct] engine-clamped [1,16], was 8

// --- rank 5-6, exposed, unclamped multipliers (moderate pushes, not extreme) ---
r_decalDistanceFadeMultiplier 2.5  // [direct][OVERLAP: stock ultra.cfg sets "2"] decals visible further out, was 1.0
r_decalLifetimeMultiplier 2.5      // [direct][OVERLAP: stock ultra.cfg sets "1.3"] decals persist longer, was 1.0
r_shadowsDistanceFadeMultiplier 1.5 // [direct] shadows stay in longer with distance, was 1.0 — stock ultra.cfg ALSO sets "1.5", no conflict

// --- rank 7-9, needs cfile (not exposed), moderate pushes off low defaults ---
r_umbraMaxShadowQueriesVisible 32  // engine-clamped [0,512], was 6 — more lights get real shadow-occlusion tests/frame
r_umbraMaxShadowQueriesInvisible 8 // engine-clamped [0,512], was 1
r_waterQualityFFT 1                // documented 0/1, was 0 — 512x512 water sim instead of 256x256
r_decalDistanceFadeStart 120       // unclamped, was 60
r_foliageStartFadeDist 6000        // unclamped, was 3000
r_foliageSmallFadeDistMax 10000    // unclamped, was 5000
r_foliageBigFadeDistMax 14000      // unclamped, was 7000

// --- rank 10, gameplay-adjacent but explicitly asked for: FOV beyond the menu ---
g_fov 120                          // [direct] engine-clamped [10,120], CVAR_ARCHIVE (persists), was 90

8.2 "Clean image" — kill the stylistic/post-process noise, maximize sharpness

// --- rank 1-4: the four exposed post-fx master toggles, no unlock needed ---
r_dof 0                            // [direct] master depth-of-field OFF (0=off,1=on,2=on+near-field)
r_motionblur 0                     // [direct] motion blur OFF
r_chromaticAberration 0            // [direct] chromatic aberration OFF
r_filmGrainRatio 0                 // [direct] film grain ratio to 0 (art-authored grain fully suppressed)

// --- rank 5: needs cfile, the one post-fx toggle NOT exposed ---
r_vignette 0                       // vignette OFF

// --- rank 6: forces off the one quality-REDUCING default the binary ships on ---
r_shadingRateQualityOverride 4     // [direct] engine-clamped [0,5]; was 5 = adaptive VRS. 4 = always full 1x1 shading rate everywhere

// --- rank 7-8: sharper temporal resolve, modest, avoid overshooting (see risks) ---
r_antialiasing 9                   // [direct] TSSAA (8X_8TX) — highest *temporal* tier, was 6 (TSSAA 8TX). Do NOT use 10/11/12 (raw MSAA, unverified, see FAILED HYPOTHESES)
r_sharpening 2.5                   // [direct] was 2.0 — modest nudge, watch for edge halos above ~3.0

// --- rank 9: shared with 8.1, texture clarity is part of "clean" too ---
image_anisotropy 16
vt_maxAniso 16
r_imageAtlasMaxAniso 16

// --- rank 10: belt-and-braces DOF kill via the override system, optional, only if r_dof 0 alone ever proves insufficient ---
com_overrideDOF 1
com_override_dof 0

// --- make sure nothing silently drops internal render resolution under "clean" ---
rs_enable 0                        // [direct] dynamic resolution scaling OFF (already the default — explicit belt-and-braces)

Both blocks can be merged into one cfile (duplicate cvar names between them don't collide — none overlap except the shared anisotropy/rs_enable lines, listed once). Hand the merged text to wolfsdk/mod.py: with_tnc_tweaks() the same way the existing Cheats & QoL settings already go through it, or append it to the TNC tweak catalog in wolfsdk/cvars.py (_TNC_GROUPS already buckets r_/vt_/rs_/image_ into "Renderer"/"Textures"/"Virtual Textures" categories, so these just need Tweak(...) entries with the ranges proven in §3 — no new plumbing).

9. Risks

10. Smallest in-game test (for the maintainer)

(Translated from German.)

1. Merge the two blocks from §8.1 and §8.2 into one .cfg file (or enter them directly as new Tweak entries in wolfsdk/cvars.py under _TNC_GROUPS/"Renderer").
2. Apply in the loader — the existing with_tnc_tweaks() route appends the lines automatically to cfile:default.cfg (the same mechanism that, according to TODO.md, already brought God mode/infinite ammo into the game).
3. Start the game, and before the first click check qconsole.log (set logFile 1/logFilePersistent 1 beforehand if the log is missing — docs/ladepfade.md section "Kein Log ohne Zutun" ("no log without doing something") applies, according to its own text, to part 2 as well) for CANNOT be set or Unknown command on exactly these lines — either would contradict the gate model proven in §4.
4. Then just look: g_fov 120 should immediately show a visibly wider field of view (clearest single test, since CVAR_ARCHIVE + hard-clamped); r_dof 0 + r_motionblur 0 should be noticeable immediately in the next cutscene/when looking around quickly (no more blur/softening effect); r_decalFilteringQuality 4 is seen most clearly on a flat bullet hole from a steep viewing angle (sharp instead of washed out).
5. New this round, two concrete checks for the two open risks from §9: type r_decalFilteringQuality in the console (~) (without a value, it shows the current state). If it says 4 → our line has survived, initial_video_ultra.cfg does not overwrite the tweaks at every start. If it says 3 → the stock file wins, and the preset needs either a different delivery route or must drop the 5 lines marked [OVERLAP] from §8.1. The same for r_vignette (should show 0, not 1) — if it is back at 1, a cheat reset has wiped the cfile line, and the whole "needs cfile" part of both presets is affected, not just this one line.
6. If both checks from step 5 are green, the cfile route for render cvars is upgraded to PROVEN, and vt_minLockedVmtrLOD 0 can be checked on a fast camera turn for texture pop-in/blur (should occur much more rarely/not at all compared with the original state).

Sources

• re_probes/cvartable/cvars_tnc_v2.json, re_probes/agent_reports/cvartable.md (3256/304 cvar catalog, incl. session_value field, not redone, queried)
• tools/decomp.py 0x1238730 --callers, 0x1239140 --callers, 0x123932c, 0x123a320 --callers, 0x123a320 --xrefs, 0x1238530, 0x1238fa0 (clamp mechanism + cheat-reset investigation, this round and this pass)
• tools/tnc_runtime_code.py --xref 0x2f35050, --xref 0x123a320 (negative controls on per-cvar usage tracing, this round/this pass)
• wolfsdk/mod.py (with_tnc_tweaks, TNC_DEFAULT_CFG), wolfsdk/cvars.py (split_tnc, build_cfg, _tnc_exposed) — existing delivery mechanism, read not written
• mods/sandbox_tools/mod.json — the actual file (snapdemo.cfg/snapedit.cfg) the runtime-proven cfile test used, read this pass to fix the "same file" overstatement
• docs/ladepfade.md:240-289, re_probes/agent_reports/command_queue.md, re_probes/agent_reports/r4_consolecmds.md — resourceExec default.cfg -s at TNC startup and the generic restriction-level-0 proof
• docs/cvars-tnc.md, docs/cvars-tnc-vergleich.md, docs/virtualtextures.md, docs/ui-assets.md, docs/limits.md (TNO cheat-reset precedent) — cross-referenced, not re-derived
• re_probes/agent_reports/r6_enginelimits.md — sibling round report, cited this pass for its CVAR_CHEAT-reset hedge (missed in pass 1)
• re_probes/enginelimits/tno_strings.py (existing, unmodified) run against TNO's .rdata/.data this pass — §1b
• <Steam library>/.../Wolfenstein.II.The.New.Colossus/base/initial_video_{ultra,uber,meinleben}.cfg — read-only, this pass, §3.11/§9
• tools/ghidra_runtime_import_tno.py (docstring re-read this pass, confirms no TNO runtime image exists)
• TODO.md (2026-10-01 entry on the cfile tweak delivery mechanism)

Related: Research Report: R4 Console Commands, Research Report: R6 Engine Limits, Research Report: Cvartable, Research Report: Command Queue, Modding Limits, Asset Loading Paths, TNC CVar Catalog, TNO Virtual Textures, UI Assets, TNC CVar Validation, TNC CVar Catalog Rendering, TNC Console Unlock.