Context Menu

Surfaces a dynamic list of actions on any target — items (Use / Drop / Split), doors (Lock / Unlock / Open / Close), NPCs, world pickups — with either a modal cursor-anchored popup or a world-anchored panel that tracks a USceneComponent (Cyberpunk scan-mode / Dishonored body-interaction feel).

Plugin pieces involved

Integration steps

1. Enable the plugins

Open Edit → Plugins, search Crimson, and tick all five so each is enabled: CrimsonCommon, CrimsonUI, CrimsonInventory, CrimsonInteraction, and CrimsonCore. CrimsonCore depends on them, so the Plugins window flags them as required. Restart the editor when prompted — for a Blueprint project that's the whole install, with no .uproject or .Build.cs to edit.

2. Register the UI.Layer.ContextMenu layer

Open your UCrimsonHUDLayout Blueprint. Add a UCommonActivatableWidgetStack named e.g. Stack_ContextMenu. Wire RegisterLayer to attach it under the native tag.

// C++ — anywhere in your HUD layout init (typically RegisterLayers):
#include "ContextMenu/CrimsonContextMenuTags.h"

RegisterLayer(CrimsonContextMenuTags::UI_Layer_ContextMenu, Stack_ContextMenu);

3. Create the menu widget Blueprints

Three widgets need BP subclasses. C++ bases own all logic; BP supplies visuals.

Inside ContentPanel, add a Dynamic Entry Box named exactly EntryBox and set its Entry Widget Class to WBP_ContextMenuEntry. C++ creates the entries automatically on activation and refresh - no MVVM view binding needed. (A UListView named EntryList is also supported for long scrollable menus, but a virtualizing list inside the auto-sized panel must be given a bounded height or it generates only one row.) A missing ContentPanel is a Blueprint compile error; missing both entry hosts logs a warning at activation.

4. Wire input bindings in the menu widget BP

Mouse needs no wiring — entries confirm on click and focus on hover natively. For gamepad/keyboard, the widget base exposes BlueprintCallable methods — in OnActivated, register UI action bindings for each of these tags.

5. Map the UI action tags to UInputAction assets

In your project's UCommonUIInputData (or UCrimsonInputConfig, whichever feeds the CommonUI action router), add one row per tag.

UI.Action.ContextMenu.Confirm         -> IA_UI_Confirm
UI.Action.ContextMenu.Cancel          -> IA_UI_Cancel
UI.Action.ContextMenu.Navigate.Up     -> IA_UI_NavigateUp
UI.Action.ContextMenu.Navigate.Down   -> IA_UI_NavigateDown
UI.Action.ContextMenu.Cycle.Next      -> IA_UI_CycleNext      (RB / E)
UI.Action.ContextMenu.Cycle.Previous  -> IA_UI_CyclePrevious  (LB / Q)

6. Attach the player component

UCrimsonContextActionPlayerComponent carries the Server_ExecuteContextAction RPC. Choose one attachment path; the component sets SetIsReplicatedByDefault(true) automatically.

// Option A — C++ subclass of your player controller:
ACrimsonPlayerController::ACrimsonPlayerController()
{
    ContextActionComponent = CreateDefaultSubobject<UCrimsonContextActionPlayerComponent>(
        TEXT("ContextActionComponent"));
}

Option B — add a GFA_AddComponents entry to your experience definition targeting APlayerController.
Option C — add the component in your PC Blueprint's Components panel.

7. Configure per-item-type defaults (optional)

For "all weapons get Inspect/Drop", "all consumables get Use/Drop":

8. Author per-item actions

Open any UCrimsonInventoryItemDefinition and add UCrimsonInventoryItemFragment_ContextActions to its Fragments array. Populate the fragment's Actions array with instanced subclasses of UCrimsonContextAction.

9. Show the menu from your gameplay code

// Inventory item — modal, cursor-anchored:
ULocalPlayer* LP = PC->GetLocalPlayer();
UCrimsonCoreContextMenuSubsystem* CM = LP->GetSubsystem<UCrimsonCoreContextMenuSubsystem>();

FCrimsonContextMenuRequest Request;
Request.PresentationMode = ECrimsonContextMenuPresentationMode::Modal;
Request.Header           = FText::FromString(TEXT("Item Actions"));
Request.bAnchorToCursor  = true;
// Widget class is optional — unset falls back to
// UCrimsonUISettings::DefaultModalContextMenuClass (Project Settings -> Crimson -> Crimson UI).

CM->ShowContextMenuForItem(ItemInstance, Request);

// Door / NPC — world-anchored:
FCrimsonContextMenuRequest Request;
Request.PresentationMode = ECrimsonContextMenuPresentationMode::World;
Request.Header           = FText::FromString(TEXT("Door"));
// Request.WorldWidgetClass optional (falls back to UCrimsonUISettings::DefaultWorldContextMenuClass).
// Request.TargetAnchor is auto-filled to Actor->GetRootComponent() if not set.

CM->ShowContextMenuForActor(FocusedDoor, Request);

Typical trigger points: UCrimsonInventorySlotWidget::OnContextMenuRequested on right-click, a 'Hold E to see actions' branch on your interaction ability, or a direct HUD button. For the double-click / tap fast path that skips the menu, call ExecuteDefaultActionForItem / ExecuteDefaultActionForActor — it dispatches the first enabled action flagged bIsDefault (else the first enabled action).

Discovery rules

Out of the box: ACrimsonInteractableActor

ACrimsonInteractableActor ships with the full flow pre-wired: it implements ICrimsonContextActionProvider, and with bShowContextMenuOnInteract (default on) a successful interaction opens the world-anchored menu on the interacting player. Author actions as Crimson Context Action Set Data Assets referenced in ContextActionSets - a plain asset picker, shareable across every door/lever, with asset edits propagating to all of them. There is deliberately no inline action array on the actor (Instanced arrays on level-placed actors keep stale per-instance copies).

World-menu lifetime and feel are per-asset options on the widget Blueprint (UCrimsonContextMenuWidget_World class defaults): AutoCloseDistance closes the menu when the pawn walks away (the server-side crimson.ContextMenu.MaxExecuteDistance check backs it up), bCloseOnClickOutside gives the dialog-border dismiss pattern, and bScaleWithDistance / bFadeWhenOccluded fake depth and stop the menu drawing through walls.

Subclassing UCrimsonContextAction

UCLASS(DisplayName = "Drop Item")
class UMyAction_DropItem : public UCrimsonContextAction
{
    GENERATED_BODY()
public:
    virtual bool IsAvailable_Implementation(const FCrimsonContextActionContext& Context) const override
    {
        return Cast<UCrimsonInventoryItemInstance>(Context.Target.Get()) != nullptr;
    }
    virtual void ExecuteAction_Implementation(const FCrimsonContextActionContext& Context, const FInstancedStruct& Payload) override
    {
        // Runs under HasAuthority() on the server — do the deed here.
        // Payload is empty for plain clicks; ConfirmEntryWithPayload can pass arguments.
    }
};

Or create a Blueprint subclass directly — UCrimsonContextAction is Blueprintable, EditInlineNew, DefaultToInstanced, so designers can author actions inline on item fragments without C++.

Common pitfalls