Developer Mode — What It Unlocks and Where the Retail Lock Remains

All information here originates from the unencrypted .rdata sections of both game executables. Tool: python tools/probe_devmode.py. Every entry includes a file offset and virtual address; --self-check verifies that these locations remain valid.

No findings in this document stem from an active game. Section 6 specifies for each hypothesis which startup command it tests and what would indicate the opposite.

Update 2026-10-04. Sections 1–9 are the original string-level analysis. Runtime results exist since then: the restriction level that gates commands and cvars (TNC Console Unlock) and the working developer menu (TNC Dev Menu). Sections 10–12 summarize them.

Evidence Grades

Four levels, consistently distinguished in this text:

Why not higher: The .text sections of both executables are SteamStub-encrypted (Section .bind, EntryPoint therein). There is no readable call site that links a name with the code that checks it. (Update: true for the files on disk only. Later work reads the decrypted code from a memory snapshot of the running game, re_probes/runtime_87400/module.bin; sections 10–12 rest on it.)

A methodological false lead, as it would have almost led to a negative finding: walk_strings from tools/mine_cvars_tnc.py filters via str.isprintable() and discards every string containing \n — including Resetting cheat cvar: %s\n, which exists in both executables. A negative finding from this filter is worthless. probe_devmode.py therefore uses its own pass that iterates through \n\t\r and checks this difference in the Self-Check.

1. The Summary

Two sentences, both at level Mechanism:

1. The New Order locks, The New Colossus asks. The message %s CANNOT be set in retail! exists in NewColossus_x64vk.exe not at all — not even the fragment in retail. At the exact point where Part 1 leads, Part 2 leads to Attempting to set a developer cvar '%s'.

2. Developer Mode is absent in Part 1. Neither devMode nor DevMode, DEVMODE, Dev Mode, or enableDeveloperMode appear anywhere in WolfNewOrder_x64.exe — zero hits out of eight search patterns, while the reverse check (developer mode, lowercase) yields four hits. The search works; there is nothing there.

Developer Mode does not lift the Retail lock. It has replaced it.

2. The Retail Lock in The New Order

Grade: Mechanism.

010503B0  VA 1410519B0  '%s can only be set on the command line\n'
010503D8  VA 1410519D8  '%s is read only\n'
010503EC  VA 1410519EC  'reset'
010503F8  VA 1410519F8  '%s CANNOT be set in retail!'     <---
01050418  VA 141051A18  "Archived CVar '%s' in production mode"
01050440  VA 141051A40  '"%s" is:"%s"^7 default:"%s"\n'
01050460  VA 141051A60  'Resetting cheat cvar: %s\n'
01050498  VA 141051A98  'toggles a cvar'

Three rejection reasons in succession — command-line requirement, read-only protection, Retail — then the archive message, then the Cheat Reset. This is idCVarSystemLocal, a single translation unit whose literals are laid down contiguously by the linker.

The CVar flags of Part 1, from the Reflection table in .rdata (there Name and numeric value are demonstrably linked together, unlike in the code):

014CC258  CVAR_BOOL       = 0x000001      014CC2D0  CVAR_INIT      = 0x004000
014CC270  CVAR_INTEGER    = 0x000002      014CC2E8  CVAR_ROM       = 0x008000
014CC288  CVAR_FLOAT      = 0x000004      014CC300  CVAR_ARCHIVE   = 0x010000
014CC2A0  CVAR_CHEAT      = 0x000008      014CC318  CVAR_MODIFIED  = 0x020000
014CC2B8  CVAR_NOCHEAT    = 0x000010      014CC330  CVAR_MODIFIED2 = 0x040000

There is no CVAR_DEVELOPER — in neither of the two Exes. Anyone searching for this flag is looking for something the engine does not know about. The lock from Part 1 runs via CVAR_CHEAT (0x8); this aligns with the measured log from docs/limits.md, where exactly those locked Cvars are also wiped by the cheat reset.

