The game's UI system (ink): building, injecting and drawing XF UI in game

Maturity: Draft. How Cyberpunk 2077 draws its UI (ink), how a mod builds widgets from script, matches the game's look, takes input, adds to every standard screen, draws over the world, adds map pins and markers, and renders 3D into UI; plus the answer on an XF-owned ImGui overlay (§8, from the 30 September feasibility study). Consolidated on 29 September 2026 from the decompiled 2.31 script bundle (r6/cache/final.redscripts, SHA-256 2119046f…ee86, redscript-cli 0.5.31 decompile -f into a private scratch folder; paths below are that tree's), the source of Codeware v1.20.4 (613a1cb8), Red Hot Tools (b4d3415), Equipment-EX (3208ff4), Cyber Engine Tweaks 1.37.1 (9a8522f), Mod Settings (e904815) and Let There Be Flight (6d7c1b7), and the installed script files of mods that inject UI (Dark Future, Vehicle Navigation System, Sheng Noods Ramenshop; read-only in the MO2 mods folder). No claim on this page has been seen in game yet except where marked runtime; the XF Runtime Bridge 0.5.3 demos (§9) are the first in-game test, on the ink demo rows (group F of the session-7 checks). The route map for the in-game ambitions is in-game UI design. Grades follow the knowledge rules.

1. The short answers

2. Widgets from script

2.1 The widget classes

Every widget: SetName, SetVisible, SetOpacity, SetTintColor(HDRColor), SetAnchor(inkEAnchor), SetAnchorPoint, SetMargin, SetPadding, SetSize, SetHAlign/VAlign, SetScale, SetRotation, SetShear, SetTranslation, SetRenderTransformPivot, SetInteractive, SetStyle, BindProperty, SetState, PlayAnimation(WithOptions), RegisterToCallback(event, object, function), SetEffectEnabled/SetEffectParamValue (per-widget effects such as blur, glitch and colour correction), and Reparent(parent, opt index) source abstractWidgets.script:2-227. Compound widgets add AddChild(typeName), AddChildWidget, GetWidgetByPathName, RemoveChild, ReorderChild, SetChildOrder source :230-276.

Library widgets. A controller spawns items from its own library (SpawnFromLocal) or another .inkwidget (SpawnFromExternal, async variants), which is how every game screen is built source core/ui/baseControllers/widgetController.script. ArchiveXL's ink-spawner extension (and Codeware's) accept item:Controller to attach a script controller class to the spawned root source (terminals §4). A mod that ships its own .inkwidget gets designer layouts; one that builds in script needs no archive (the XF demos build in script).

2.2 Reaching layers and screens

• Vanilla: only from inside a controller you already hook (this.GetRootCompoundWidget() in a wrapped OnInitialize), or through objects a system hands you source.
• Codeware: GameInstance.GetInkSystem().GetLayers(), GetLayer(n"inkHUDLayer"), GetWorldWidgets(); a layer wrapper's GetVirtualWindow(), GetGameController(), GetGameControllers() source Codeware scripts/UI/inkSystem.reds, src/App/UI/inkSystem.hpp. Its wiki's own example reparents a text straight into the HUD layer's virtual window source Codeware wiki/Home.md "Layers and windows".
• Installed practice: Dark Future and Vehicle Navigation System reparent a 3840×2160 inkCanvas into GetLayer(n"inkHUDLayer").GetVirtualWindow().GetWidgetByPathName(n"Root"), check first whether their named canvas is already there (a layer outlives a session), and scale it with Codeware's VirtualResolutionWatcher source DFHUDSystem.reds (CreateFullScreenSlot), VNS.reds (MinimapContainerController.InitializePlayer wrap). The watcher scales by screen size / 3840×2160 per axis, which implies the HUD root is in screen pixels [hypothesis from runtime-proven mods]; per-axis scaling squashes text on ultrawide screens, so the XF overlay scales uniformly by height (2160 units high, as wide as the aspect makes it).

