Cheat Manager Menu

Unreal Engine 5.8, Win64.

Other engine versions are not supported. The menu draws through SlateIM, an experimental engine plugin that carries no API stability guarantee and emits no deprecation warnings, so a build made against one engine version cannot be assumed to work against another. Each version is built and verified separately before it is listed.

SlateIM ships with the engine and is enabled automatically as a dependency. You will not be asked to confirm it: the editor’s experimental-plugin prompt only appears for a plugin you tick yourself, and dependencies are pulled in silently.

The plugin ships no content assets.

There are two routes in and they behave differently.

From the Epic Games Launcher

In the launcher, open Library, find Cheat Manager Menu, and choose Install to Engine. Then open your project, go to Edit > Plugins, find Cheat Manager Menu under the Debug category, tick it, and restart the editor when prompted.

A plugin installed into the engine is not enabled until you tick it. If you install the plugin and nothing happens when you press F1, that is almost always the reason.

You do not need a compiler to use the plugin in the editor. A launcher install ships the module prebuilt, so a Blueprint-only project works. Packaging is different: enabling the plugin makes Unreal treat your project as code-based and build a project-specific game binary for any Development, DebugGame or Test client build, and that step needs a C++ toolchain. On Windows that means Visual Studio 2022 with the Desktop development with C++ workload.

From source

Copy the plugin folder to <YourProject>/Plugins/CheatManagerMenu, regenerate project files from your .uproject, and build the editor target. This route needs a C++ project because the module compiles as part of your build.

A plugin inside <YourProject>/Plugins is enabled by default, so there is nothing to tick.

Any UFUNCTION(Exec) on your cheat manager or on a cheat manager extension shows up in the menu. Nothing registers it.

UCLASS()
class UMyCheats : public UCheatManagerExtension
{
    GENERATED_BODY()

public:
    /** 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 produces a World section with two cheats. SetTimeOfDay gets a slider running from 0 to 24 in quarter-hour steps, starting at noon, with the doc comment as its tooltip. WipeSettlement asks for confirmation before it runs.

Designers can add cheats without touching C++ by subclassing UCheatMenuBlueprintExtension in Blueprint and listing the class under Project Settings > Plugins > Cheat Manager Menu.

The Category on a UFUNCTION becomes the section header the cheat is filed under. Cheats that declare no category collect under Uncategorized.

UFUNCTION(Exec, Category = "World")
void SetTimeOfDay(float Hours);

UFUNCTION(Exec, Category = "World")
void SetWeather(EWeatherType Weather);

UFUNCTION(Exec, Category = "Player")
void GiveGold(int32 Amount);

/** No Category, so this one lands under Uncategorized. */
UFUNCTION(Exec)
void ResetTutorial();

Those four cheats produce three collapsible sections:

[-] Player (1)
      GiveGold        Amount [    ]
[-] Uncategorized (1)
      ResetTutorial
[-] World (2)
      SetTimeOfDay    Hours  [    ]
      SetWeather      Weather [Clear v]

Sections sort alphabetically by default. To pin the ones you use most to the top, list them under Project Settings > Plugins > Cheat Manager Menu > Category Order. Anything not listed there follows in alphabetical order after the ones that are. There is also a setting to force a category named General to the top without listing it.

The category string is matched without regard to case or surrounding spaces, so "World" and "world " are the same section. It is used verbatim as the header text, so write it the way you want it displayed.

Category comes from metadata, which the engine strips when it cooks. The menu records it in the editor so it still works in a packaged build. See What changes in a packaged build.

Everything the menu reads from a cheat declaration, in one place.

A worked example using all of them:

/** Floods the settlement to the given depth. Destroys crops. */
UFUNCTION(Exec, Category = "World", meta = (CheatConfirm = "Flood the settlement?"))
void FloodSettlement(UPARAM(meta = (UIMin = "0", UIMax = "10", Delta = "0.5", UIDefault = "2")) float Depth);

That files the cheat under World, puts the doc comment on its tooltip, draws Depth as a slider from 0 to 10 in half-unit steps starting at 2, and asks for confirmation before it runs.

A numeric parameter draws a slider only if it declares both ends of a range, using the keys in the table above. A range whose maximum is not greater than its minimum is ignored and the parameter falls back to a text box.

Enum dropdowns need no metadata for the list itself. They list the enum’s display names, skip the generated _MAX entry, skip entries marked UMETA(Hidden) or UMETA(Spacer), and pass the bare enumerator name to the cheat.

Return parameters and pure out parameters are skipped. In-out reference parameters get an input.

Almost nothing, but it is worth knowing why, because the engine does not make this easy.

UFUNCTION metadata is editor-only. WITH_METADATA follows WITH_EDITORONLY_DATA, so Category, tooltips, CheatConfirm and the slider ranges do not exist in a packaged Development or Test build. Left alone, the menu would collapse into one Uncategorized block of text boxes with no tooltips and no confirmation prompts.

The menu bakes instead. Every time you open it in the editor it records the metadata of every cheat it finds, and at runtime the lookups fall back to that. Categories, tooltips, sliders and confirmation gates all keep working.

Three consequences worth knowing.

A cheat whose cheat manager or extension was never live while the menu was open has nothing baked for it, and shows up uncategorised in a packaged build. Being filtered out or inside a collapsed category does not matter, since every cheat found is baked. Opening the menu once before you package covers it.

The bake writes to a config file the plugin owns rather than to your DefaultGame.ini. With the plugin in your project it is Plugins/CheatManagerMenu/Config/DefaultCheatManagerMenu.ini; with the plugin installed into the engine, where that folder is shared between projects and usually not writable, it falls back to Config/DefaultCheatManagerMenu.ini in your project. Both are staged into packaged builds. Commit whichever one appears, because it is what carries this data into builds made by anyone else, including a build machine that has never opened the menu.

It only writes when something changed, and logs under LogCheatMenu when it does. If the plugin’s own config file is read-only, the write falls back to the project’s Config folder; only when neither location is writable is it skipped, with a warning, and the previously baked data still applies. A failed write is not retried in the same editor session, so fix the permission and restart the editor.

Baking is also the only way this can work for Blueprint cheats at all. Their metadata lives in editor-only asset data and is stripped at cook no matter how the game module is compiled.

Enum dropdowns keep their values either way, because the list comes from the UEnum rather than from metadata, as do the cheat list, the filter box, favourites and gamepad navigation. Two enum details are metadata-driven and are not baked: UMETA(Hidden) and UMETA(Spacer) entries reappear in a packaged build, and DisplayName overrides fall back to the raw enumerator name.

Bug reports, known issues and the version support policy live on the support page.