3. What stands in its place in The New Colossus

Grade: Mechanism. Same functional group, identifiable by identical neighbors:

0297B3E0  VA 14297C1E0  '%s can only be set on the command line\n'
0297B850  VA 14297C650  "Archived CVar '%s' in production mode"
0297B878  VA 14297C678  '"%s" is:"%s"^7 default:"%s"\n'
0297B898  VA 14297C698  '%s is read only\n'
0297B8B0  VA 14297C6B0  "Attempting to set a developer cvar '%s'."   <---
0297B8E0  VA 14297C6E0  'toggles a cvar'
0297B9C8  VA 14297C7C8  'Resetting cheat cvar: %s\n'

Line for line, the same repertoire. One line has been swapped out.

And it did not stop at one place. The same lock sits in both the command system and session management:

02981960  VA 142982760  "Attempting to call a developer command '%s'."
026E32E0  VA 1426E40E0  "Entering Developer Mode without it being enabled.\n
                          Set cvar '%s' to enable Dev Mode."

Three lock points — setting a Cvar, calling a command, entering the mode — and a common blueprint. The latter is open:

02981728  VA 142982528  'Enable entering developer mode'
02981748  VA 142982548  'devMode_enable'
02981758  VA 142982558  "%s\nSet cvar '%s' to enable Dev Mode."
02981780  VA 142982580  "Dev Mode is not enabled and action cannot be
                          completed. Set cvar '%s' to enable developer
                          options."
029817E8  VA 1429825E8  'FatalError rather than enter Dev Mode'
02981810  VA 142982610  'devMode_fatalErrorOnEnter'

"%s\nSet cvar '%s' to enable Dev Mode." takes two placeholders: the reason and the Cvar name. The two reasons are listed above. The Cvar name stands immediately next to them and is the only one in question: devMode_enable.

This is the answer to the guiding question. The Dev Mode does not lift the lock — the lock is the Dev Mode query. Part 1 says "does not go in Retail", Part 2 says "turn on devMode_enable".

The Flag Behind It

Grade: Indication, not Mechanism. (Update: section 11 reads the check in code.) What makes a Cvar a "developer cvar" is not proven. The comparison stands in the encrypted .text. What speaks in favor of it being CVAR_SHIPPINGDISABLED:

   The New Colossus                            The New Order
   ----------------------------------------    ----------------------
   CVAR_STRING            = 0x000000           (missing)
   CVAR_BOOL              = 0x000001           0x000001
   CVAR_INTEGER           = 0x000002           0x000002
   CVAR_FLOAT             = 0x000004           0x000004
   CVAR_CHEAT             = 0x000008           0x000008
   CVAR_NOCHEAT           = 0x000010           0x000010
   CVAR_TIME_MS           = 0x000020           (missing)
   CVAR_NETWORKSYNC       = 0x002000           (missing)
   CVAR_INIT              = 0x004000           0x004000
   CVAR_ROM               = 0x008000           0x008000
   CVAR_ARCHIVE           = 0x010000           0x010000
   CVAR_LOCAL_SETTING     = 0x020000           (missing)
   CVAR_MODIFIED          = 0x040000           0x020000
   CVAR_MODIFIED2         = 0x080000           0x040000
   CVAR_SHADERSYNC        = 0x100000           (missing)
   CVAR_EXPOSE            = 0x200000           (missing)
   CVAR_SHIPPINGDISABLED  = 0x400000           (missing)     <---

CVAR_SHIPPINGDISABLED is exactly new in the part where the Retail message disappeared. This is added to the correspondence in the command system, where the same lock message sits:

0247F7F8  CMD_NOCHEAT          = 0x2
0247F810  CMD_EXPOSE           = 0x4
0247F828  CMD_SHIPPINGDISABLED = 0x8

CMD_SHIPPINGDISABLED does not exist in Part 1 either. Two parallel flags, both new, both located where the new message appears — this is a good indicator but not proof. CVAR_CHEAT remains the second possibility; both systems coexist because Resetting cheat cvar: %s exists unchanged in Part 2.

