Iron Curtain — Design Documentation

Built-In Commands

Always available (all players):

Chat commands (multiplayer):

Host/Admin commands (multiplayer):

Developer commands (dev-tools feature flag + DeveloperMode active):

Diagnostic overlay commands (client-local, no network traffic):

These commands control the real-time diagnostic overlay described in 10-PERFORMANCE.md § Diagnostic Overlay & Real-Time Observability. They are client-local — they read telemetry data already being collected (D031) and do not produce PlayerOrders. Level 1–2 commands are available to all players; Level 3 panels require dev-tools.

Note on DeveloperMode interaction: Dev commands check DeveloperMode sim state (V44). In multiplayer, dev mode must be unanimously enabled in the lobby before game start. Dev commands issued without active dev mode are rejected by the sim with an error message. This is enforced at the order validation layer (D012), not the UI layer.

Comprehensive Command Catalog

The design principle: anything the GUI can do, the console can do. Every button, menu, slider, and toggle in the game UI has a console command equivalent. This enables scripting via autoexec.cfg, accessibility for players who prefer keyboard-driven interfaces, and full remote control for tournament administration. Commands are organized by functional domain — matching the system categories in 02-ARCHITECTURE.md.

Engine-core vs. game-module commands: Per Invariant #9, the engine core is game-agnostic. Commands are split into two registration layers:

• Engine commands (registered by the engine, available to all game modules): /help, /set, /get, /version, /fps, /volume, /screenshot, /camera, /zoom, /ui_scale, /ui_theme, /locale, /save_game, /load_game, /clear, /players, etc. These operate on engine-level concepts (rendering, audio, camera, files, cvars) and exist regardless of game module.
• Game-module commands (registered by the RA1 module via GameModule::register_commands()): /build, /sell, /deploy, /rally, /stance, /guard, /patrol, /power, /credits, /surrender, /power_activate, etc. These operate on RA1-specific gameplay systems — a Dune II module or tower defense total conversion would register different commands. The tables below include both layers; game-module commands are marked with (RA1) where the command is game-module-specific rather than engine-generic.

Implementation phasing: This catalog is a reference target, not a Phase 3 deliverable. Commands are added incrementally as the systems they control are built — unit commands arrive with Phase 2 (simulation), production/building UI commands with Phase 3 (game chrome), observer commands with Phase 5 (multiplayer), etc. The Brigadier CommandDispatcher and cvar system are Phase 3; the full catalog grows across Phases 3–6.

Unit commands (require selection unless noted) (RA1):

Selection commands:

Production commands (RA1):

Building commands (RA1):

Economy / resource commands (RA1):

Support power commands (RA1):

Camera and navigation commands:

Camera bookmarks (Generals-style navigation, client-local): IC formalizes camera bookmarks as a first-class navigation feature on all platforms. Slots 1-9 are local UI state only (not synced, not part of replay determinism, no simulation effect). Desktop exposes quick slots through hotkeys (see 17-PLAYER-FLOW.md), while touch layouts expose a minimap-adjacent bookmark dock (tap = jump, long-press = save). The /bookmark_set and /bookmark commands remain the canonical full-slot interface and work consistently across desktop, touch, observer, replay, and editor playtest contexts. Local-only D031 telemetry events (camera_bookmark.set, camera_bookmark.jump) support UX tuning and tutorial hint validation.

Game state commands:

Game speed and mobile tempo guidance: /speed remains the authoritative gameplay command surface for single-player and host-controlled matches. Any mobile “Tempo Advisor” or comfort warning UI is advisory only — it may recommend a range (for touch usability) but never changes or blocks the requested speed by itself. Ranked multiplayer continues to use server-enforced speed (see D055/D064 and 09b-networking.md).

Vote commands (multiplayer — see 03-NETCODE.md § “In-Match Vote Framework”):

Audio commands:

Render and display commands:

Observer/spectator commands (observer mode only):

UI control commands:

Map interaction commands:

Localization commands:

Note: Commands that affect simulation state (/move, /attack, /build, /sell, /deploy, /stance, /surrender, /callvote, /vote, /poll, etc.) produce PlayerOrder variants and flow through the deterministic order pipeline — they are functionally identical to clicking the GUI button. Commands that affect only the local client (/volume, /shadows, /zoom, /ui_scale, etc.) take effect immediately without touching the sim. This distinction mirrors the cvar split: sim-affecting cvars require DEV_ONLY or SERVER flags and use the order pipeline; client-only cvars are immediate. In multiplayer, sim-affecting commands also respect D033 QoL toggle state — if a toggle is disabled in the lobby, the corresponding console command is rejected. See “Competitive Integrity in Multiplayer” below for the full framework.

PlayerOrder variant taxonomy: Commands map to PlayerOrder variants as follows:

