KATA 6 OF 8 · UI LAYER

UI Mods with XUi

The good news: 7 Days to Die's entire interface - every window, the HUD, the toolbelt - is defined in XML, so you edit it with the exact XPath commands from Kata 2. The catch: it is its own dialect with its own file set, and V3.0 reworked it more than any other modding surface. This kata is the concept plus the V3.0 map, so your UI mods survive the jump.

What you'll build

A small, real HUD/window tweak driven by XPath into the XUi files - and a clear picture of the V3.0 changes that decide whether a UI mod ports in an afternoon or a week.

XUi is just (special) XML

The UI definitions live in the game's Data/Config/XUi/ and XUi_Common/ folders - windows.xml (the windows and their contents), the controls/templates file (reusable widget definitions), and styles.xml. A UI modlet puts same-named files in its own Config/XUi/ and uses XPath to patch them, exactly like items.xml.

The honest method, because XUi node names are deep and version-specific: open the game's XUi files, find the window or control you want by name, and write the XPath against what is actually there. Do not trust a path copied from an old guide - the UI tree changes between versions. The shape of an edit is ordinary:

<!-- in Config/XUi/windows.xml - illustrative: confirm the exact names in the game's files -->
<set xpath="/windows/window[@name='<the window you found>']//<the control>/@<attribute>">newValue</set>

That is why the classic UI mods (bigger backpack, custom HUDs, quest trackers) are "just" XPath - they resize windows, retheme colours, add panels, and toggle visibility. They are also why UI mods break on big updates: the names they target move.

The V3.0 overhaul (read this before porting)

V3.0 "Dead Hot Summer" shipped a new XUi system. From the official release notes, the changes that matter for a UI mod:

• A new XML binding system moves control logic from code into XML - more is now expressible in XUi without C#.
• controls.xml is renamed templates.xml, and the folder is renamed XUi_InGame. Mods targeting the old names stop matching.
• force_hide is removed in favour of visible - the standard way to hide/show an element changed.
• New view types (video, scrollbar, scrollview) and XML-controllable tweens.

So a V2.6 UI mod is not a recompile-and-go on V3.0 - it is real porting work against renamed files and a new binding model. This is the single biggest reason UI-heavy mods lag a version jump, and it is documented in our V3.0 mod compatibility guide. Build against the file names that match your target build.

When XUi is not enough: Quartz

For UIs that vanilla XUi cannot express - new widget types, data-bound lists - the community framework Quartz adds XUi widgets and controllers. You ship it as a dependency (it loads as its own mod), then your UI references its widgets. It is the bridge between pure-XML UI and full code mods (Kata 7).

Client-side, always

The UI is rendered on each player's machine, so UI mods are client mods - like assets, every player installs them, and EAC stays on (no code, no EAC-off). A server cannot push a HUD change to clients.

Test it

1. Make one small, reversible change first (recolour a panel, resize a window) so you can clearly see it worked.
2. Restart, open the affected screen. XUi errors are usually loud in the log with the offending window/control named.
3. If nothing changed, your XPath did not match - re-open the game's XUi file and confirm the exact name and nesting.

Common pitfalls

• Copied an old path. XUi names move between versions; a path from an A21 guide may not exist on V2.6, and almost certainly differs on V3.0. Always confirm against the live files.
• V3.0 renames. controls.xml → templates.xml, folder → XUi_InGame, force_hide → visible. Targeting the old names silently fails on 3.0.
• Forgot it is client-side. Players without the UI mod just see vanilla UI (or errors if it half-loaded). Ship it to everyone.