Limits — what works, what doesn't, and why

Section 0 lists the limits of the WolfSDK apps (0.3.0) that players and modders run into. From section 1 on, everything is measured, not guessed. The evidence comes from the game log (%USERPROFILE%\Saved Games\MachineGames\Wolfenstein The New Order\base\qconsole.log), which the engine writes on every start. It logs the complete command line, every rejected Cvar, and every error — the most useful tool for modding this game.

Keywords: limits, limitations, what does not work, known issues, Grenzen, Einschränkungen, was geht nicht

0. WolfSDK 0.3.0: Limits for Players and Modders

These limits come from the 0.3.0 release (README and release notes). Short answers to the same topics: FAQ (Deutsch).

Keywords: WolfSDK 0.3.0 limits, WolfSDK 0.2.0 limits, release limits, known limits, user limits, Grenzen 0.3.0

Steam Versions Only

WolfSDK supports the Steam versions of both games on Windows. The Microsoft Store / Xbox Game Pass version locks the game files, so the loader cannot write mods there. GOG and Epic are untested. The loader finds the games through Steam and starts them through Steam (steam://rungameid/...); starting the EXE directly does nothing, because the SteamStub wrapper hands the start back to Steam and exits.

Keywords: Steam only, Steam version, Microsoft Store, GOG, Epic, Windows only, SteamStub, nur Steam

Custom Maps Need The Freedom Chronicles, Episode 2

A custom map for The New Colossus takes the place of the map c2v1 and is loaded in the game through The Freedom Chronicles, episode 2, so it needs that DLC episode. The loader installs a finished map file with Install map… (Confirmed in game) but cannot build one. Ways to load a map without the DLC exist only as research (Research-Report-R3-Mapselfcontained). The WolfSDK: Mod test map entry of the developer menu needs the test map installed in dlc\dlc_0; the map file is not in the public packages.

Keywords: custom map, Freedom Chronicles, episode 2, c2v1, dlc_0, Install map, mod test map, eigene Karte

Sound and Video Replacement (New in 0.3.0, Not Yet Tried in Game)

In 0.2.0 the Studio refused to replace sounds and videos, because Revert did not restore replaced sound packs and video files. Since 0.3.0 Revert restores them and the Studio replaces PCM sounds (Wwise sound packs) and Bink 2 videos for The New Colossus. Not yet confirmed in game. For The New Order, sounds are Ogg streams outside the archives the loader writes and there is no Vorbis encoder, and its videos are loose Bink files the loader does not write for that game.

Keywords: replace sounds, replace videos, audio mod, Wwise, Bink, Revert, held back in 0.2.0, Sounds ersetzen

Tested on One PC So Far

WolfSDK has been tested on one PC only. Confirmed in game: applying and reverting mods with backups, installing a custom map, Sandbox Tools god mode and infinite ammo, the developer menu running devmap, and the mod test map loading. Most shipped mods are only checked structurally; unless a mod's description says otherwise, treat it as untested in game. The full list of what is Not yet confirmed in game is in the FAQ. Reports from other PCs help: Discord via https://lopekinz.github.io/wolfenstein-modloader/#community.

Keywords: tested on one PC, untested, beta, not confirmed, structurally checked, getestet, ungetestet

Four Mods Are Not in the Public Package

Four mods carry whole modified retail files instead of patches, so they are left out of the public packages:

• More Realistic Gore Textures (gore_texturen): modified retail textures.
• Supersoldiers Instead of Fire Soldiers (supersoldaten_c15): a whole retail map entities file.
• Golden Pistol (tnc_skin_gold_pistol): modified retail textures.
• Menu Branding (menue_marke): the whole retail English string table.

They come back once they are built as patches instead of whole files. Also left out: test probes and a personal skin. Golden Pistol (Simple), which uses material decls only, is in the package.

Keywords: missing mods, excluded mods, not in package, gore textures, golden pistol, menu branding, supersoldiers, fehlende Mods

More Limits for Players

• The New Colossus gets no default F-key binds: a bound key runs at the restricted console level. Use the Sandbox Tools mod (FAQ).
• The German, censored version has different textures; skins probably do not apply there (unverified).
• Close the game before applying or reverting; after a game update, Revert first.
• The backups need about 1 GB free on the game's drive, up to about 3 GB with The New Order.
• Back up %USERPROFILE%\Saved Games\MachineGames once; not every mod has been checked with old saves.
• Do not tick two skins for the same weapon.

Keywords: F-key binds, German version, close the game, game update, disk space, save games, two skins

1. The Retail Lock

The engine rejects certain Cvars:

WARNING: com_allowConsole CANNOT be set in retail!

Measured via a probe run with the full catalog (26 names, all of them cheat cvars). Locked include, among others:

ai_damageScale        ai_invulnerable       com_allowConsole    com_skipIntroVideo
devgui                g_AimAssist_Disable_All   g_EnableGore    g_debugGore
g_freeCamSpeed        g_gameDifficulty      g_goreBloodyMess    g_gravity
g_infiniteAmmo        g_playerHealthRegenDelay  g_playerHealthRegenSpeed
g_showThinks          g_useSavegameDifficulty   pm_autoSprint   pm_crouchspeed
pm_jumpheight         pm_noBob              pm_noclipspeed      pm_runspeed
pm_sprintMaxTime      pm_sprintspeed        pm_walkspeed

Keywords: retail lock, CANNOT be set in retail, locked cvars, cheat cvars, The New Order

Cvars Not Affected by the Lock

Not locked and thus fully usable:

g_permaGodMode   g_permaInfiniteAmmo   g_damageScale   g_fov
com_showFPS      g_showHud             g_bloodEffects  pm_togglesprint
r_swapInterval

Notable: g_infiniteAmmo is locked, while g_permaInfiniteAmmo is not.

Keywords: unlocked cvars, g_permaGodMode, g_permaInfiniteAmmo, g_fov, usable cvars

Why These Names Are Locked (Read from the Code)

Why these names (read from the code, not measured in game). Cheat is the default cvar flag: a cvar registered without NOCHEAT, INIT, ROM or ARCHIVE is a cheat cvar. The engine registers 3,194 cvars in The New Order, 2,865 of them cheat and 329 non-cheat (8 read-only, 38 init-only, 169 archived). All 26 measured-blocked names are cheat cvars and all 9 measured-accepted names are non-cheat, so code and measurement agree. Archived cvars (g_permaGodMode, g_fov, g_showHud, ...) are not cheat cvars, which is why wolfConfig.cfg can carry them. The list above is only the measured part; every cvar with its default, range and flag is in the catalogue: TNO-CVar-Catalog (Gameplay, Rendering, Other). For The New Colossus see TNC-CVar-Catalog.

Keywords: cheat flag, NOCHEAT, ARCHIVE, cvar flags, 2865 cheat cvars, wolfConfig.cfg

Measuring the Lock Yourself

The current status can be measured at any time — write the catalog as a Config, start, and search the log for CANNOT be set in retail.

The tool for this does not exist in the repository. The list above comes from a manually driven probe run; none of the tools/probe_*.py scripts generate it — probe_cvars.py, probe_cheatvars.py, and probe_retail_lock.py all read only the EXE. "Measured" here means measured once, but not reproducible on demand. The reference to tools/probe_retail_cvars.py in wolfsdk/cvars.py:30 points to nothing.

Keywords: measure, qconsole.log, probe run, reproducible, retail lock test

Two different Nays — Config Lock and Cheat Reset

The warning above is the response to a Config line. From the command line, the same rejection looks different, and this is readable in the log. The run from 21.09.2026, 18:47 (qconsole.log, 4,858 lines) produced with

+com_skipIntroVideo 1 +pm_autoSprint 1 +com_allowConsole 1 +g_showHud 1
+g_EnableGore 1 +g_bloodEffects 1 +g_goreBloodyMess 1

not a single line CANNOT be set in retail, but rather:

325: Resetting cheat cvar: pm_autoSprint
326: Resetting cheat cvar: g_goreBloodyMess
327: Resetting cheat cvar: com_allowConsole
328: Resetting cheat cvar: com_skipIntroVideo

Keywords: cheat reset, Resetting cheat cvar, command line, config lock, qconsole.log

Same Result, Different Path

This is the mechanism from Section 2, not from Section 1: The assignment arrives, but the Cheat Reset wipes it out. Practically, the result is the same — the Cvar stands at its default value again on game start. Formally, it is a different path, and whoever searches the command line for CANNOT be set to check if a Cvar gets through is looking at the wrong line.

Keywords: cheat reset, default value, CANNOT be set, startup arguments, different path

Incidental Finding: g_EnableGore Survives the Reset

Incidental finding of the same lines: g_EnableGore was also on the command line, stands in the lock list above — and does not appear under "Resetting cheat cvar". From the command line it survives the reset, unlike g_goreBloodyMess two lines down. Whether it works with that is not stated by the log. Unverified. (g_showHud and g_bloodEffects were also present and are anyway not locked.)

Keywords: g_EnableGore, gore cvar, cheat reset, unverified

2. Why the Lock Cannot Be Bypassed from Config Files

Five channels were tested (measured):

Two mechanisms interact with each other:

1. The lock only allows assignments from the command line. Configuration files are rejected.
2. A single cheat reset at startup wipes all CVAR_CHEAT cvars: 326: Resetting cheat cvar: devgui It runs after the command line and before everything else.

The combination is tight: what comes early enough to bypass the lock gets caught by the reset; what comes late enough to survive the reset no longer counts as a command line input.

Keywords: bypass lock, config files, binary.cfg, default.cfg, +set, +exec, +toggle, channels

How +toggle Breaks the Logic

+toggle actually breaks this logic — toggle is a command and runs late, but it originates from the command line:

494: devgui = 1.000000      (no lock warning)

Measured: with devgui = 1 set this way, nothing happened on F8 and F10, and the console did not open when ~ was pressed. The first reading, "the functionality is not hooked in the retail build", is too strong. A later static pass (nothing run in game) found the points in the next two subsections. Everything there is read from the code only.

Keywords: +toggle, devgui, toggle command, F10, console did not open

The New Order Console and Cheat Cvars (Read from the Code)

• The console opens with Ctrl+^ (the key left of 1, with Ctrl held). A plain ^/~ does nothing, which looks exactly like "console disabled". com_allowConsole does not open it: nothing in the console code reads it, and its only reader feeds an achievement check. Nobody has pressed Ctrl+^ in The New Order yet.
• Only one setter path is gated: a bare name value (typed in the console or in a .cfg line) is refused with CANNOT be set in retail!. The commands toggle, cvarAdd, cvarRandom, addWrap, addClamp and cvarMultiply, and the DoomScript native sys.setcvar, force-set the value, so toggle name v v (always ends at v) works on a cheat cvar. On the command line, +name value is accepted and then wiped by the cheat reset, while startup commands such as +toggle run after it. Only the form without values (+toggle devgui) is measured; +toggle name v v is code-only.

Keywords: Ctrl+^, open console, com_allowConsole, toggle name v v, force set, cvarAdd, setter path

DevGUI, F10 and Missing Commands (Read from the Code)

• The stock F10 bind cannot work: it is bind "F10" "devgui 1", a bare assignment to a cheat cvar. bind F10 "toggle devgui 0 1" takes the force path.
• The DevGUI only stays on inside a level. At the main menu the game resets devgui to 0 itself, which fits the measurement above (taken at the menu). Whether it stays at 1 inside a level is not measured.
• god, noclip, notarget, give and spawn do not exist in The New Order, neither as commands nor as cvars; they print "Unknown command". devgui is a cvar. Substitutes: toggle g_permaGodMode 0 1 (an archived, non-cheat cvar) and the cheat cvar g_freeCam.
• debugmenu.txt (the loader's menu page) has no consumer in the executable that could be found, so even an open DevGUI would very probably not show it. This is an absence of strings, not proof.

Keywords: DevGUI, F10 bind, god, noclip, give, spawn, g_freeCam, debugmenu.txt

And an EXE patch?

Not in the Steam version. The EntryPoint lies in a section named .bind — the SteamStub wrapper. The real .text is encrypted on disk, evidenced by the fact that not a single string has a reference, not even "Command line is: ", which is guaranteed to be used. Removing the wrapper would be copyright removal, not modding.

The GOG version is DRM-free. There, a patch would be normal modding on its own file. Whether it leads to the target is open: The DevGUI strings ("DevGUI Key Legend:", ">Trying to Init DevGUI when its already Init!") are embedded in the binary, so the code is presumably present — but behind the cvar sits at least one more hurdle.

Keywords: EXE patch, SteamStub, .bind section, encrypted text, GOG DRM-free, binary patch

3. The Compression Format — the most important detail

Payloads are raw DEFLATE without a finish. Of the 15,069 entries in chunk0, 14,035 end on 00 00 ff ff, the Z_SYNC_FLUSH signature: The BFINAL bit is not set. The engine knows the usize for every entry and inflates exactly that many bytes — it never expects a stream end.

If one instead writes a stream closed with Z_FINISH (i.e., zlib.compressobj(...).flush() in Python), the following occurs:

380: Load 11168 resources using 14023 of 15069 total resource files
381: WARNING: zlib inflate error
382: WARNING: couldn't read production file for decl 'generated/decls/renderProg/...'
... and from here on, every further resource access fails

A single inflate error disables the entire resource reader. The visible crash occurs afterwards at a completely unrelated location — in this specific case with the Combatknife model, which was never touched.

Keywords: compression, raw DEFLATE, Z_SYNC_FLUSH, zlib inflate error, crash, chunk0

The One-Line Fix

The fix is one line:

packed = co.compress(data) + co.flush(zlib.Z_SYNC_FLUSH)   # not co.flush()

Tricky about it: Python's zlib.decompressobj reads both formats silently. All byte tests were green, while the output format was wrong. tools/verify_patch.py now explicitly checks that every stream ends on the sync marker.

Keywords: zlib fix, Z_SYNC_FLUSH, compressobj, sync marker, verify_patch

4. The Archive Invariant

Payloads lie in .resources sequentially on 16-byte boundaries, with strictly ascending offsets (verified: 15,069 of 15,069 entries in chunk0). The engine validates this:

FATAL ERROR: idBackgroundLoader::BeginBackgroundLoads: FileTable is out of order

An earlier version of the patcher appended new data to the file end and redirected the index there. This passed every byte test — round-trip byte-identical, revert sha256-identical — and still caused the game to crash at startup.

Keywords: archive invariant, FileTable is out of order, offsets, 16-byte boundaries, crash at startup

Writing into the Existing Slot

Therefore, the Patcher writes today into the existing Slot: Offsets never move. The budget is exactly csize — not csize plus alignment padding. Although up to 15 bytes of padding may exist between two payloads, Archive.write_in_place() does not touch them: a shorter stream would shrink csize, and the Loader would then incorrectly address later entries — symptom No address, error: 487. Shorter streams are therefore padded back to csize and the length field remains intact. Whoever calculates the space for an edited Decl computes csize − own Deflate and no additional bytes (example figures in TNO-Modding-Surface.md §4.1). If a replacement does not fit, the affected Archive is completely rewritten — expensive, but orderly.

Lesson learned: Byte-exact round-tripping is not the same as a valid Archive. tools/verify_patch.py checks the order since then.

Keywords: slot write, csize, padding, No address error 487, archive rebuild, write_in_place

And In Game?

And in-game? Measured as of 21.09.2026: An apply with 373 Assets, which all 14 .resources files rewrote, started 15 seconds later and ran for approximately 48 minutes until Chapter 12. The qconsole.log from this session contains 0 lines of ERROR, 0 zlib inflate error, 0 FileTable is out of order, and 0 No address. Thus, the Order Invariant holds not only in the verification tool but also in the Loader. This answers the question "does the Engine load the patched Archives without complaint?" — though what the changes do remains unverified.

Keywords: in game test, 48 minutes, 373 assets, patched archives load, no errors

5. What Cannot Be Modded

New 3D Geometry. md6Def is text, but multimesh.base points to .md6mesh — binary, not examined. A "new weapon" here means: new Decl, existing Meshes, own values, Tags, and Skins.

New Surface Textures for Weapons and Characters. Their pixels lie in the Megatexture (virtualtextures/*.pages, 39 files, 35.6 GB / 33.2 GiB, measured as of 21.09.2026), not as an image Asset — for models/weapons/Handgun/Handgun there is demonstrably no image. Materials with usevirtualmapping 1 derive their data from there. Skins therefore function via bending onto existing materials, not via new image data.

Keywords: cannot be modded, new geometry, md6mesh, megatexture, new textures, skins, The New Order

HUD and UI Textures

HUD and UI Textures exist instead as image (2,566 pieces). Header Readers, Decoders (BIM → PNG), and Encoders (PNG → BIM) are present — wolfsdk/image.py, exported as wolfsdk image-export and wolfsdk image-import. Two limitations remain:

• The Encoder writes exclusively Format Code 3 (RGBA8) and requires the replaced image as a template, because multiple header fields are not decrypted. There is no BC1/BC3 compressor — thus a replacement is usually larger than the original and forces an Archive rebuild.
• Whether a replaced image looks correct in-game is not verified. It is only documented that the Engine loaded four self-built BIMs (Mod wolfsdk.gore_texturen, not in the public packages) without writing an error line — see Section 4. Looking at the screen does not confirm this.

Keywords: HUD textures, UI textures, BIM, image-export, image-import, RGBA8, encoder

Movement Speed, Gravity, Jump Height

Movement Speed, Gravity, Jump Height. As a cheat CVar locked from config files and from +name value (the console route above is code-only and untested), and no Decl equivalent can be found — a full-text search across all 60,210 text Assets for runSpeed|sprintSpeed|walkSpeed|jumpHeight|gravity yields nothing for the player.

Keywords: movement speed, run speed, gravity, jump height, pm_runspeed, g_gravity

6. What Happens Instead with Decls

The lock applies only to Cvars. Everything the Engine reads from Decls remains untouched:

Details in the Modding Guide.

Keywords: decls instead of cvars, weapon damage, fire rate, gore, enemy health, weapon skin

7. Open Issues

• Savegame Compatibility with Player Decl Changes. A run with modified player/game/wolf/chapter_start_default ended in Failed to load md6 model 'combatknife.md6mesh'. Cause unconfirmed; suspected interaction with an existing save state. Anyone working on the player decl should test with a new game.
• BIM Encoder in Game. The encoder exists (Section 5), but only for RGBA8, and no one has checked whether a replaced HUD image renders correctly.
• .md6mesh is not examined.
• Virtual Texture Pixel. The .pages container is decrypted and verified (TNO-Virtual-Textures.md), but the pixel data is not — a cropped JPEG-XR stream, TNO-Virtual-Textures.md §8. Swapping pixels therefore still does not work.
• Console and cheat cvars in game. Ctrl+^ and toggle <cheatcvar> 0 1 (Section 2) are code-proven but have never been run in The New Order.

Keywords: open issues, savegame compatibility, player decl, md6mesh, virtual texture pixels, open questions