Presenting external gameplay data

Add IFDataSource to your gameplay adapter Blueprint. Implement Get UI Model and Request UI Action. The UI never needs to cast to your game's controller, inventory or ability component.

Create a stable IFPresentationData object for each visible model with Construct Object from Class. Set StableKey, Title, Detail, Quantity, Fraction, Icon and Enabled as appropriate. Return the same object from Get UI Model. After changing its fields, call Notify Data Changed once. Bind a screen or entry to On Data Changed, update its visuals and unbind on release/destruction.

Pass the adapter as Data to Push Screen. Initialize Screen receives it before activation; the screen stores it as Screen Data. Call Get UI Model (Message) with your agreed model name. Invoke Request UI Action (Message) for interaction. The adapter decides whether an action is valid and returns whether it accepted the request. Treat refusal as a normal result, and present feedback from the adapter.

Bind context-specific models in Initialize Screen, after calling its parent implementation. CommonUI may construct a pooled widget's Slate tree before it supplies the new context. Construct alone is therefore insufficient for a context subscription. Unbind the old context before assigning the new one, and unbind again during destruction/release. This also prevents one reused screen observing two players or entities.

The example project implements Resources, Selected, Objective, Queue and Notice, with SelectNext, Patrol, Rally and Recruit requests. Those names and the small outpost simulation belong to the example, not the plugin. Existing game systems can use different names and their own UObject models. Multiplayer adapters must send requests through their existing authoritative gameplay path; InterfaceForge does not grant authority or implement item/combat rules.

Use InterfaceForge Text for labels that should follow the local player's theme and text-size preference. Set Role and Base Size; select a Theme Override only for a local exception. IF Button exposes Label Alignment; its theme supplies padding, corner radius, font, colors and audio. Request Back and the root's Go Back invoke CommonUI's actual back handler, including Blueprint overrides and settings cancellation.

The saved Blueprint-only Watchpost source, screen and entry now have scoped source/cooked action/model/theme/focus/lifecycle proof. Follow Blueprint customization for the actual graphs and verification record for limits. The sample's FrontEnd identity model also replaces MainTitle/MainDetail through ordinary public screen nodes; menus/HUD documents that shared tree.

Menu presentation extends that saved workflow to optional Begin/Resume labels and confirmation wording, with missing/empty-model fallbacks and same-instance source reset. Menus explicitly refresh configuration text when asked; continuously changing entries still use Notify Data Changed and the entry lifecycle above.

For a remapping row, call Get Registered Mapping on IFRemappingSubsystem with your mapping name and Pointer/Keyboard/Gamepad family. It returns the first registered slot in that family and the engine's actual hardware identifier. Feed its result to Get Preview Key, Stage Key Mapping and Stage Default. Do not assume DefaultKeyboardAndMouse is the identifier of a registered mapping: engine contexts can register the neutral identifier instead. Touch capture is not implemented by this helper. Advanced multiple-slot/hardware selection can use the engine key profile's mapping rows directly.