2.3 Styles, fonts and colours

• SetStyle(styleResPath) attaches an .inkstyle; BindProperty(propertyName, styleVariable) binds tintColor, fontSize, fontStyle/fontWeight or opacity to a named value in it source abstractWidgets.script:24, 221.
• The shared style sheets: base\gameplay\gui\common\main_colors.inkstyle (the palette), base\gameplay\gui\fullscreen\fullscreen_main_colors.inkstyle, …\common\dialogs_popups.inkstyle, …\common\tooltip\tooltip_menu.inkstyle and tooltip_hud.inkstyle, …\fullscreen\hub_menu\hub_menu_style.inkstyle, …\common\components\toggles_style.inkstyle and slots_style.inkstyle, …\widgets\notifications\notification.inkstyle source path counts in the 2.31 scripts and installed mods.
• The HUD's grammar in practice: headers in MainColors.Red (upper case, Semi-Bold), body text in MainColors.Blue (the cyan), warnings ActiveRed, success Green/ActiveGreen, prompts Yellow, dark translucent panels with a thin red edge source token use in 2.31 scripts; the look itself hypothesis until compared with captures.
• Codeware keeps a few literal HDR colours (ThemeColors.ElectricBlue, Bittersweet, Dandelion…) and recommends binding main_colors.inkstyle instead source scripts/UI/Styles/ThemeColors.reds. HDR colours go above 1.0 for glow (the game's red is about 1.176, 0.381, 0.348).

2.4 Animation

inkAnimDef holds interpolators (inkAnimTransparency, inkAnimTranslation, inkAnimScale, inkAnimRotation, inkAnimColor, inkAnimSize, inkAnimMargin, inkAnimPadding, inkAnimShear, inkAnimTextInterpolator, inkAnimEffect), each with duration, delay, easing (SetType, SetMode) and direction; PlayAnimationWithOptions(def, inkAnimOptions) takes loop type (Cycle, PingPong), loop count or infinite, markers and whether it follows time dilation; the proxy's RegisterToCallback(inkanimEventType.OnFinish | OnEndLoop | …, object, function) calls back source orphans.script:6512-6524, 31496-31589, 35211-35229. Library animations play by name (PlayLibraryAnimation). An endless looping animation is a UI-clock tick: the game itself drives text scrolling and minigame buffers from OnEndLoop source core/ui/textScrollingAnimController.script:91, networkMinigameBufferController.script:57. With dependsOnTimeDilation false it keeps running while the world is paused [source; in game hypothesis]. The XF overlay ticks this way (about 30 Hz), which ties the tick's lifetime to its widget.

2.5 Input on ink

• Pointer and buttons: a widget set interactive receives OnHoverOver, OnHoverOut, OnPress, OnRelease (with inkPointerEvent.IsAction(n"click")), OnAxis through RegisterToCallback source e.g. pauseMenu.script:251-260. Game controllers hear everything through RegisterToGlobalInputCallback(n"OnPostOnRelease" | n"OnPostOnPress" | n"OnPostOnAxis" | n"OnPostOnRelative", …) (66, 22, 21 and 14 uses in 2.31) source.
• The cursor belongs to the layer: a menu layer shows the game's cursor (CursorGameController, whose ProcessCursorContext picks the cursor's look per context) source cyberpunk/UI/cursors/cursorGameController.script:111, 343. The HUD layer normally has none; input there comes as gameplay actions. Red Hot Tools makes the topmost layer (inkWatermarksLayer) interactive with its own game cursor (spawned from base\gameplay\gui\widgets\cursors\default_cursor.inkwidget, input context UINotifications) to pick widgets under the pointer source InkWidgetCollector.cpp:462-496. That is a native route to an ink "interact mode" without opening a menu; it needs RED4ext.
• Keys: Codeware's callback system delivers raw Input/Key and Input/Axis events, and Input Loader registers new input actions from XML; a script listens for input actions with GameObject.RegisterInputListener(listener, name) source Codeware wiki/Home.md (callback events), scripts/Callback/Events/KeyInputEvent.reds; 2.31 core/entity/gameObject.script:152.
• Text entry: Codeware's TextInput/HubTextInput components source scripts/UI/TextInput.

