Modules

A module is a folder of content with a module.xml at its root. Modules are how everything ships — the base game is a module, the editor is a module, and your content is a module.

The manifest

<module id="RND-Horizons" guid="9105e3db-..." parent="Horizons" priority="10" version="1.0.0" active="true">
  <name>Horizons R&amp;D</name>
  <icon>images/mythric-icon.png</icon>
  <watermark>images/mythric-watermark.png</watermark>
  <description>...</description>
  <default-map />
  <encounters random="true" />
  <credits>...</credits>
</module>

Three attributes do the work:

• id — how everything else refers to this module. It is also the name used in the server's module list.
• parent — the module this one builds on. An empty parent means a root module.
• priority — the tie‑breaker between modules at the same depth in the tree.

Layering: who wins

Active modules are loaded in a specific order, and later loading overwrites earlier whenever two modules define the same thing. The order is:

1. Depth in the parent tree, shallowest first. A root module loads before its children; a child loads before its own children.
2. Priority ascending, among modules at the same depth. A module with priority 10 loads after one with priority 1, so the higher number wins.
3. Name, as a final tie‑break.

So a deeper, higher‑priority module has the last word. This is the mechanism behind everything modules can do: your module declares a vessel class with the same name as one in the base game and yours is the one that loads.

What can be overridden

Almost everything, and that includes files, not just records. The server keeps a merged index of every file every active module provides, resolved by path, and the same later‑wins rule applies. Put a file at the same path as a base game file and yours is served.

Which means a module can replace:

• Content records — vessel classes, components, factions, maps, missions, models, ordnance, commodities, names.
• Console screens — the screen registrations themselves, so a module can add stations or replace an existing one. This is how the Hydra editor's screens exist only while its module is enabled.
• Client code and styling — anything under Html, including widgets, stylesheets and templates.
• Art and audio — models, textures, sounds, music, video.

The practical consequence for anyone debugging content: the file being served is not necessarily the file you are looking at. When a change appears to have no effect, check whether a higher‑priority module provides the same path.

Enabling modules

Which modules are active is server configuration, not module configuration — the server's config lists every known module with an enabled flag, and Hydra's Modules section is the interface to that list. A module folder that is present but not enabled contributes nothing.

Modules can also live outside the main folder. The server takes a list of additional content directories, which is how you keep your own work in its own repository rather than inside the game's install.

What the module editor edits

Opening a module in Hydra gives you every collection it contains, grouped:

Most of these open a list; picking an item opens the specialised editor for it in a new tab. The module editor is the index, not the place you do detailed work.

Names and generators

The Names sections are easy to overlook and worth filling in. The game generates NPCs, callsigns, vessel names and star system names from these lists, so a module that supplies its own gets a consistent flavour everywhere without authoring anything individually.

Packaging

The Export section packages a module for distribution. A packaged module is served from inside its package rather than as loose files, and takes part in the same layering as any other module — but it is permanently read‑only, and an unpacked module of the same id beats it. See Packaging Modules.