Set Input Mode & Show Mouse Cursor¶

At a glance

Lives in: Blueprint API / Input for the Set Input Mode nodes; PlayerController for Show Mouse Cursor - Returns: nothing - Changes: local input routing, UI focus/mouse capture options, and whether the local player controller wants a cursor shown - Can fail by: targeting the wrong or missing PlayerController, focusing the wrong widget, or never restoring the old mode - Official docs: Set Input Mode Game and UI, Set Input Mode Game Only, Set Input Mode UI Only, and APlayerController

The one-minute version¶

Set Input Mode decides who gets input first: the game, the UI, or the UI with possible fallback to the game.
Show Mouse Cursor is separate. You can show a cursor while still being in a game input mode, or set a UI input mode and forget to show the cursor.
Open an interactive menu by pairing the three things: add/show the widget, set focus/input mode, and show the cursor.
Close the menu by undoing the three things: remove/hide the widget, restore Game Only, and hide the cursor.
If the pawn keeps moving under a menu, you probably used Game and UI without pausing the game or ignoring movement input.
If input dies after closing a menu, you probably never restored Game Only, focus, cursor state, or the input mapping context you changed elsewhere.

What it actually does¶

The Set Input Mode nodes are convenience Blueprint nodes that configure the local PlayerController's input mode. They do not add a widget, pause the game, or change Enhanced Input mapping contexts. They tell the controller and viewport how to route input for the current player.

At beginner altitude, the modes mean:

Mode	Beginner translation	Typical use
Game Only	Player/controller input handles the game. UI is not the intended target.	Normal gameplay HUD, no mouse menu open.
Game and UI	UI gets a chance first; unhandled input can still reach player/controller input.	Inventory screens, radial menus, in-game UI where movement may continue.
UI Only	UI is the intended target; gameplay input should not drive the pawn.	Pause menu, main menu, modal screen.

The cursor flag lives on the PlayerController:

Set Show Mouse Cursor true  -> the player controller wants the cursor visible
Set Show Mouse Cursor false -> the player controller wants it hidden

Putting those together:

pseudocode of the Blueprint pattern - not engine source

function OpenPauseMenu(PlayerController):
    if PauseMenuWidget is None:
        PauseMenuWidget = CreateWidget(WBP_PauseMenu, PlayerController)

    PauseMenuWidget.AddToViewport(ZOrder = 100)
    PlayerController.SetShowMouseCursor(true)
    SetInputModeUIOnly(PlayerController, WidgetToFocus = PauseMenuWidget)

Input mode is a local screen/control setting. It is not a replicated gameplay state. In multiplayer, each client needs its own local UI setup for that client's screen.

The pins that matter¶

Player Controller¶

This is the controller whose local input and viewport you are changing. For a single-player project, it is often Get Player Controller 0. Inside a custom PlayerController Blueprint, it is usually Self.

If this reference is wrong, every other pin can look correct while the player you are testing does not change.

Game and UI and UI Only can receive a widget to focus. Focus matters for keyboard/gamepad UI navigation and for close keys like Escape.

If the focused widget is None, removed from parent, or not focusable, the menu may appear but keyboard input will seem lost. For a pause menu, focus a real root widget that is on screen, and make sure the widget or one of its children can receive focus if you expect keyboard/controller navigation.

Mouse Lock Mode¶

Mouse lock controls how the cursor is confined relative to the viewport while the mode is active. Beginners usually leave the default until they are building windowed menus, drag/drop UI, or multi-monitor behavior.

Hide Cursor During Capture¶

On Game and UI, this decides whether the cursor hides during mouse capture interactions such as click-drag. If the cursor seems to disappear only while dragging, check this pin before blaming the widget.

Flush Input¶

Flush Input clears current pressed-key state while switching modes. This can prevent the key that opened a menu from also being treated as still held after the mode changes. If you see "I pressed Escape and the menu instantly closed again" or a held movement key continuing through a transition, test this pin.

When it fails (and what failure does)¶

These nodes do not return success/failure. Failure usually looks like "the screen changed, but controls feel wrong."

Common causes:

The PlayerController reference is None or not the local controller. There is no useful local input mode to change for the player you meant.
The menu widget is not valid or not on screen yet. You focused a widget that was never created, was removed, or belongs to another instance.
The widget cannot receive focus. Mouse clicks may still work, but keyboard/gamepad navigation or Escape handling can fail.
You used Game and UI for a modal menu. The UI appears, but unhandled movement/look input can still reach the pawn.
You used UI Only and put the close key in the pawn/controller. The mode is doing what you asked: gameplay input is not driving that graph. Handle close from the focused widget, or use Game and UI deliberately.
You hid the widget but did not restore the mode. The player returns to the game with UI input routing still active.
You restored input mode but not cursor state. The game receives input again, but the cursor stays visible or remains captured in an unexpected way.
You changed Enhanced Input contexts separately. Set Input Mode is not Add Mapping Context or Remove Mapping Context. If a mapping context was removed on menu open, restoring Game Only will not add it back.
The game is paused and the close path cannot tick or receive input. UI can still respond while paused when set up for it, but gameplay actors often will not. Put pause-menu close logic on the widget/controller path you know still receives input.