• GUI-equivalent commands (/move, /attack, /build, /sell, /deploy, /stance, /select, /place, etc.) produce the same native PlayerOrder variant as their GUI counterpart — e.g., /move 120,80 produces PlayerOrder::Move { target: WorldPos(120,80) }, identical to right-clicking the map.
• Cvar mutations (/set <name> <value>) produce PlayerOrder::SetCvar { name, value } when the cvar has DEV_ONLY or SERVER flags — these flow through order validation.
• Cheat codes (hidden phrases typed in chat) produce PlayerOrder::CheatCode(CheatId) — see “Hidden Cheat Codes” below.
• Chat messages (/s, /w, unprefixed text) produce PlayerOrder::ChatMessage { channel, text } — see D059 § Text Chat.
• Coordination actions (pings, chat wheel, minimap drawing) produce their respective PlayerOrder variants (TacticalPing, ChatWheelPhrase, MinimapDraw) — see D059 § Coordination.
• Meta-commands (/help, /locale, /hotkeys, /voice diag, etc.) are local-only — they produce no PlayerOrder and never touch the sim.
• PlayerOrder::ChatCommand { cmd, args } is used only for mod-registered commands that produce custom sim-side effects not covered by a native variant. Engine commands never use ChatCommand.

Game-module registration example (RA1): The RA1 game module registers all RA1-specific commands during GameModule::register_commands(). A Tiberian Dawn module would register similar but distinct commands (e.g., /sell exists in both, but /power_activate with different superweapon names). A total conversion could register entirely novel commands (/mutate, /terraform, etc.) using the same CommandDispatcher infrastructure. This follows the “game is a mod” principle (13-PHILOSOPHY.md § Principle 4) — the base game uses the same registration API available to external modules.

Mod-Registered Commands

Mods register commands via the Lua API (D004) or WASM host functions (D005):

-- Lua mod registration example
Commands.register("spawn_reinforcements", {
    description = "Spawn reinforcements at a location",
    permission = "host",       -- only host can use
    arguments = {
        { name = "faction", type = "string", suggestions = {"allies", "soviet"} },
        { name = "unit_type", type = "string", suggestions = {"Tank", "Rifle", "APC"} },
        { name = "count",   type = "integer", min = 1, max = 50 },
        { name = "location", type = "string", suggestions = {"north", "south", "east", "west"} },
    },
    execute = function(source, args)
        -- Mod logic here — note: Reinforcements.Spawn takes
        -- (faction, unit_type_list, entry_point_id), matching
        -- the canonical Lua API (see modding/lua-scripting.md).
        local units = {}
        for i = 1, args.count do table.insert(units, args.unit_type) end
        Reinforcements.Spawn(args.faction, units, args.location)
        return "Spawned " .. args.count .. " " .. args.faction .. " reinforcements"
    end
})

Sandboxing: Mod commands execute within the same Lua sandbox as mission scripts. A mod command cannot access the filesystem, network, or memory outside its sandbox. The CommandSource tracks which mod registered the command — if a mod command crashes or times out, the error is attributed to the mod, not the engine.

Namespace collision: Mod commands are prefixed with the mod name by default: a mod named cool_units registering spawn creates /cool_units:spawn. Mods can request unprefixed registration (/spawn) but collisions are resolved deterministically: sub-commands under the same parent node are merged (Brigadier tree merge — two mods adding different sub-commands under /spawn coexist). If two mods register the exact same leaf command path, the last mod loaded replaces the earlier handler, with a warning logged. The convention follows Minecraft’s namespace:command pattern.

Anti-Trolling Measures

Chat and commands create trolling surfaces. IC addresses each:

Achievement and Ranking Interaction

Following the universal convention (Factorio, AoE, OpenRA):

• Using any dev command permanently flags the match/save as using cheats. This is recorded in the replay metadata and sim state.
• Flagged games cannot count toward ranked matchmaking (D055) or achievements (D036).
• The flag is irreversible for that save/match — even if you toggle dev mode off.
• Non-dev commands (/help, /set render.shadows false, chat, /ping) do NOT flag the game. Only commands that affect simulation state through DevCommand orders trigger the flag.
• Saved game cheated flag: The snapshot (D010) includes cheats_used: bool and cosmetic_cheats_used: bool fields. Loading a save with cheats_used = true displays a permanent “cheats used” indicator and disables achievements. Loading a save with only cosmetic_cheats_used = true displays a subtle “cosmetic mods active” indicator but achievements remain enabled. Both flags are irreversible per save and recorded in replay metadata.

This follows Factorio’s model — the Lua console is immensely useful for testing and debugging, but using it has clear consequences for competitive integrity — while refining it with a proportional response: gameplay cheats carry full consequences, cosmetic cheats are recorded but don’t punish the player for having fun.