2.6 Performance

• Ink is retained: a static widget costs layout and draw only when invalidated; text changes re-shape one string. Changing text, tint or translation every frame on a few dozen widgets is what the game's own nameplates do [source; cost unmeasured].
• Controllers spawned from libraries load their .inkwidget resources (async where the Async spawn is used); script-built widgets load nothing but fonts and atlases already resident source.
• inkCacheWidget renders a static subtree once; the world map, scanner and damage digits use projected controllers so the engine does the per-frame placement source.
• The XF overlay: one native call (XFBridge_Hud, a string of a few hundred bytes) every sixth tick (about 5 Hz), and for nameplates three ProjectPoint calls plus one per visible head per tick [offline design; cost in game unmeasured].

3. Injecting into the standard screens

The general pattern: @wrapMethod the screen's controller OnInitialize (or the function that fills it), call the game first, then add widgets under this.GetRootCompoundWidget() or a named container; add a scenario event with @addMethod(MenuScenario_…) protected cb func On…() to switch to your own menu; tear down in OnUninitialize. Controllers below are source 2.31 unless noted; the "Mods" column names installed or cloned mods that hook them source.

Rule for every injected screen [source, from the bridge's crash]: UI code runs on the main thread inside the screen's lifecycle, so it is safe to call game systems while the screen is live, but a callback that outlives its screen (a delay callback, an animation proxy, a listener) must be released in OnUninitialize/OnDetach.

4. The HUD in detail

• Layers: the HUD layer (inkHUDLayer, a full-screen layer) holds entries, each a window with a name and a slot (hudEntryName, slotParams.slotID), spawned with its inkHUDGameController source Red Hot Tools InkWidgetCollector.cpp:207-221. UISystem.SetHudEntryForcedVisibility(entryName, visibility) forces an entry shown or hidden source core/systems/uiSystem.script:126.
• Showing and hiding: inkHUDGameController.ShowRequest/HideRequest with intro and outro animations (GetIntroAnimation, GetOutroAnimation) and context changes (combat, vehicles, scenes) source core/ui/baseControllers/hudGameController.script:20-108. The whole HUD hides in menus, photo mode and the creator.
• Positioning: HUD entries sit in safe-zone slots (the HUD safe-zone editor, gameuiHudSafezonesEditorGameController); a mod's widget under Root is placed by anchor and margin in the root's units (screen pixels hypothesis, §2.2).
• An XF HUD module can be: widgets under Root (built, Demo A); a wrapped vanilla entry's root (couples to that entry's visibility); or a true HUD entry (needs the HUD's entry list and an .inkwidget; not researched further).

5. World-space ink

5.1 Render-to-texture on a surface (terminals, screens, holograms)

• An entity carries a worlduiWidgetComponent (IWorldWidgetComponent): widgetResource (an .inkwidget library), itemNameToSpawn, sceneWidgetProperties, meshTargetBinding (the mesh and its UI material the window is drawn onto), screenAreaMultiplier, spawnDistanceOverride, tintColor, glitchValue, isEnabled; script reaches the spawned tree through GetWidget() and GetGameController() source 2.31 core/components/uiComponents.script:2-63, Codeware scripts/Base/Addons/IWorldWidgetComponent.reds, worlduiWidgetComponent.reds. Devices request it by name in OnRequestComponents (n"ui") source e.g. apartmentScreen.script:7, arcadeMachine.script:32. How a computer builds its screen and takes cursor input: terminals §2.
• The world layer (inkWorldLayer) keeps every such component's window; Codeware's GetWorldWidgets() lists their controllers source Codeware src/App/UI/inkSystem.hpp:40-60.
• Adding one to our own entity: either in the entity template (an archive change: the showroom build would add a component bound to a flat plate mesh with a UI material and a small .inkwidget), or at assembly time through Codeware's entity events (Entity/Assemble → AddComponent) source Codeware wiki "Components" ("add components at the right moment, for example when entity is assembled"). No mod was found doing the second for a world widget; Let There Be Flight's attempt is commented out source src/redscript/Extensions/VehicleObject.reds:8-20. Untested, the route of the pedestal labels' next step (design).

5.2 World-anchored, screen-space (nameplates, floating labels)

• Engine projection: a projected HUD controller registers inkScreenProjectionData (an entity and slot, or a static world position, a fixed world offset, distance adjustment) and gets OnScreenProjectionUpdate with the placed projections; ApplyProjectionMarginOnWidget positions a widget source orphans.script:44765-44775, 51626-51647; used by NPC nameplates, damage digits and mappins.
• Script projection: CameraSystem.ProjectPoint(worldPoint) with the active camera's transform, forward, right and up source orphans.script:26738-26740. Which screen space it answers in is not settled, so the caller detects it from a point straight ahead (the bridge's photo.frame does, tools/api/framing.ts) source. This is what Demo B uses: a tick behind the game's own projection by at most one UI tick [hypothesis: visible lag when the camera moves fast].