4. What Developer Mode Costs

Grade: Mechanism. The game states it itself, at 0x026E3390 / VA 0x1426E4190:

You have enabled Developer Mode by using a developer tool.

Network gameplay and online services have been disabled. Save games (including SnapMaps) updated or created in Developer Mode will be permanently marked as "cheat", automatically re-triggering Developer Mode any time they are accessed.

To disable Developer Mode, restart the game without accessing any developer tools on the command line, configuration files, or console.

Three things stand out here that are documented nowhere else:

1. Network off. Confirmed by 0x02686F68 'Network features unavailable while using developer tools' and its neighbor idSessionLocalWin::InviteFriends.
2. Save games are permanently marked as "cheat" and subsequently trigger Developer Mode themselves. This closes the loop on the Save Game Agent's finding: 0x02686ED0 'Loading Dev Mode or corrupted save game.' and devMode_skipCorruptedSaves are the same thing from opposite sides. A save with a false .verify is not rejected, but loaded as a Developer Mode save — thereby pulling in the Developer Mode marking with it.
3. The trigger is explicitly triple: Command line, configuration files, and console. This is the sharpest difference from Part 1, where .cfg files were the only channel the ban did not penetrate (docs/limits.md, Section 2).

The counterpart to activation: 0x026E3338 'Entering Developer Mode' and 0x026E3548 'NotifyCheating' lie immediately adjacent, thus in the same function.

5. Names and Their Descriptions

5.1 The three devMode_* Cvars

Grade: Cvar. Names are hard-coded; descriptions rely on neighborhood, not call site — but each stands immediately before its name and matches in wording.

devMode_fatalErrorOnEnter warrants a warning: The description text states that the game intentionally crashes upon entering Dev Mode rather than entering it. This is a developer tool to find accidental activation — nothing one would want to enable.

None of the three appear in docs/cvars_tnc.json. This is not a contradiction, but a gap in the Miner's work: tools/mine_cvars_tnc.py filters via a fixed prefix list, and devMode_ does not belong there (devgui as a prefixless name equally so). Anyone reading the catalog as complete will miss exactly this group.

devMode_skipCorruptedSaves is the most interesting of the three: If it stands at 1, a corrupted save game does not trigger Developer Mode. For modding purposes, the value 0 (presumably the default) is more useful — then every save with a false .verify becomes a Developer Mode key.

5.2 The Command Line Environment

Grade: String. Two entries lie in a storage area with arguments that the engine evaluates early itself:

026C1268 '+s_noSound' 026C12F0 '+net_' 026C1278 '+menu_enableInitialAgreements' 026C1310 '+fs_basepath' 026C1298 '+telemetry_' 026C1320 '+set' 026C12A8 '+r_fullscreen' 026C1328 '+fs_savepath' 026C12B8 '+devMode_' <--- 026C1338 '+net_versionchecksum' 026C12C8 '+com_enableDeveloperMode' <---

+devMode_ is a prefix (covers all three Cvars), +com_enableDeveloperMode an exact name. The fact that +set and +fs_basepath appear in the same list indicates: These are arguments with special handling before normal Cvar processing. Whether this involves pre-evaluation, passing via a restart (' +com_restarted 1' is located 200 bytes further), or an allowlist — this information resides in the encrypted .text section. Not substantiated.

com_enableDeveloperMode itself has no description next to it, unlike practically every other com_ Cvar. Its neighbors are set, fs_basepath, devMode_ — components of the command-line parser, not a Cvar registration. Whether it is actually a registered Cvar or merely an argument recognized by the parser remains open.

5.3 The State: devMode_t

Grade: Mechanism (Value and Name from Reflection Table):

DEVMODE_PRODUCTION = 0
DEVMODE_DEVELOPER  = 1

An enumeration type devMode_t (0x02717608, RTTI .?AW4devMode_t@@ at 0x0303A838) with two states. No intermediate state, no levels.