There is no hidden error handler. The execution pin continues. Use Print String and the Output Log or breakpoints to prove the open and close paths both run.

The pattern everyone actually uses¶

For a simple pause menu in a PlayerController Blueprint:

Input Pause
-> Branch bMenuOpen

false path:
    Branch IsValid(PauseMenuWidget)
        false:
            Create Widget WBP_PauseMenu (Owning Player = Self)
            Set PauseMenuWidget

    PauseMenuWidget Add to Viewport (ZOrder = 100)
    Set Game Paused true
    Set Show Mouse Cursor true
    Set Input Mode UI Only
        Player Controller = Self
        In Widget to Focus = PauseMenuWidget
        Flush Input = true
    Set bMenuOpen true

true path:
    PauseMenuWidget Remove from Parent
    Set Game Paused false
    Set Show Mouse Cursor false
    Set Input Mode Game Only
        Player Controller = Self
        Flush Input = true
    Set bMenuOpen false

If UI Only prevents your controller's Pause input from firing on close, move the close command into the menu widget: a Resume button, an override that handles Escape when focused, or a widget event that calls back to the controller's close function.

For an inventory screen where the character can keep moving:

OpenInventory
-> Add inventory widget to viewport
-> Set Show Mouse Cursor true
-> Set Input Mode Game and UI
   In Widget to Focus = InventoryWidget

That is a deliberate choice. If movement under the inventory is not wanted, pause, disable movement input, or use UI Only and provide a UI-owned close path.

The C++ twin, for the curious (our own example code):

void ATrainingPlayerController::OpenPauseMenu()
{
    if (!IsValid(PauseMenuWidget))
    {
        PauseMenuWidget = CreateWidget<UUserWidget>(this, PauseMenuClass);
    }

    if (!IsValid(PauseMenuWidget))
    {
        return;
    }

    PauseMenuWidget->AddToViewport(100);
    bShowMouseCursor = true;

    FInputModeUIOnly Mode;
    Mode.SetWidgetToFocus(PauseMenuWidget->TakeWidget());
    SetInputMode(Mode);
    SetPause(true);
}

What these nodes do not do¶

They do not create, add, remove, or destroy widgets.
They do not pause the game unless you also call Set Game Paused.
They do not show or hide the cursor unless you also set the cursor flag.
They do not add or remove Enhanced Input mapping contexts.
They do not make a widget focusable if its widget settings prevent focus.
They do not replicate to other clients.
They do not decide where UI belongs. For player UI, prefer the PlayerController or HUD setup path over a respawnable pawn.

Lookalikes - which one do I want?¶

Node / setting	Use when	It does not
Set Input Mode Game Only	Returning to normal gameplay.	Hide the cursor or re-add removed mapping contexts.
Set Input Mode Game and UI	UI should handle clicks/focus first, but game input may still run.	Stop unhandled movement/look input by itself.
Set Input Mode UI Only	A menu should own input while open.	Let pawn/controller gameplay input keep firing normally.
Set Show Mouse Cursor	You want the local player controller to show/hide the cursor.	Change input routing or focus.
Set Game Paused	Gameplay simulation should pause behind the menu.	Configure UI focus or cursor.
Enable / Disable Input	You are enabling input on a specific actor.	Replace controller-level input mode for menus.
Add / Remove Mapping Context	Enhanced Input bindings should change for a player.	Focus widgets or show the cursor.
Set Keyboard Focus	A specific widget should receive keyboard focus.	Change the whole player controller input mode.

Rule of thumb: opening a menu is a bundle, not one node. Display the widget, set the mode/focus, show the cursor, and decide whether gameplay should pause. Closing the menu must restore the same bundle in reverse.

Going deeper¶

Create Widget + Add to Viewport - creating and storing the widget before focusing it.
Updating a Widget: Bindings vs Events - how the menu or HUD receives gameplay data after it exists.
Get Player Character / Pawn / Controller - why the controller is the object these nodes usually target.
Possession - why UI tied to a pawn can break when that pawn is replaced.
The Blueprint survival kit - organizing the open/close menu flow without turning the event graph into a knot.
Official docs: Set Input Mode Game and UI, Set Input Mode Game Only, Set Input Mode UI Only, Creating Widgets, and APlayerController.
Engine source (requires engine access - we do not reproduce it here): UWidgetBlueprintLibrary::SetInputMode_GameOnly, UWidgetBlueprintLibrary::SetInputMode_GameAndUIEx, and UWidgetBlueprintLibrary::SetInputMode_UIOnlyEx are declared in Engine/Source/Runtime/UMG/Public/Blueprint/WidgetBlueprintLibrary.h and implemented in Engine/Source/Runtime/UMG/Private/WidgetBlueprintLibrary.cpp; APlayerController::SetInputMode is declared in Engine/Source/Runtime/Engine/Classes/GameFramework/PlayerController.h and implemented in Engine/Source/Runtime/Engine/Private/PlayerController.cpp; bShowMouseCursor and its SetShowMouseCursor Blueprint setter are declared in Engine/Source/Runtime/Engine/Classes/GameFramework/PlayerController.h.