Hull Rupture Modules Database: Documented Roles and Kits

Read a module as a working system

A useful module entry separates its function from the kit used to obtain it. Construction requirements, available space, staffing and operating inputs are different questions about making that function useful aboard the ship. Keeping those fields distinct helps explain why acquiring a module option is not the same as having a completed producer contributing to the economy.

When comparing equipment, identify what each description actually measures. An output rate, a stored amount and an input requirement should not be treated as interchangeable statistics. Check the relevant tooltip and active conditions before comparing two values, because a bonus or staffing difference can change the meaning of the result you are looking at.

Despot's Chamber: random module kits

The September update gives Despot's Chamber a documented role in kit production. Humans assigned to the Chamber can generate random module kits, creating equipment options during the run. The important distinction is that this supplies kits rather than automatically completing every corresponding module or guaranteeing the exact equipment needed for a planned build.

Treat the result as an acquisition decision followed by a construction decision. Inspect what the new kit does, what it requires and whether the ship can support it. If the option does not fit the current arrangement, the developer also describes selling unwanted kits, so acquiring one does not oblige you to construct it immediately.

Bioreactor: humans become Fuel

The Bioreactor is documented as converting humans into Fuel. That connects the human supply with travel support, rather than making humans relevant only as workers assigned to ordinary production. Consider the conversion alongside the useful labor the ship needs, because the module's role belongs in the same management picture as staffing and movement.

The September demo update introduces automatic human assignment for converters, with the Bioreactor as the principal example. This is a dated feature description, not a release measurement of exact conversion rates or staffing requirements. Use the role to understand the system, then read the current in-game information before assigning numerical expectations to a particular setup.

Reproducer: human supply and interactions

The Reproducer supplies humans, making it relevant to the workforce and the broader use of humans as a resource. Its role should therefore be understood in relation to the other systems that depend on available people. A ship can have several promising modules while still needing to consider whether the human supply supports the arrangement being built.

Developer material also uses the Reproducer in an example where a modifier affects defense. That illustrates why a module reference needs interactions as well as a simple role label. Read the particular condition attached to the current equipment instead of assuming that every Reproducer automatically grants the same defensive effect in every run.

Mineral Generator: production and event conditions

The exploration devlog identifies a Mineral Generator as a producer of Minerals. It also describes an event modifier that changes output conditionally. The reference lesson is that the producer's ordinary role and a special interaction are separate pieces of information, so a modified output should not automatically be recorded as the module's universal base behavior.

If you compare an event-enhanced producer with another setup, account for that condition first. Identify the relevant modifier and the state in which the value was observed. This avoids turning a conditional reward into a numerical promise about every Mineral Generator, particularly when the source material does not supply a complete release output table.

Mystic Goo Generator: an event-related example

The developer's exploration material names the Mystic Goo Generator in connection with event-specific modifier rewards. That establishes an example of how exploration can interact with a module, rather than a complete entry for every cost, footprint or upgrade. Keep the documented relationship separate from details that would require a current tooltip or a different source.

When a reward refers to a module, inspect what the modifier applies to before deciding how it changes the build. A named interaction can be relevant to planning without establishing that the equipment is mandatory in every run. Use the specific condition to guide the decision, rather than infer an entire production tree from one event example.

Apply the release placement and identifier changes

The November FAQ states that modules can be built in any empty module slot in the full release. That replaces the demo rule requiring a completed neighboring module before a slot became usable. Reference entries and older construction advice should use the current general rule instead of repeating the earlier restriction without its version context.

The same FAQ says artifact icons and names changed between the demo and release. Some old icons can therefore refer to different artifacts in the full game. Use the current name, effect and version context when checking an interaction, rather than identify a bonus solely by a familiar image from a demo screenshot.

Compare entries without mixing conditions

For a numerical comparison, distinguish the game build, module level, assigned workers and active modifiers. Then identify whether the value concerns input, output or capacity. This is a practical reference method, not a claim that the collected material already provides every numerical field for every release module.

The June tutorial discussion also names Plasteel, Mineral, Isotope and Microchip as Uncommon-resource module categories. Keep that historical clarification separate from a complete release inventory. Use the shop guide for acquisition, the resource page for shortages and the construction page for placement, so each entry remains connected to the decision it actually helps you make.

Use an entry to answer a specific ship question

If you are comparing the Chamber and a resource producer, begin with the different roles each description establishes. One can provide random kit options, while another can address a material need; those outputs should not be treated as interchangeable improvements. Inspect what the current ship lacks before deciding which role deserves attention. This turns the reference into support for a decision rather than a list of names that appear equally useful simply because they are documented.

Apply the same care when an event modifies a named producer. Identify the condition and the module involved before treating the reward as a permanent increase to the ship's ordinary output. Record or read the current circumstances alongside any number you compare. Keeping roles, acquisition, construction and conditional behavior separate is what makes a limited set of verified entries more useful than an apparently complete table filled with values from incompatible builds or unsupported assumptions.

Related articles