Step 2 Opening The Menu
In your own player controller Blueprint, bind any key event (e.g. M) to
Toggle Settings Menu (UOkMenuLibrary). The node:
- creates the menu widget and adds it to the viewport,
- switches to UI-only input with the cursor shown,
- pauses the game (optional
Pause Gamepin), - and undoes all of it when the menu closes - via Escape, gamepad B, the footer
Cancel button, or a
Close Settings Menucall.
Open Settings Menu, Close Settings Menu, Is Settings Menu Open and
Get Settings Menu cover the non-toggle flows. Per-player state lives in a local
player subsystem, so split-screen players get independent menus.
Project Settings → Plugins → OptiKit → Menu Widget Class - it ships pointing at
WBP_OkSettingsMenu. Point it at your own copy once and every open call in the
project uses it. One setting, one source of truth; if the field is ever emptied, the
shipped menu still opens.
Escape + gamepad B by default. Change them under Project Settings → Plugins → OptiKit → Menu Close Keys - list one keyboard and one gamepad key. If you pick a rebindable key, add it to Reserved Rebind Keys too so players cannot bind it to an action.
| Setting | Purpose |
|---|---|
| Default Theme | Theme used when the menu widget's own Theme is empty |
| Menu Widget Class | Widget the open functions create |
| Menu Close Keys | Keys that ask the menu to close |
| Autosave On Change | Commit every change instantly instead of waiting for Apply |
| Text Library | Data Asset for dialog/error texts (Step 7) |
| Definition Scan Paths | Content paths scanned for setting Data Assets |
The classic flow still works: Create Widget (WBP_OkSettingsMenu) →
Add to Viewport → set your input mode → bind the menu's On Close Requested
event and restore input there. Without a binding the menu still removes itself on a
close key - restoring your input mode is the only part it cannot do for you.
Next: Step 3: Settings Catalog