API Reference
Editor-side surface (settings file) and the C++ subsystems for projects extending the plugin from code.
Two parallel folders, mirrored by topic where it makes sense:
- Editor — the toolbar widget and the settings file. This is where most users go.
- C++ — the
runtime/editor subsystems and the settings
UCLASSfor projects extending the plugin from code.
The toolbar widget is documented separately as a first-class page — see Toolbar. It's the plugin's primary surface, not an API detail.
Page index
| Topic | Editor | C++ |
|---|---|---|
| Settings | Editor/Settings | Cpp/Settings |
| Editor subsystems | — | Cpp/EditorSubsystems |
Concepts (shared)
A few facts are true regardless of which page you're reading.
What the override does
When the override is on and a class is selected, the plugin sets
World->GetWorldSettings()->DefaultGameMode = OverrideClass on the
live world at initialization time. The level asset itself is not
modified. The original DefaultGameMode is captured before the swap
so it can be restored on PIE end.
Where it applies
The override is editor-only by design. It runs in PIE and editor sessions; packaged and standalone builds always use the level's authored game mode.
Two subsystems cover the editor surface:
| Context | Subsystem | Module |
|---|---|---|
| PIE / editor sessions | UOverrideGameModeGameInstanceSubsystem | QuickGameModeOverrideEditor |
| Toolbar widget | UOverrideGameModeUISubsystem (editor subsystem) | QuickGameModeOverrideEditor |
The editor GameInstance subsystem captures the world's authored
DefaultGameMode before swapping in the override, then restores it on
PIE end — so the override is fully transparent across PIE sessions.
Where it persists
Config/DefaultQuickGameModeOverride.ini. The settings object writes
through to that file via SaveDefault() whenever the toolbar widget
changes a value. Two keys:
[/Script/QuickGameModeOverride.QuickGameModeOverrideSettings]
bOverrideGameMode=True
OverrideGameModeClass=/Script/Engine.GameModeBaseOverrideGameModeClass is a TOptional<TSubclassOf<AGameModeBase>>
under the hood — when unset, no key is written.
When it does not apply
- Packaged / standalone builds. The plugin is editor-only by design — the runtime module ships the settings object only, with no behavior of its own.
- Commandlets and the cook commandlet. The editor GameInstance
subsystem refuses to spawn there (
IsRunningCommandlet() || IsRunningCookCommandlet()), so cooking and headless tooling pick up the level's authored game mode.