5.4 The DevGUI

Grade: Cvar. devgui has six modes in Part 2 instead of three:

0 = disable DevGUI, 1 = enable DevGUI, 2 = enable DevGUI with key legend, 3 = ImGUI only, 4 = ImGUI with custom windows, 5 = custom ImGUI windows only — 0x0294F6C0

In Part 1, the same description ends at 2 (0x01038310). Part 2 therefore includes a complete ImGui interface. The pages are named in the Exe: VirtualTexturing, UmbraDebug, LightDebug, RenderingStats, Render_Reload, RenderModes, Set_Team, Weapon_Offsets, AI_NavDebug, Spawn_AI, Time_Scale (0x0294F5F8–0x0294F6A0).

Incidental finding: com_allowConsole does not exist in Part 2. In Part 1 it exists (0x00E67C18), but a later code reading shows it does not gate the console: the console opens with Ctrl+^ and the cvar only feeds an achievement check (code only, see Modding-Limits §2). In Part 2 there is no such Cvar, which fits with the screenshot showing the input line ].

6. com_production and Production Toggles

Grade: Cvar. All four exist, three with descriptions:

Two of them exist only in Part 2.

com_production is the master toggle, and its own description states that. "All demo and retail builds are built with this on" — that is the Retail property encapsulated in a single Cvar. The name fits DEVMODE_PRODUCTION = 0: production is the opposite of developer.

However, be careful; this is the most likely way to waste time here: com_production controls far more than cheat unlocks. In the same executable, attached to it are the resource loader ("couldn't read production file for decl", 'Resource loaded in production mode: %s : %s'), the entity loader ('if set use .entities files instead of .map files for production'), the sound bank loader, and virtual textures (vt_productionFilePath). A retail game with com_production 0 searches for files that do not exist in a retail installation. If com_production is actually settable at runtime, the expected outcome is a crash on the next resource access — exactly the pattern from docs/limits.md, Section 3.

com_gameMode is the more restrained switch of the same family. The values are documented:

GAMEMODE_ALL = 0   GAMEMODE_MP   = 2   GAMEMODE_SHELL = 4
GAMEMODE_SP  = 1   GAMEMODE_SNAP = 3   GAMEMODE_MOD   = 5

GAMEMODE_MOD = 5 deserves its own attention. A mode named MOD, which according to the description determines "asset load pattern and runtime behaviour", is immediately relevant for a modloader project — regardless of dev mode. The engine also carries ' +com_gameMode ' (with spaces, 026C14C0) and '+com_gameMode' (026C16C0), so the value is appended to a command line as well as read from one. What Mode 5 specifically changes — custom load path, custom .resources, relaxed checks — is not documented.

7. Experimental Arrangements

Everything below here is untested. For each experiment, it states what confirms and what refutes it. The log is located under %USERPROFILE%\Saved Games\MachineGames\Wolfenstein II The New Colossus\base\qconsole.log and logs every rejected assignment.

Above all: checkpoint.dat, profile.bin, and progression.bin must be backed up. The warning text explicitly states that touched save games will be permanently marked as "cheat". This is not a side-effect risk, but announced behavior.

V1 — What is the switch: com_enableDeveloperMode or devMode_enable?

NewColossus_x64vk.exe +com_enableDeveloperMode 1
NewColossus_x64vk.exe +devMode_enable 1
NewColossus_x64vk.exe +com_enableDeveloperMode 1 +devMode_enable 1

Confirmed by the warning text from Section 4 as a dialog box, or by Entering Developer Mode in the log. The third variant shows whether both are needed. Refuted by Dev Mode is not enabled and action cannot be completed on the first dev action — then the set cvar is not the one being queried. From the screenshot it is known that Variant 1 opens the console; open is whether the cvar lock also falls with it.

V2 — Does the lock really fall? (the guiding question)

Start beforehand without dev mode, enter g_infiniteAmmo 1 in the console, and note the message. Then do the same with dev mode.