6. Map pins, markers and the compass

• Registering: MappinData { mappinType: TweakDBID, variant: gamedataMappinVariant, active, debugCaption, visibleThroughWalls, scriptData }; MappinSystem.RegisterMappin(data, position), RegisterMappinWithObject(data, object, opt slotName, opt offset), SetMappinPosition, SetMappinActive, ChangeMappinVariant, UnregisterMappin, GetMappins(targetType) source orphans.script:17783-17856. The game's drop points use Mappins.DropPointStaticMappin; mods use Mappins.DefaultStaticMappin source dropPointSystem.script:384-387; AMM Modules/util.lua (a FastTravelVariant marker over a spawned object), Sheng Noods Ramenshop.
• What a pin shows: its variant maps to an icon part (MappinUIUtils.MappinToTexturePart), a colour token (MappinToColor), a label key and a world-map filter group (GetFilterGroup(variant)) source cyberpunk/UI/mappins/mappinUtils.script. IMappin.GetDisplayName() answers the data's debugCaption for a runtime pin [source: mods rely on it; in game hypothesis for XF].
• Where it shows: world map (BaseWorldMapMappinController), minimap (MinimapPOIMappinController, MinimapDeviceMappinController), in the world (QuestMappinController, GameplayMappinController, which clamp to the screen edge, scale with distance, show distance and a name line), and tooltips (WorldMapTooltipController.SetData) source. The compass ribbon is the minimap's container; tracked pins drive the GPS path (GetManuallyTrackedMappinID, SetMappinTrackingAlternative) source.
• Custom icons: each controller's UpdateIcon sets the icon from the variant; a wrap that runs after it can swap the atlas and part (a mod's own .inkatlas) or hide the icon and draw ink instead; identify your pins by GetNewMappinID() or by a caption convention source Sheng Noods Ramenshop's wraps (its Nexus page credits Hepero for the map-icon script).
• Persistence: runtime pins belong to the session's mappin system [hypothesis: gone after a load; session 7 checks]; points of interest keep saved phase and variant (GetPointOfInterestMappinSavedState) source.
• Quest markers come from journal objectives (GetMappinFromObjective, quest mappins with phases); a real XF quest marker means a journal entry and quest phase (ArchiveXL), not a runtime pin source.

7. 3D in UI, video and render targets

