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. It has to be a plain folder name, with no slashes, drive letters or characters a file name cannot hold; the server refuses a module whose id is not.
• 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, and the NPC records: archetypes, task plans, tactics and bots (see NPC Archetypes).
• 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.

Switching a module off switches off everything built on it. A module whose parent, or any ancestor, is off is not loaded, although its own switch stays where you left it; the Modules list marks that row (parent disabled).

A module can also be switched on and still not load. If the parent it names is not installed at all, or its manifest asks for a newer engine than the server is running, the server skips it and the Modules list says why beside its name: (needs module …) or (needs engine …). The engine requirement is the engine attribute on <module>, set as Requires Engine in the module editor's General section. Leave it blank unless your module depends on something a recent engine added.

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. Hydra's Directories section is where you add one.

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 specialized 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 flavor 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 unless you pick one of the package's versions in the Modules list. See Packaging Modules.