Confirmed, if without dev mode Attempting to set a developer cvar 'g_infiniteAmmo'. appears and with dev mode no word — and g_infiniteAmmo afterwards returns 1. Refuted, if the message appears in both cases or is absent in both. In the first case devMode_enable is not what the query reads; in the second g_infiniteAmmo is not led as a developer cvar at all and the attempt needs another candidate. Checked from docs/cvars_tnc.json for existing and suitable: g_EnableGore, g_debugGore, ai_damageScale, g_freeCamSpeed, pm_noclipspeed. (The Part-1 names from docs/limits.md do not serve as candidates — g_showThinks, ai_invulnerable, g_gameDifficulty, com_showFPS, and g_permaGodMode exist in Part 2 all not.)

This is the one experiment that matters. It is cheap, it needs no save game, and it answers the question in two starts.

(Update: answered, see section 10.)

V3 — Does the lock only warn or reject?

Same structure as V2, but without Dev Mode: set g_infiniteAmmo 1 and then query g_infiniteAmmo without arguments.

Confirms if the value remains 0 — in that case, Part 2 behaves like Part 1 and the text is merely more polite. Warns only if the value becomes 1. Then the lock in the CVar system would be toothless, and the real hurdle would lie deeper, during the evaluation of the value. This outcome would explain why the text reads "Attempting to …" instead of "Cannot …".

V4 — Is a configuration file sufficient?

The warning text mentions "command line, configuration files, or console". In Part 1, the .cfg was one channel that the lock reliably blocked.

In Part 2 there is no autoexec.cfg — the name does not appear in the Exe. The executable file on disk is binary.cfg in the game folder (exec "%s/binary.cfg" -s, 0x026E31B0; it is demonstrably searched according to docs/ladepfade.md):

echo devMode_enable 1 > D:\...\Wolfenstein.II.The.New.Colossus\binary.cfg
NewColossus_x64vk.exe

Confirmed by the Dev Mode dialog without any command-line arguments. Refuted by silence in the Log. First, verify that the file is actually executed — write a harmless line like g_showHud 0 and check if the HUD disappears. Otherwise, you are blaming Dev Mode for a file that no one reads.

V5 — Is a corrupted save game a Dev Mode key?

Take a copy of a save game, change one byte in checkpoint.dat, leave the associated .verify unchanged, and load it.

Confirmed by "Loading Dev Mode or corrupted save game." in the Log plus the Dev Mode dialog. Then the .verify is not a loading barrier but a Dev Mode trigger — and an entry into Dev Mode that does not require command-line arguments. Refuted by rejection of the save game. Control test: Restart subsequently with +devMode_skipCorruptedSaves 1 and load the same save game. If Dev Mode does not appear, then the CVar→Behavior mapping from Section 5.1 is confirmed.

Make this attempt last. It is the only one that permanently marks a save game.

V6 — com_gameMode 5 (MOD)

NewColossus_x64vk.exe +com_gameMode 5

Confirmed by a different load path in the Log — different .resources, different Decl root, a different start menu. Refuted by an unchanged start, or by read only / can only be set on the command line. A crash during loading is the third likely outcome and also a result: it shows that Mode 5 expects files that a Retail installation does not have.

Value 3 (SNAP) and 4 (SHELL) are cheap comparison runs and show whether the CVar has any effect at all.

V7 — com_production 0

The riskiest attempt, and the one with the lowest chance of success. See Section 6: com_production controls resource, entity, sound, and text loaders. Only use this with secured save games and only if V2 through V6 yield nothing.

Confirmed by a start that reaches the menu at all. Refuted — and expected — by couldn't read production file for decl followed by a crash at an unrelated location. This pattern is known from docs/limits.md Section 3: a single read error disables the entire resource loader, and the visible crash occurs much later.

8. What remains open

