How it works
The menu reads the local player’s UCheatManager and every cheat manager extension registered on it, then draws a row for each cheat it finds. Add a cheat, and it is there the next time you open the menu.
Parameters get an input widget picked from their type. A checkbox for a bool, a dropdown for an enum, a slider for an int32, float or double that declares a range, and a text box for anything else. Doc comments become tooltips. UFUNCTION categories become collapsible sections.
/** Sets the time of day, in hours. */
UFUNCTION(Exec, Category = "World")
void SetTimeOfDay(
UPARAM(meta = (UIMin = "0", UIMax = "24", Delta = "0.25", UIDefault = "12"))
float Hours);
/** Removes every building in the settlement. Cannot be undone. */
UFUNCTION(Exec, Category = "World", meta = (CheatConfirm = "Wipe the whole settlement?"))
void WipeSettlement();That is a World section with two cheats. One gets a slider from 0 to 24 in quarter-hour steps starting at noon. The other asks before it runs.
It still works after you package
Categories, tooltips, sliders and confirmation prompts come from reflection metadata, and the engine strips that when it cooks. Reflection-driven menus usually collapse into a flat alphabetical list of text boxes in a packaged build, which is where a cheat menu earns its keep.
This one records what it needs while it draws in the editor and reads it back at runtime, so a packaged Development or Test build matches what you saw in PIE. Open the menu once in the editor after adding cheats, before you package. It is also the only route that works for Blueprint cheats, whose metadata is stripped at cook no matter how the project is configured.
Built for a list that got long
- Filter box matching on name, category and description, expanding collapsed sections so a match cannot hide
- Favourites, pinned with the + button on a row, persisted to config
- Recently Used, per session, with a configurable length
- Category ordering you can pin in Project Settings
- Panel size and offset configurable, with the height capped against the viewport
Designers can add cheats too
Derive a Blueprint from Cheat Menu Blueprint Extension, add impure functions to it, then list the class under Blueprint Cheat Extensions in Project Settings. Those functions appear beside the C++ cheats with the same categories, tooltips and parameter widgets. No programmer, no rebuild.
Input it takes, input it leaves alone
F1 opens the menu. No gamepad button is bound out of the box, and that is deliberate: the plugin registers an application-wide Slate input pre-processor and consumes whatever you bind to it, so taking a face button from your game without asking is not a call a plugin should make.
Bind one in Project Settings and the menu drives from a pad, with the D-pad or left stick to move, (A) to run a cheat, and the shoulder buttons to jump between categories. The console command CheatMenu.Toggle opens it on any device with no bind at all, which is the way in on a touch device or a machine with no keyboard attached.
bEnabled is a real off switch. Clearing it stops the subsystem being created, which takes the input pre-processor and the console command with it.
Nothing to remember before you ship
The module is compiled out of Shipping builds by the plugin descriptor. No define to remember, and no way to leave the menu in a shipped game by accident. Code of your own that calls into the plugin does need guarding, and the documentation covers how.