In a Common UI game
Nothing to set up. When the game viewport client is Common UI’s (Project Settings > Engine > General Settings > Game Viewport Client Class is Common Game Viewport Client or a subclass), each player’s Rolly screens open inside an activatable widget of their own on the viewport, so Common UI’s router keeps focus on them, and:
- Accept on a row acts on the row (a slider steps once, a choice moves one option), never a click at its centre;
- Rolly’s prompts stay on the player’s device: the analog cursor’s moves never switch them to the mouse;
- Back goes up Rolly’s levels, then closes the screens;
- when the last Rolly screen closes, the activatable widget goes and focus returns to the game’s widget that had it.
Rolly’s prompt bar shows the prompts of every Rolly screen. Common UI’s action bar lists nothing while a Rolly screen is on top: hide it while it is empty.
Project Settings > Plugins > Rolly Save Core UI > Common UI:
| Setting | What it does |
|---|---|
| Common UI | Auto (the default) adapts when the game uses Common UI’s viewport client; Off leaves the screens as they are. |
| Common UI Host Class | The activatable widget the screens open in: a Widget Blueprint subclass of Common Activatable Widget, to set its input config or desired focus target. Empty: Common Activatable Widget. |
| Common UI Host Panel | The panel of that class (an Overlay, by name) the screens go into. Empty: they fill it. |
Into your layer stack
To put the screens into one of your own activatable widget stacks (a Menu layer of your root layout), call Push Rolly Screens Into Common UI Stack with the player controller and the stack before you open a Rolly screen: it pushes the host class into the stack and shows the player’s screens in its panel. The stack takes the widget off again when the last Rolly screen closes.
Show the screens in a panel of your HUD
For a panel you own (an Overlay of your HUD), Set Host Panel on the player’s stack is enough; see Open screens on the screen stack.
Show the screens in a layer system
A game with its own layer system puts each player’s host (the widget that holds the player’s screens) into one of its layers with a presenter: a small C++ class implementing IRollySaveCoreUIPresenter (Present, Dismiss, IsPresented, and optionally GetAreaSize for the compact layouts), handed to each player’s stack with URollySaveCoreUIStackSubsystem::SetPresenter. While Rolly screens are open the host keeps the player’s input from the game.
Replace the input handling
A game with an input policy of its own can replace how screens take and give back the game’s input: implement IRollySaveCoreUIInputHandler and hand it to URollySaveCoreUISharedSubsystem::SetInputHandler. The built-in handler records the viewport’s input flags and the cursor when the first screen opens and restores them after the last one closes (see Open screens on the screen stack).
Limits
- The screens do not use Common UI’s bound actions: their keys come from the engine’s navigation config and the screens’ own key lists.
- Common UI’s names are read by name: a later engine version that renames one turns the adaptation off with a setup message, and the screens work as without Common UI.