Before you get in touch
Most reports come down to one of three things, and all three are quick to rule out.
If the menu will not open, check the log for the line the plugin writes at startup. It reads Cheat menu ready. Keyboard: F1 | Gamepad: <unbound> and tells you the binds it will actually respond to. If a bind reads <unbound> it was cleared in Project Settings. If the line is missing entirely, the plugin is not enabled, and if you installed it through the launcher it will not be enabled until you tick it in Edit > Plugins.
If the menu opens but is empty, the player controller has no UCheatManager. On a networked client the engine will not create one, because it checks with the game mode and there is no game mode on a client.
If a cheat does nothing when you click it, look at the row. A numeric parameter left blank blocks the run and the row names the parameter.
If everything is filed under Uncategorized in a packaged build, the metadata for those cheats was never harvested. Open the menu once in the editor and repackage. The log confirms what was written, as Baked N categories, N tooltips, N confirms and N slider ranges.
The troubleshooting page shipped in the plugin’s Docs/ folder covers these in more detail.
Reporting a bug
Send the report to the support address on the Fab listing.
- The engine version, and whether it is the launcher build
- The build configuration — several behaviours differ between the editor, PIE, and a packaged Development or Test build
- Whether a gamepad was connected, since most of the open issues below only appear when one is
- What you did, what happened, and what you expected
The most useful thing you can attach is the log. The plugin logs under LogCheatMenu, and it logs the full command string every time a cheat runs, which usually shows the problem directly.
If the issue involves a specific cheat, include its UFUNCTION declaration. Parameter types drive almost everything the menu does, so the signature is often the whole answer.
Known issues in 1.0.0
These are confirmed and documented rather than unknown. A fix for each is planned, and where a workaround exists it is listed.
A cheat name can be claimed by another handler
Cheats are dispatched through APlayerController::ConsoleCommand, where the cheat manager is only the sixth of eight handlers. A cheat whose name matches an exec on your PlayerInput, PlayerController, Pawn, HUD or GameMode will be claimed by that one instead. Rename the cheat if it does not run.
A leading object parameter shifts every argument
A cheat whose first parameter is object-typed gets that parameter bound to the executing pawn by the engine without consuming an argument, so every following argument shifts by one. Put object parameters after your value parameters.
Pure out parameters misalign the call
A cheat with a pure out parameter, meaning an out parameter that is not also a reference, is invoked with its arguments misaligned. Declare such parameters as UPARAM(ref) or avoid them on cheat functions.
Blueprint extensions contribute extra rows
Cheat extensions authored as Blueprints also contribute their Event Dispatcher signatures and Custom Event stubs to the menu. These appear as extra rows that do nothing useful.
Enum values ending in _MAX are hidden
An enum value whose name ends in _MAX in any casing is treated as the compiler-generated sentinel and hidden from the dropdown. Rename the value if you need to select it.
Category jump always wraps
The LB and RB category jump always wraps at the ends of the list and ignores the loop setting, which only governs D-pad movement.
The toggle key closes the menu under a dialog
Pressing the toggle key while a confirmation dialog is open closes the menu out from under the dialog; answering Yes still runs the cheat. Dismiss the dialog first. This one is editor and PIE only.
Favourites set in a packaged build may not persist
Starring a cheat in a packaged build writes to the per-user saved config rather than a config layer, so favourites set in a packaged build may not survive a config hierarchy change.
Two pads or multi-client PIE can drive the wrong window
Input is tracked by key identity without per-user attribution. With two gamepads connected, or in a multi-client PIE session running under one process, menu navigation can respond to the wrong pad or the wrong client window.
Some enum metadata does not survive cooking
UMETA(Hidden) and UMETA(Spacer) enum entries reappear in a packaged build, and enum DisplayName overrides fall back to the raw enumerator name there. The enum list itself is unaffected.
What is not a known issue
Two things that look like bugs and are not, because they were fixed before release. Listed because earlier notes described them as limitations.
Categories, tooltips, sliders and confirmation gates work in packaged Development and Test builds. Reflection metadata is stripped at cook, so the menu harvests it in the editor and reads it back at runtime. The only requirement is that you open the menu in the editor once after adding cheats, before packaging.
The cursor and mouse capture state is restored correctly on close, including after a cheat that replaces the player controller, such as a map travel or ToggleDebugCamera.
Version support
Each engine version is built and verified separately and listed separately. Version 1.0.0 supports Unreal Engine 5.8 on Win64 only.
This is stricter than most plugins and the reason is worth stating. The menu renders through SlateIM, which Epic ships as an experimental engine plugin. Experimental plugins carry no API stability guarantee, and SlateIM in particular ships no deprecation markers, so an API change arrives as a compile error rather than a warning. Claiming a version range without building against each version in it would be a guess.
Support for a new engine version follows that engine’s release rather than arriving with it.
What is not supported
Shipping builds
The module is excluded from Shipping by the plugin descriptor, which is deliberate: a cheat menu that can be opened in a shipped game is a liability. Guard any project code that references the plugin with #if !UE_BUILD_SHIPPING.
Platforms other than Win64. The descriptor declares SupportedTargetPlatforms as Win64, so a Game, Client or Server target for another platform will not build against it.
Dedicated servers and commandlets. There is no Slate application in either, so the subsystem does not create itself.
Still stuck
Bugs, questions and feature requests all go to the same place. Expect a reply within a few working days.