API Reference
Reference index. Pick the parallel Blueprint or C++ tree depending on how you author cheats.
The API reference is split into two parallel folders. Pick the one that matches how you author cheats — the trees are mirror images of each other, so the page you want has the same name in either folder.
- Blueprint — for projects that author cheats as Blueprint assets. Editor field names, BP node names, no C++.
- C++ — for projects that author cheats in C++. Header signatures, properties, virtuals, templated accessors.
Both reference the same runtime types — you can mix the two (a C++ base class with a Blueprint subclass that fills in arguments is a common pattern). Just read whichever pages match what you're touching.
Page index
| Topic | Blueprint | C++ |
|---|---|---|
| Cheat scripts | Blueprint/CheatScripts | Cpp/CheatScripts |
| Cheat arguments | Blueprint/CheatArguments | Cpp/CheatArguments |
| Subsystem | Blueprint/Subsystem | Cpp/Subsystem |
| Settings | Blueprint/Settings | Cpp/Settings |
| Input | Blueprint/Input | Cpp/Input |
| UI | Blueprint/UI | Cpp/UI |
| Function libraries | Blueprint/FunctionLibraries | Cpp/FunctionLibraries |
Concepts (shared)
A few facts are true regardless of authoring path. They're collected here so neither folder has to repeat them.
Cheat trigger sources
Three ways a cheat is invoked:
- Overlay menu — opened with the menu hotkey from the configured Input Mapping Context. Each enabled cheat appears as a row with one widget per argument and an execute button.
- Console command — registered automatically when the cheat opts
in. Optionally project-prefixed (e.g.
mygame.GodMode). - Hotkey — an Enhanced Input action bound directly to the cheat. Hotkey invocations pass an empty argument list, so cheats meant for hotkeys must either take no arguments or default every argument.
Argument types
| Type | EBlueprintCheatArgumentType |
|---|---|
| Bool | Boolean |
| Int | Int |
| Float | Float |
| Double | Double |
| String | String |
| Enum | Enum |
Each argument carries three universal fields: Position (positional
console index, also drives menu sort), bOptional (parsing succeeds
without this token), DisplayName (UI label, falls back to the
argument's name).
Console parsing example
Given:
Position 0 : Multiplier (float, default 1.0)
Position 1 : DurationSeconds (float, optional)| Console input | Result |
|---|---|
cheat | Multiplier = 1.0 (default), DurationSeconds not set. |
cheat 2.5 | Multiplier = 2.5, DurationSeconds not set. |
cheat 2.5 10 | Multiplier = 2.5, DurationSeconds = 10. |
cheat foo | Parse failure; outcome message names the offending argument. |
If Multiplier had no default and was not optional, the bare cheat
invocation would fail with Argument Multiplier is required but was not specified or defaulted.
Lifecycle
The subsystem creates one cheat-script instance per enabled class on
world match start. That instance owns its argument instances for the
lifetime of the level. After a menu-driven execution the script's
ResetState clears every argument's runtime value back to "no value"
so the same instance can be reused for the next click.
Shipping builds
Cheats are stripped from shipping builds by default (see the Settings pages). The subsystem refuses to spawn under shipping when that flag is on, which means no cheat script, console command, or hotkey is registered.