• Which flag triggers Attempting to set a developer cvar. (Update: answered statically for the console set path, see section 11.) CVAR_SHIPPINGDISABLED (0x400000) is the best indicator; CVAR_CHEAT (0x8) is the alternative. Decidable only via V2 with multiple candidate Cvars.
• Whether the ban is rejected or merely warned — V3.
• What +devMode_ and +com_enableDeveloperMode do in their list. The proximity to +set, +fs_basepath, and ' +com_restarted 1' suggests a pre-evaluation or passing via restart. Not substantiated.
• Whether com_enableDeveloperMode is actually a registered Cvar. It is the only com_ name without a description in its environment.
• Which Cvars and commands qualify as "developer". The catalog in docs/cvars_tnc.json lists 2231 names without flags — the flags are located in the encrypted .text. The only way to reach them is to try them out in-game and evaluate the log, exactly as described in docs/limits.md for Part 1.
• What GAMEMODE_MOD changes.

9. Tool

python tools/probe_devmode.py              # full report with addresses
python tools/probe_devmode.py --self-check # only the invariants

The Self-Check verifies: the four anchor points at their address, the absence of in retail in Part 2 and devMode in Part 1, that the search actually yields results (otherwise every negative finding would be worthless), the isprintable trap of walk_strings, and the flag and enum values this document relies on.

10. Update: The Restriction Level Is the Lock That Matters in The New Colossus

Added 2026-10-04. Grades in sections 10–12: In Game = confirmed in game; Inferred = code reading of the memory snapshot, not watched at runtime.

• Inferred. One global integer, the restriction level (RVA 0x41244d8), picks the list the dispatcher searches. Level 0: all 234 commands and every cvar. Level 1: the 34 exposed commands and 304 exposed cvars. It rests at 0; console key input, +args, exec and key binds raise it to 1 for their own lines.
• In Game. +args and console lines for non-exposed names get Unknown command.
• In Game. A loader-replaced cfile run with resourceExec <cfile> -s runs at level 0: God and Notarget printed ON, and g_infiniteAmmo 1 kept the ammo.
• In Game. Developer menu lines run at level 0: devmap loaded a map.

Details: TNC Console Unlock, TNC Dev Menu.

Keywords: developer mode, restriction level, retail lock, Unknown command, unlock console, devMode_enable, Entwicklermodus, Sperre

11. Update: What Triggers "Attempting to set a developer cvar"

Inferred (code reading, report r8). A console line that sets a cvar goes through idCVarSystemLocal (vtable +0x88, RVA 0x1239f20) to idCVar::Set (RVA 0x1239140). Its tests, in order:

1. INIT flag → can only be set on the command line;
2. ROM flag → is read only;
3. restriction level not 0 and no NOCHEAT bit (0x10) → Attempting to set a developer cvar.

The function has no CHEAT (0x8) test. So on this path "developer cvar" means: a cvar without NOCHEAT, set from a restricted context. At level 0 (a resourceExec ... -s file, a dev menu line) the same set goes through. This answers the first open question of section 8 for the console set path, statically only.

Keywords: Attempting to set a developer cvar, developer cvar, NOCHEAT, CVAR_CHEAT, idCVar::Set, cvar flags, Cvar gesperrt

12. Update: The Developer Menu of The New Colossus Loads Maps Again

The New Colossus has its own developer menu, built from devMenuOption decls; it is not the debugmenu.txt route of The New Order. Its map entries did nothing in retail: they queue loadDevMenuOption, a command the retail build never registers.

• In Game (2026-10-02). The mod Dev Menu Map Loading rewrites each map entry into command lines ending in devmap <map>. The menu runs them at level 0, and the map loads.
• Not yet confirmed in game. 126 restored dev starts, and the Hidden Menu Options mod, which sets menu_showOptionForDevMenu so the main menu offers the entry.

Everything else, with addresses: TNC Dev Menu.

Keywords: developer menu, dev menu, devmap, loadDevMenuOption, devMenuOption, Dev-Menü, Entwicklermenü, Karten laden