Skip to content

Settings, input and UI

An experience can bring more than content. While it is active, it can give players settings pages, controls and UI, and take them away when it ends. A game mode brings its own scoreboard and controls; a DLC pack brings its own options. The game's menus and HUD never need to name them.

All of it works from Blueprint, and Gantry draws none of it: your widgets show what Gantry keeps.

Player settings

Each local player gets a settings registry: their pages of settings, the current values, what has changed, and their save. A settings screen reads from it and writes to it.

Pages are assets: a title ("Video", "Controls", "Crew") and the settings on it, in order. Each setting is one of Gantry's shapes, or your own subclass of one:

Shape Shows as
Number A slider, snapped to a step and clamped to its range.
Choice A rotator or drop-down. Its options can be fixed or worked out when asked for (screen resolutions, sound devices).
Toggle A check box.
Action A button: "Calibrate brightness", "Rebind keys".
Key Binding One rebindable key of an Enhanced Input mapping.

Where a value lives is up to the setting. Override Read Value and Write Value to read and write the real thing (a console variable, the game's user settings). Leave them alone and the value is simply kept in the player's save, which is all a game-only setting like a sensitivity or a crosshair colour needs. Conditions hide or disable a setting: while another setting has some value, on some platforms, or for every player but the first (for the display and sound device, which two players on one screen cannot each have).

Pages reach players two ways:

  • Listed in Project Settings > Plugins > Gantry Settings > Pages: every player has them from the start.
  • Added by an experience's Add Settings Pages stage: there while the experience is active. This is how a game mode or a DLC pack brings settings of its own.

To build the screen: get the player's registry (Get Gantry Settings, with the widget's owning player), list Get Pages and each page's settings, and show a widget per setting. Setting a value takes effect at once, so the game reflects it while the player looks. Apply Changes keeps the changes and saves them; Revert Changes puts them back. After a change to the display mode or resolution, the registry waits for Confirm Video Changes and reverts by itself after Video Confirm Seconds, the usual "keep these settings?" countdown. The example project's WBP_YR_Settings is a complete settings screen built this way.

In C++, a settings provider builds pages in code, with values, options and states bound to functions, for settings worked out at run time.

Input

The Add Input Mappings stage puts Enhanced Input mapping contexts on every local player while its experience is active, players who join later included, and takes them off when it ends. A mode's controls come and go with the mode. Contexts are counted per player, so two experiences that both add one do not take it off each other.

The stage can also register its contexts for rebinding, which is what Key Binding settings read. Gantry adds keys, not behaviour: what an input action does stays with your pawn, controller or component.

UI slots

A UI slot is a named place in your UI that other content can fill: a spot on the HUD for a mode's scoreboard, a row in the pause menu for a DLC pack's button. The UI that owns the place does not need to know what will arrive.

  • The owner calls Register UI Extension Slot with a gameplay tag naming the slot, and hears every entry that arrives or leaves, including the ones already there.
  • Content that fills it calls Add UI Extension (Class), usually with a widget class, or Add UI Extension (Object) with data, and Remove UI Extension to take it out. Each entry has a priority and a context (a local player, a team, or none), so a split-screen HUD sees only its player's entries.
  • The Add UI Extensions stage does the adding and removing for an experience, while it is active.

Gantry keeps the entries and draws nothing: the slot's owner decides what each entry becomes.

Messages

Messages let parts of a game talk without knowing each other: a mode announces a score, a DLC pack's round reacts to it, the HUD shows it, and none of them names another.

  • Broadcast Message sends any struct on a channel, which is any gameplay tag you choose.
  • Listen For Messages (an async node) hears a channel, or a channel and everything under it. In On Message Received, Get Payload reads the message into a struct of the type you expect.
  • In C++: BroadcastMessage and RegisterListener, typed.

Gantry defines no channels and no message types. Messages stay on the machine that sent them: nothing is replicated.