• Paperdoll: inkInventoryPuppetPreviewGameController (an inkPuppetPreviewGameController: GetGamePuppet(), rotation by axis input, AnimFeature_Paperdoll for its pose) renders the puppet the in-game menu spawns for the "inventory" scene; gameuiInGameMenuGameController.OnPuppetReady(sceneName, puppet) hands it over and Equipment-EX dresses it there source entityPreviewGameController.script:2-80; Equipment-EX. The camera setup comes from gameuiPuppetPreview_SetCameraSetupEvent source Codeware addon of that name.
• Other 3D-in-UI: item previews (inkItemPreviewGameController.PreviewItem(itemID): weapons and clothes), crafting garment previews, the character creator's and gender selection's puppets, inkEntityPreviewGameController (vehicles), the 3D world map, the tarot preview source.
• A holographic V with per-limb damage [hypothesis, the route]: the paperdoll puppet is an entity, so its components can be changed after OnPuppetReady (Codeware GetComponents, meshAppearance + LoadAppearance(), or chunkMask); a hologram look needs mesh appearances with a hologram material (an XF archive adding appearances to V's body meshes through ArchiveXL, or extra mesh components per limb added to the puppet only) and per-limb states as appearance switches, since runtime material parameters are per resource, not per instance. The preview scene's lighting and post-process are its own, which suits an emissive hologram. First test: switch the puppet's body appearance in the inventory and confirm the gameplay V is unchanged.
• Video: inkVideo plays Bink (.bk2) in UI; BinkComponent plays video in the world; journal briefings and internet pages name videos source orphans.script:44099-44129; Codeware addons BinkComponent.reds, JournalBriefingVideoSection.reds.
• Dynamic images: inkImage.RequestSetImage(inkIconReference) loads icons asynchronously; the gallery shows screenshots through its own preview controller; inkCacheWidget renders ink into a cached texture. No script-reachable way to render an arbitrary camera into a widget was found [source; searched galleryfullpreview.script, preview controllers].

8. An XF ImGui host beside CET

The full study, with the component diagram, prototype plan and test card, is ImGui overlay feasibility (30 September 2026). Grades as above; [external] marks a public issue report or vendor document.

Verdict: feasible, recommended for development tools (dense, immediate-mode panels, live values, gizmos) beside, not instead of, the ink route for player-facing UI. Confidence is high for drawing, medium for interact mode and medium-low for frame generation and HDR until a session. First prototype: draw-only, off by default, refusing in HDR (about 4 days plus a session), then interact mode (about 3 days), then an own HDR-aware renderer and the panel kit (about 5 days).

9. The XF Runtime Bridge's ink demos (0.5.3, temporary test features)

Code: redscript/XFRuntimeBridgeInk.reds, redscript/XFRuntimeBridgePins.reds, native/src/core/InkUi.cpp in projects/xf-runtime-bridge.

Open questions

1. Is the HUD layer's Root in screen pixels (the overlay's uniform scale assumes it), and does a widget left under it survive a load?
2. Which layers stay visible in photo mode and menus: inkGameNotificationsLayer, inkWatermarksLayer? Is the watermarks layer drawn while it is not "active"?
3. Does an infinite looping ink animation keep ticking while the HUD is hidden, in menus and in photo mode?
4. Which screen space does CameraSystem.ProjectPoint answer in (shared with runtime access, question 9)?
5. Which controller draws a DefaultStaticMappin in the world for each variant, and where on its root does a centred child sit relative to the icon?
6. Do runtime mappins vanish with a load, and does RegisterMappinWithObject follow a Codeware static entity?
7. Can a worlduiWidgetComponent be added at assembly time to a spawned entity and draw on a plate mesh (§5.1)?
8. Does switching the inventory puppet's appearance affect only the preview (§7)?
9. For an XF ImGui host (§8): does the game register Raw Input with legacy messages off; does ForceCursor keep a second reason independent of CET's; do XF pixels ghost or flicker under DLSS or FSR frame generation; is the exit order of the two present hooks safe? (feasibility §9)

Related pages

Terminals, browser and arcade · Photo mode · Runtime access · Game crashes · In-game UI design · Mod ecosystem survey · Runtime bridge design · ImGui overlay feasibility