Runtime Modding — what can change while the game runs

Research from 2026-10-10/11 on changing game content without restarting the game, for The New Colossus (TNC), The New Order (TNO) and Youngblood (YB). Everything here comes from the decompiled retail executables (RVAs as in the project's Ghidra exports) and from static reads of the retail archives. Labels: proven = read in code or data; inferred = follows from proven facts; open = needs a game test. None of the hot-patch routes below has run in game yet.

Keywords: hot patch, hot reload, runtime, live, without restart, ohne Neustart, Laufzeit, archive lock, reloadDecls, script console command

1. Which game is easiest to change at runtime?

2. TNC: why the loader cannot apply while the game runs, and what a hot patch would need

• How archives are opened (proven): one opener (RVA 0x12418b0) uses GENERIC_READ with share mode READ|WRITE and no memory mapping. Containers are registered with keepOpen=1 (gameresources, patch_N at init; map chunks on map load) and keep their handles for the whole session.
• What fails: writing in place into an open archive is allowed by that share mode. Replacing a file (os.replace after a rebuild) needs DELETE sharing, which the game does not grant — this is the "cannot be replaced right now" error.
• When data is re-read: the entry table of a container is read once when it is opened (RVA 0xacb780). Base archives are never reopened, so a rebuilt base archive is useless to a running game. Map chunk containers re-read their table on the next load of a different map (inferred).
• Reload commands exist but do not help: reloadDecls, reloadEntity, reloadLanguage, reloadMD6Models, s_reload, vt_reload are registered (non-exposed). None re-reads archive bytes; they walk resident objects or compare loose-file timestamps, which are constant in production. There is no mount, DLC-rescan or container-reload command.
• Patching the exe is not the route: .text is SteamStub-encrypted, a Steam update or file verification restores the exe, and even with DELETE sharing the game would keep reading the old file through its handle.
• Best candidate route (open): write changed entries in place, in their existing slot, while the game runs, then load a different map. Most likely to work for map content (.entities, map scripts, per-map containers); open for decls in the base archives; risky for .bswf UI files (an on-demand load may be fatal in production state). A safe in-place probe with byte-exact restore exists in the project and waits for a game test.

3. TNC: shop items that work live (no restart)

• Decl edits (magazine size, max health, regeneration) are restart-only: decls are resident and never re-read.
• Kiscule Command node lines run at restriction level 0 (proven in game for cvarAdd, echo, conDump, nextmap), so cvars with live readers work right away:
  • g_damageScale is read on every hit (RVA 0xf945f0) → armor tiers as cvarMultiply g_damageScale 0.9
  • pm_runspeed, pm_jumpheight, timescale, g_infiniteAmmo, g_infiniteThrowItems have real gameplay readers
  • healDebugEntity (RVA 0xf45c20) falls back to the player when no debug entity is selected → full heal (inferred)
• give, god (lowercase), noclip and spawn are not registered in the retail build.
• ActionGiveItems gives weapons; for a held non-weapon item it is a silent no-op (RVA 0x97efe0). Items such as upgrade kits can be handed over through a carrier inventory item with giveItemsOnRecieveWithCount.
• Placed AI in a map .entities file keep their own aiHealth block: an entityDef edit does not reach them, because .entities blocks take only their own edit text (RVA 0xa355d0). Health changes for placed or cloned AI have to be written into the entity blocks.
• g_playerHealthRegenSpeed, g_playerShieldRegenDelay and g_playerShieldRegenRate have no reader in the TNC exe (inferred) — setting them has no effect.

4. TNO: building blocks for scripted game modes

• Map transitions from scripts (proven): $player1.nextMap(map, spot, layersOn, layersOff) (native 0x9241a0) sends nextmap 0 "<map>" "<spot>" ...; $player1.devMap(...) (0x924350) does the same with devmap. The console nextmap handler (0x14a120) describes itself as "transitions to the next map, maintaining inventory". idTarget_NextMap frees the inventory on a chapter change.
• State across maps: script globals do not survive a map load (every load recompiles and restarts main(); a checkpoint load also re-runs main()). Use an archived cvar through sys.setcvar / sys.getcvar.
• Hooking a map: every map load compiles script_main.script and <map>.script (RVA 0x865440); 15 of 24 maps have a main(). A compile error is fatal, so add prefixed functions and one thread ...; line only. Budgets: 5120 statements, 1024 functions, 127-char strings, call depth 64; a loop without wait is fatal after 5M statements.
• Enemies: spawning AI with sys.spawn is unproven; the usable idiom is the map's own AI pool (hide, teleport, show, detectPlayer). Kills are counted by polling (isDead(), sys.numActiveAIs()).
• New map name: appending entries to base chunk0/chunk4 works offline; the DLC-folder route is probably blocked by the DLC ownership check.
• Cutscenes and set pieces: there is no single cutscene native. They are idFirstPersonEvent, idCameraView and idTarget_PlayVideo entities fired through trigger → idTarget_Count relay chains; a script avoids them by removing the relay or starting outside the trigger volume. No skip native was found.

Map census for combat use (static, by entity names)

Related: Modding Limits, Engine Modding Surface, Kiscule Scripting, Patch Precedence, Known Contradictions.