Skip to content

Auto Warz — Factory & Resource System Design

Document Type: System Design Version: 0.6 (Reconciled) Status: In Progress Last Updated: 2026-08-26 Vault destination: 01_Design Documents Author: Solo Developer Parent Document: [01_Master GDD](<./01_Master GDD.md>) Related Documents: [01_Technical Architecture Document](<../02_Technical Documents/01_Technical Architecture Document.md>) · [02_Scope & MVP Document](<./02_Scope & MVP Document.md>) · [[08_Economy & Progression Design]] · [01_Art Direction Document](<../03_Art & Audio/01_Art Direction Document.md>) Amended by: [00_Canonical Design Facts](<../04_Project Management/00_Canonical Design Facts.md>) · [24_Module System Design](<./24_Module System Design.md>) · [25_Power System Design](<./25_Power System Design.md>) · [20_Belt Logistics - The Router](<./20_Belt Logistics - The Router.md>) · [23_Port System Design](<./23_Port System Design.md>)

Table of Contents

Purpose of This Document

This document defines the complete design of the Factory & Resource System — the heart of Auto Warz and the entirety of the Phase 1 Early Access release. Every mechanic, building, resource, and production chain that exists on the Planet layer is specified here.

Design Philosophy

The Factory is the Story

In Phase 1, there is no war and no space. The factory IS the game. Every design decision must ask: does this make the factory more satisfying to build and optimise?

Everything Comes From the Factory

Even the bots that build the factory must be produced by the factory (after Genesis gets it started). Modules that improve buildings are crafted in the factory. Science Drives that accelerate research come from the factory. The factory is self-reinforcing.

Complexity Earns Its Place

Every new resource and machine must introduce a meaningful decision. Complexity for its own sake is cut.

Readable at Every Zoom Level

The factory must be comprehensible when zoomed out and detailed when zoomed in. The voxel/cube art style and colour coding make this achievable even with placeholder assets.

Resources

Resource Categories

Category Description Examples
0.7 2026-08-28 Resource model corrected. The category list is now marked as a reading aid rather than the data model: a resource carries substance and phase only (Canonical §12a). Removed the false claim that ResourceTier.FLUID makes fluids pipe-only — nothing enforces it, belts never check tier, and the split is structural. Chemical Gas divergence rescoped: retyping the .tres would fix nothing, since it rides belts because its definition is item-shaped.
Raw Extracted directly from the planet Metal Ore, Silicon Crystals, Biomass, Coal
Refined Produced from Raw resources Metal Plates, Silicon Wafers, Fuel Cells, Polymer Sheets
Components Produced from Refined resources Circuit Boards, Hull Plating, Drive Cores, Power Cells
Advanced Components Produced from Components Quantum Processors, Nano-Alloy Frames, Energy Conduits
Fluids Liquids and gases. Ride pipes because of their phase Coolant, Fuel, Liquid Metal, Chemical Solvent
Science Drives Research acceleration items Basic Drive, Advanced Drive, Quantum Drive
Bot Components Used to produce Construction Bots Bot Frame, Bot Core, Bot Cell

These categories are a reading aid, not the data model. A resource is described by two fields, substance and phase, and nothing else. See Canonical Design Facts §12a.

The categories above mix two unrelated ideas: Raw / Refined / Components / Advanced describe production depth, while Fluids describes phase. That is why Chemical Gas was mis-filed for so long — it is raw by origin and a gas, and a single category list forces a choice that has no right answer. Under the model it is simply chemical / GAS, true on both axes.

Production depth is derived from the recipe graph and is not stored. It was already wrong when it was: cmp_structural_frame is made from cmp_hull_plating, so components are made from components and the ladder does not hold.

Transport is derived from phase and is not stored either. Solids ride belts; liquids and gases ride pipes.

Phase 1 Resource List

Raw Resources

ID Name Colour Source
raw_metal_ore Metal Ore 🟤 Brown Mining Drill
raw_silicon Silicon Crystals 🔵 Blue Crystal Extractor
raw_biomass Biomass 🟢 Green Biomass Harvester
raw_coal Coal ⚫ Dark Grey Mining Drill (variant)

Refined Resources

ID Name Produced From Building
ref_metal_plate Metal Plates Metal Ore Smelter
ref_silicon_wafer Silicon Wafers Silicon Crystals Refinery
ref_fuel_cell Fuel Cells Chemical Gas + Coal Chemical Plant
ref_polymer Polymer Sheets Biomass + Chemical Gas Chemical Plant
ref_copper_wire Copper Wire Metal Ore (variant) Wire Extruder

Components

ID Name Produced From Building
cmp_circuit_board Circuit Boards Silicon Wafers + Copper Wire Assembly Machine
cmp_hull_plating Hull Plating Metal Plates + Polymer Sheets Press Machine
cmp_power_cell Power Cells Fuel Cells + Circuit Boards Assembly Machine
cmp_drive_core Drive Cores Metal Plates + Copper Wire Assembly Machine
cmp_structural_frame Structural Frames Metal Plates + Hull Plating Press Machine

Advanced Components (research unlocked)

ID Name Produced From Building
adv_quantum_processor Quantum Processor Circuit Boards + Silicon Wafers + Power Cells Advanced Assembly
adv_nano_alloy Nano-Alloy Frame Structural Frames + Chemical Solvent Advanced Press
adv_energy_conduit Energy Conduit Copper Wire + Power Cells + Polymer Sheets Advanced Assembly

Science Drives (consumed by Research Labs)

ID Name Produced From Unlocks
sci_basic_drive Basic Science Drive Metal Plates + Circuit Board Tier 1–2 research
sci_advanced_drive Advanced Science Drive Power Cells + Silicon Wafers + Polymer Tier 3 research
sci_quantum_drive Quantum Science Drive Quantum Processor + Energy Conduit Tier 4 research

Bot Components (used to produce Construction Bots)

ID Name Produced From Building
bot_frame Bot Frame Metal Plates + Hull Plating Press Machine
bot_core Bot Core Circuit Boards + Drive Core Assembly Machine
bot_cell Bot Power Cell Power Cells + Fuel Cells Assembly Machine

Fluids

ID Name Source Notes
fld_coolant Coolant Water Extractor Pipes only
fld_fuel Liquid Fuel Chemical Plant Pipes only
fld_liquid_metal Liquid Metal Smelter (high temp) Insulated pipes only
fld_chemical_solvent Chemical Solvent Chemical Plant Pipes only
raw_chemical_gas Chemical Gas Gas Pump Pipes only. See the data divergence note below.

The raw_ prefix on Chemical Gas is a legacy artefact of its original misclassification. It is the real filename (data/resources/raw_chemical_gas.tres); renaming it is a data change that would touch every recipe referencing it, so the id stands and this note explains the mismatch.

⚠️ The data currently disagrees with this, and the data is wrong.

Chemical Gas rides belts in the running game. The cause is not its tier. Nothing enforces the belt/pipe split via tier — belts never check it — so retyping the .tres would change nothing. Chemical Gas rides belts because it has an item-shaped definition and lives in inventory. Under the resource model it is chemical / GAS (Canonical §12a), and the real work is moving it onto the fluid path.

The fix is blocked, and not by choice of priority. RecipeDefinition.inputs is item-only, BuildingInstance._has_recipe_inputs() reads inventory only, and PipeConnector.gd records that receive_fluid() does not exist yet. No building can receive fluid as a production input at all. Retyping the .tres to FLUID today would not move Chemical Gas onto pipes, it would break both recipes that consume it (ref_fuel_cell, ref_polymer) with no working path to replace them.

Unblocked by the M2.3.1 fluid-input path. Tracked in AGENTS.md under Known Code/Design Divergences. Do not resolve this by changing the design to match the data.

⚠️ Implementation note — corrected 2026-08-28. Earlier versions said fluids use ResourceTier.FLUID = 4 and that "this tier is pipe-only". Nothing enforces that. Belts never check tier, or any fluid flag. The separation is structural: fluids move through fluid_inventory and pop_fluid_output(), items through inventory and pop_output_item(), and the two paths simply never meet.

ResourceTier is being removed entirely (Canonical §12a). A resource carries substance and phase; transport follows from phase, in code, not from a field.

RecipeDefinition — Multi-Input Format

As of M2.1, RecipeDefinition uses a inputs: Dictionary field instead of a single input_resource_id + input_amount. All recipes now support any number of input resources.

# RecipeDefinition.gd
@export var inputs: Dictionary  # { "resource_id": amount, ... }
@export var output_resource_id: String
@export var output_amount: int
@export var processing_time: float  # seconds

# Example — Circuit Board recipe
# inputs = { "ref_silicon_wafer": 1, "ref_copper_wire": 2 }
# output_resource_id = "cmp_circuit_board"
# output_amount = 1

BuildingInstance._has_recipe_inputs() and _consume_recipe_inputs() iterate all entries in inputs. All 9 production chain recipes shipped in M2.1 use this format.

Recipe Selection (RESOLVED)

A building's recipe is chosen by the player in the Building Detail Panel, instantly, and it is step 2 of three in configuring a building ([23_Port System Design](<./23_Port System Design.md>) §5.1b: place, set recipe, configure ports). Ports cannot be configured before it, because what a port may accept is undefined until the building knows what it makes.

The mechanism already exists in code: BuildingInstance.active_recipe_index indexes BuildingDefinition.accepted_recipe_ids. What is missing is any way for the player to move it, and any statement of what moving it does.

Three kinds of building, three presentations

The control is not uniform, because the underlying data is not.

Building accepted_recipe_ids Panel shows
Multi-recipe — Assembly Machine, Advanced Assembly (3 each), Press Machine, Advanced Press (2 each) Several A selector. This is the only case with a choice to make
Single-recipe — Smelter, Refinery, Chemical Plant, Wire Extruder Exactly one The recipe as a label, not a dead control
Extraction — Mining Drill, Water Extractor, Gas Pump, Biomass Harvester Empty What it extracts, from output_resource_id. No recipe concept applies

Always show what the building makes; only offer a control where there is a choice. A greyed-out dropdown on a Smelter teaches the player that the control is sometimes dead, which is worse than not showing one. The label still appears in all three cases, so the panel answers "what does this do" consistently.

Changing a recipe

The change is instant, like port configuration ([23_Port System Design](<./23_Port System Design.md>) §9a). No Genesis task, no materials, no travel. Consistency matters here: the panel would otherwise apply one of its two settings immediately and queue the other.

What Happens
A job in progress Abandoned. Inputs already consumed are lost. The panel warns first, and only when a job is genuinely mid-production
Buffered inputs the new recipe cannot use Kept, never voided. They stay in the building's buffer and count against its capacity
Auto-enabled ports Follow the new recipe. Their filter is empty and they only ever accepted what the recipe wants ([23_Port System Design](<./23_Port System Design.md>) §5.1c)
Explicitly filtered ports Left alone and surfaced. A filter the new recipe cannot use is flagged in the panel, never silently cleared — the player set it deliberately

Why lost rather than refunded. Returning partially consumed inputs means deciding what happens when the buffer has no room for them, which is a second rule to cover an edge the player created on purpose. Canonical §7a forbids silently voiding things; a warned, player-initiated cancellation is neither silent nor transport. One sentence beats a rule with an exception.

Stranded stock must be drainable

Keeping unusable inputs raises a real problem: a building whose input buffer is full of the old recipe's ore can never start the new one, and pop_output_item() only ever pops the recipe's output, so nothing removes it.

An OUTPUT port carrying an explicit filter pushes that resource out of the building, whether or not it is the current recipe's output. This gives port filters a second job and makes stranded stock the player's problem to route rather than a soft-lock.

The panel shows unusable buffered stock distinctly from usable inputs, so the player can see why the building is idle rather than guessing.

Not decided here

Which recipes a building may hold is data, not design. Adding or removing entries in accepted_recipe_ids is a balance question per building, and research gates the recipe, not the selector — a building offers only recipes the player has unlocked, so the selector's contents grow over the session.

Production Chains

Chain Depth: 4 Tiers

TIER 1 — Extraction (Raw)
Planet surface → Extraction buildings → Raw resources

TIER 2 — Refinement
Raw → Smelters/Refineries/Chemical Plants → Refined resources

TIER 3 — Assembly (Components)
Refined → Assembly/Press Machines → Components

TIER 4 — Advanced Assembly
Components + Fluids → Advanced Assembly → Advanced Components
(Used for Science Drives, Bot Components, win conditions)

Example Chain: Quantum Processor

Metal Ore → Smelter → Metal Plates ──────────────────────────┐
                                                               ├→ Press → Hull Plating
Biomass → Chemical Plant → Polymer ─────────────────────────┘

Silicon → Refinery → Silicon Wafers ──┐
                                       ├→ Assembly → Circuit Board ──┐
Metal Ore → Wire Extruder → Copper ───┘                              │
                                                                      ├→ Advanced Assembly → Quantum Processor
Chemical Gas → Chemical Plant → Fuel Cells ──┐                       │
                                              ├→ Assembly → Power Cell┘
Circuit Boards ───────────────────────────────┘

Buildings

Building Categories

Category Purpose Phase
Extraction Pull raw resources from the planet Phase 1
Processing Convert resources Phase 1
Logistics Move resources Phase 1
Power Generate and distribute power Phase 1
Storage Buffer resources Phase 1
Research Consume Science Drives, generate RP Phase 1
Modules Craft modules for building upgrades Phase 1
Construction Produce and manage Construction Bots Phase 1
Defence Protect base from alien attacks Phase 1
Launch Send resources to Space layer Phase 2

Building State Machine

IDLE → INPUT_WAITING → PROCESSING → OUTPUTTING → IDLE
                              ↓
                         OUTPUT_FULL (stalled)

Any state → NO_POWER (power grid cannot supply)
Any state → DISABLED (manually disabled by player)

Phase 1 Building List

Extraction Buildings

ID Name Output Power Size
building_mining_drill Mining Drill Metal Ore / Coal 10 PU 2×2
building_crystal_extractor Crystal Extractor Silicon Crystals 15 PU 2×2
building_gas_pump Gas Pump Chemical Gas (fluid) 20 PU 2×3
building_biomass_harvester Biomass Harvester Biomass 8 PU 3×3
building_water_extractor Water Extractor Coolant (fluid) 12 PU 2×2

Processing Buildings

ID Name Power Size
building_smelter Smelter 30 PU 3×3
building_refinery Refinery 25 PU 3×4
building_chemical_plant Chemical Plant 35 PU 4×4
building_wire_extruder Wire Extruder 15 PU 2×3
building_assembly_machine Assembly Machine 40 PU 3×3
building_press_machine Press Machine 35 PU 3×4
building_advanced_assembly Advanced Assembly Machine 60 PU 4×4
building_advanced_press Advanced Press 55 PU 4×5

Storage Buildings (RESOLVED)

Two storage buildings, one per phase. There is no third.

ID Name Holds Capacity by Mk Footprint
building_silo Silo Solids. One substance, never mixed 500 / 1000 / 2000 units 1×1
building_tank Tank Liquids and gases. Single-fluid 1000 units —

The Smart Buffer is deleted, not deferred. It existed to hold a configurable filter, and that reason has been removed twice over:

  1. Ports filter. Per-port resource filtering arrives at Base Mk3 ([23_Port System Design](<./23_Port System Design.md>) §5.4), so filtering happens at the connection rather than in a dedicated building.
  2. Every Silo is already filtered by its contents. A Silo holds one substance and never mixes, so "a store that only accepts one thing" describes the ordinary Silo. The Smart Buffer was a special case of the general rule.

A building whose only distinguishing feature is now standard is not a building.

Capacity scales by Mk rather than by building count. 500 at Mk1 keeps the value storage_chest.tres already ships, and doubling per level is legible without a table. The small-versus-large decision the two buildings used to express is now the Mk track, which is one system instead of two.

Capacity is a number of units, not of items. Each substance carries a unit_size, so a Silo of capacity 500 holds fewer bulky goods than dense ones (Canonical §7). Those unit_size values do not exist yet — tracked as OI-299 — so the curve above is a capacity in units that will only become concrete when they do.

Mk does not raise how many substances a Silo holds. It stays one at every level. The fill window shows a level tinted by its substance, and a window cannot display a mixture, so a multi-substance Mk3 Silo would have to abandon the readout that gives the Silo its identity. Mk buys depth, not variety; sorting is the Router's job.

One port per face is enough. A 1×1 Silo has four ports, and at Base Mk1 each moves 1 item/sec, matching a Basic Belt exactly — so a Silo can be served by four belts at full rate on all four sides. Base Mk raises it to 2 and then 4 per port, which is precisely the case §5.4 of the port document calls out: without a separate base track a Mk3 Silo would be "a deep buffer with a narrow neck". It is not.

Storage Roles — the ChestMode system

Shipped behaviour. Undocumented anywhere in the vault before this entry.

BuildingInstance carries chest_mode, meaningful only for STORAGE buildings and ignored for all others:

Value Intent
UNASSIGNED Default. Accepts deposits from mining and supplies builds.
STORE Mining only. Genesis deposits mined ore here.
BUILD Build supply only. Genesis fetches construction materials from here.

What it is for: letting a player dedicate storage. Without it, every storage building is both a mining dump and a construction depot, so the depot Genesis draws build materials from slowly fills with raw ore. STORE and BUILD separate the two jobs.

Current implementation status: inert.

chest_mode is declared and defaults to UNASSIGNED, and nothing ever assigns it — no UI, no Genesis task, no build-menu control. It is read in two places in WorldScene.gd, and both are dead in practice:

  • WorldScene.gd:1081 skips BUILD chests when choosing a deposit target. Since no chest is ever BUILD, this never skips anything.
  • get_chests_sorted_by_distance() accepts a mode_filter argument, but both call sites pass -1, which disables filtering.

It is also not serialized, so the value would not survive a save even if something set it. Tracked in AGENTS.md under Known Code/Design Divergences.

Being renamed by the port refactor. ChestMode becomes StorageRole. The word "chest" is deprecated everywhere: solids go in a Silo, fluids and gases in a Tank (Canonical Design Facts §7). StorageRole must survive a building upgrade untouched (§4).

Now Becomes
ChestMode.UNASSIGNED StorageRole.UNASSIGNED — both jobs, the default
ChestMode.STORE StorageRole.DEPOSIT — Genesis deposits mined ore here
ChestMode.BUILD StorageRole.CONSTRUCTION — Genesis draws build materials from here

The roles are named for what Genesis does with the building, which is the only thing they control. That makes DEPOSIT and CONSTRUCTION symmetrical, and leaves UNASSIGNED correctly meaning neither has been chosen. An earlier draft of the canonical page named the middle value GENERAL; that was replaced in Canonical Design Facts v1.1, because GENERAL read as the broad everything role — which is what UNASSIGNED already means — and left the narrow mining-deposit role with no name at all.

Research Buildings

ID Name Output Power
building_research_lab Research Lab RP (from Science Drives) 20 PU
building_advanced_lab Advanced Lab RP (faster) 40 PU

Module Crafting Building

ID Name Output Power Notes
building_module_crafter Module Crafter All module types + the four Upgrade Kits 30 PU Dedicated building for crafting modules and Mk upgrade kits

Construction Buildings

ID Name Output Power Notes
building_bot_bay Construction Bot Bay Construction Bots 25 PU Unlocked via Bot Programming II research
building_bot_depot Bot Depot — 10 PU Stores idle bots, acts as hub

Defence Buildings

ID Name Function Power
building_turret_basic Basic Turret Shoots nearby aliens 15 PU
building_turret_laser Laser Turret High-damage 40 PU
building_wall Wall Segment Blocks alien pathing 0
building_gate Gate Passable wall opening 0
building_radar Radar Tower Reveals alien positions 10 PU
building_unit_spawner Unit Spawner Produces deployable units 20 PU

Power Buildings

ID Name Output Notes
building_coal_generator Coal Generator 100 PU Consumes raw_coal at 0.5/sec. The reference source — all other outputs are multiples of it
building_fuel_generator Fuel Generator 250 PU Consumes fld_fuel at 0.5/sec (pipe)
building_solar_panel Solar Panel 50 PU peak (day only) Free but intermittent. Cosine day/night curve, zero at night
building_accumulator Power Accumulator Stores 500 PU·s Charge and discharge capped at 100 PU, 90% round trip. PU·s, not PU — storage is energy, not a rate
building_biomass_burner Biomass Burner 40 PU raw_biomass (solid belt). Starter tech: teaches the fuel-logistics burden immediately and cheaply. Fed by the Biomass Harvester (wild) or the Biomass Farm (cultivated).
building_wind_turbine Wind Turbine 60 PU base No fuel. Location-dependent output, and the one building here with decided numbers: surface 70%, Sky L1 90%, Sky L2 110%, Sky L3+ 130%, Rogue 0% (no atmosphere), Ocean 80% (calm). Specified in [06_Vertical Layers & Core Power System](<./06_Vertical Layers & Core Power System.md>).
building_geothermal_tap Geothermal Tap 300 PU No fuel. Draws the Geothermal Energy Pool, scales with depth. Favours Lava and Chthonian planets.
building_nuclear_reactor Nuclear Reactor 600 PU Uranium (solid) + cooling water (pipe). Produces nuclear waste requiring storage. ⚠️ Blocked — see the fluid-input divergence under Resources → Fluids.
building_core_power_station Core Power Station 40–2240 PU, CER-derived No fuel. One per planet. Depth-gated via Deep Core Tap research. Favours Chthonian and Lava.

Output, fuel rate, energy per item and planet-type reasoning: [25_Power System Design](<./25_Power System Design.md>) §5.1 and §5.1a, which is the authority for all of them. Figures at generation_scale = 1.0.

Cultivated organics are specified in [27_Organic Farming & Biomass Design](<./27_Organic Farming & Biomass Design.md>). Two families, Biomass Farm and Algae Farm, each built as a Control Hut plus Bays. The Biomass Burner's fuel is raw_biomass, which has existed since Phase 1 and is already load-bearing through Polymer Sheets. The previously promised Wood, organic carbon and bio-polymer crops were deleted rather than defined: two duplicated raw_biomass and the third was a naming error.

⚠️ 25_Power System Design §5.1 marks Geothermal Tap and Core Power Station "already specced". They were not specced here — both had zero mentions in this document until this entry. A document asserting something is done is what stops anyone checking, so the claim is recorded rather than repeated.

Waste & Environmental Buildings

Specified across [26_Pollution, Waste & Organic Systems Design](<./26_Pollution, Waste & Organic Systems Design.md>), [20_Belt Logistics - The Router](<./20_Belt Logistics - The Router.md>) §3b.2 and Canonical Design Facts §7a and §10, and absent from this document until now. No footprint, power figure or recipe quantity was ever decided for any of them. Every unspecified value below is marked TBD and tracked in docs/open-items.md, area pollution / power. None has been guessed.

Two power figures are now set. The Incinerator and Air Scrubber draws come from [25_Power System Design](<./25_Power System Design.md>) §9.3, which is their authority. The remaining TBDs are untouched.

ID Name Function Inputs Outputs Power Size
building_incinerator Incinerator Deliberate disposal of surplus items Any item Air pollution, plus partial heat recovery as power 20 PU TBD
building_recycler Recycler Treats solid waste Solid waste TBD TBD — "significant" TBD
building_water_treatment Water Treatment Treats contaminated water before discharge Contaminated water (fluid) TBD TBD — "significant" TBD
building_air_scrubber Air Scrubber Neutralises local air pollution Power only TBD 12 PU TBD
building_soil_remediation Soil Remediation Slowly reduces ground contamination in a zone Power + organic input from farms Reduced ground contamination TBD — "power-hungry" TBD

Category is undecided. There is no Environmental or Waste entry in Building Categories, and whether these join Processing or need a new category was never settled. The heading above is organisational and makes no category claim.

Incinerator. Costs power and produces air pollution, where open dumping produces ground contamination instead. The player chooses which pollutant to create; neither is free. Heat recovery is always a fraction of the item's embodied energy, never more — otherwise manufacturing items purely to burn them becomes optimal. Net-negative or roughly break-even in normal use. Genuinely combustible materials already have dedicated generators and should not be routed here. It answers "what do I do with 40,000 spare stone" with a deliberate exit that still costs something.

Recycler. The Treat option for solids in the three-way Store / Treat / Dump choice (Pollution §5). Ties waste to the power system: the clean answer costs electricity, so choosing it means first solving generation.

Water Treatment. The Treat option for contaminated water, and the direct parallel to the Air Scrubber. Prevents contamination rather than reversing it. ⚠️ Blocked — takes a piped fluid as a production input; see the fluid-input divergence under Resources → Fluids.

Air Scrubber. Consumes power to neutralise local atmospheric pollution. Works on any level and is essential underground, where pollution otherwise only ever rises until the level becomes unusable — a dead end rather than a decision. It does not vent pollution elsewhere. Pollution never travels between levels; the scrubber neutralises it in place.

Soil Remediation. The only reversal tool for ground contamination, and the reason a poisoned planet is recoverable rather than permanently ruined.

⚠️ Remediation must be far slower than contamination. If it cleared contamination at anything near the rate the player creates it, dumping becomes consequence-free with a delay and the entire waste decision collapses into a chore.

Consumes an organic input from farms, which gives farming a second customer beyond fuel and polymers and means restoring a planet requires having built the renewable side rather than throwing power at the problem. Must be run per level, because contamination leaches downward: cleaning the surface does not clean the levels beneath, and the deepest level is hardest because it is the sink where everything accumulated.

Logistics Systems

1. Conveyor Belts

  • Primary short-to-medium range logistics
  • Directional, placed one tile at a time
  • Items are visual representations — simulation tracks counts not positions
ID Name Speed Research Required
belt_basic Basic Belt 1 item/sec None
belt_fast Fast Belt 2 items/sec Logistics I
belt_express Express Belt 4 items/sec Logistics II

Belt Special Pieces

Two, not four.

Piece Status
Router 1×1 building, four ports. Replaces Splitter, Merger and Filter Splitter.
Underground Belt A belt variant, not a routing decision. Unchanged.

Splitter, Merger and Filter Splitter no longer exist as separate buildings. They were the same object with different port configurations, so they are collapsed into one.

The Router

Authority: [20_Belt Logistics - The Router](<./20_Belt Logistics - The Router.md>). This section summarises it. Where the two disagree, that document wins.

1×1 building. Four ports. Each configurable as INPUT or OUTPUT, with an optional filter. Its behaviour is entirely a consequence of how its ports are set:

Configuration Behaves as
1 in, 3 out Splitter (3-way)
1 in, 2 out, 1 disabled Splitter (2-way)
3 in, 1 out Merger
Any, with filters set Filter splitter
2 in, 2 out Balancer

3-way and 4-way splitting come free. No chaining required.

Capability arrives through Mk, not research

Machine Mk Capability When the player needs it
Mk1 Even split and merge only. Nothing to configure but direction. Immediately
Mk2 Priority, in and out As soon as they have storage
Mk3 Filters and ratio splitting Once belts carry mixed goods

Base Mk raises throughput, as on every building. A new player meets a Router that does one obvious thing, and depth arrives when they hit a problem that needs it. "Feed my smelters before my storage" is a problem players meet almost immediately, which is why priority comes before filters.

Priority is a waterfall, and it is the overflow mechanic

Priority and ratios are different tools, not variants of one. A ratio is proportional: 70% here, 30% there, always. Priority is a waterfall: fill output 1 completely, overflow to output 2, then 3. Priority works on inputs as well as outputs.

Because priority already provides overflow behaviour, there is no separate Overflow port mode. A filtered output that backs up simply loses its turn and the item waterfalls to the next priority.

Ratios are set explicitly (70/30, 50/25/25), never inferred from priority flags.

Backpressure

If every output is backed up, the Router stops and the backpressure propagates upstream. Nothing is ever silently voided. Backpressure is what makes a factory legible: something upstream stops, the player traces the belt forward, and finds the blockage.

Output-full and input-starved must never share a signal. Output-full is success — consumers satisfied, storage full, nowhere left to put things. Input-starved is failure. Priority routing makes full storage a normal steady state, so if the two shared a signal a healthy factory would sit permanently in alarm.

Deliberate disposal is the Incinerator — specified in [20_Belt Logistics - The Router](<./20_Belt Logistics - The Router.md>) §3b.2 and Canonical Design Facts §7a, and not yet given a building entry, recipe or unlock path in this document. It costs power and produces air pollution, where open dumping produces ground contamination instead; the player chooses which pollutant to create. Incinerator heat recovery is always a fraction of the item's embodied energy, never more, or manufacturing items purely to burn them becomes optimal.

The Building Detail Panel shows live throughput per port, so a player can see that an output configured for 70% is only receiving 40% because the upstream belt is starved.

2. Drones

Full specification in [21_Drone Logistics Design](<./21_Drone Logistics Design.md>).

The carrier that needs no built path: belts need a corridor, rail needs track, catenary needs wire, and a drone needs only two endpoints. Routes are pairs — one source, one destination — with a shared reserve in a pit for demand spikes. Demand pulls; nothing is pushed.

A drone module in a roof slot is the pickup point, dropoff point, dock, charger and buffer for the building it serves. Drones carry cache boxes, one substance per box and several boxes per drone, and cannot fly underground.

3. Pipes (Fluids & Gases)

  • Fluids and gases cannot travel on belts — pipes only
  • Flow from higher pressure (full) to lower pressure (empty)
  • Fluid Pump required for runs > 20 tiles
ID Name Notes
pipe_basic Basic Pipe Standard fluids
pipe_insulated Insulated Pipe Hot fluids (Liquid Metal)
pipe_underground Underground Pipe Passes under buildings/belts
pipe_pump Fluid Pump Boosts flow for long runs

4. Trains (Long Distance)

  • Bulk transport across the planet
  • Run on player-placed rail tracks between Train Stations
  • Host-configured schedule: station order, wait conditions
  • Require Rail Signals at junctions to prevent collisions
  • Consume Fuel Cells

Power System

Power is strictly required. A building with no supply does not run. Under a shortfall — supply present but insufficient — buildings shed progressively under hysteresis rather than cutting out; see Power Flow below.

Power Distribution

Authority: [25_Power System Design](<./25_Power System Design.md>). This section summarises it. Where the two disagree, that document wins.

Power has three tiers: Generation → Transmission → Distribution.

Distribution (baseline, always available)

Every building has an integrated power transmitter with a short range. Buildings within range of each other auto-connect to form a grid, so a compact starting factory needs no player thought at all. No early friction.

Power Poles extend distribution across a site, at the same voltage, with no loss. They are ordinary buildings, placed like any other.

Poles and integrated transmitters coexist. Earlier versions of this document stated that there are "no separate power poles"; that is removed. Poles exist at the distribution tier, and the integrated-transmitter model is retained alongside them, not replaced by them.

Distribution reach is load-dependent. It contracts as circuit load rises, so a pole network that comfortably reaches a distant outpost at low load will brown out at the edge as the factory grows. Poles extend the network; they do not defeat voltage drop. Players can use distribution for long runs — it simply becomes lossy and unreliable at scale, which is the intended lesson rather than a prohibition.

Connection range is a backend tuning value, not a player setting. It is a developer number for playtest balancing and lives in the single PowerTuning resource. It must never be exposed as a per-building player control, in a settings panel or anywhere else. See [25_Power System Design](<./25_Power System Design.md>) §2.3 and §4b.

Multiple disconnected grids can exist on the same planet, each operating independently. Per-grid health — surplus or deficit, sources, top consumers, estimated time to failure — is shown in the right flap Power tab ([17_HUD Panel Flap](<./17_HUD Panel Flap.md>) Tab 2). The full-screen Factory Overview (F) that earlier versions of this document referenced was removed in [09_UI-UX Design Document](<./09_UI-UX Design Document.md>) v0.6; its data now lives in the right flap.

Generator Building
      ↓ integrated transmitter — short range, automatic
Neighbouring buildings → auto-connected
      ↓ Power Poles — same voltage, no loss, extends reach across a site
Site-wide distribution grid
      ↓ Transformers + lines on Pylons — research path
Distant grid — long range, voltage-dependent loss

Transmission (research path)

The answer to "my ore field is too far to reach." A step-up transformer at the generation end, a step-down transformer at the consumption end, and transmission lines carried on Pylons between them. A higher voltage tier means lower loss per tile but requires a matched transformer pair, and each transformer imposes a small fixed loss.

The game must remain winnable without transmission. Research is path-choice, not a timeline. A player who never takes that branch has chosen to move fuel instead of moving power, and pays for it continuously in belt throughput and factory footprint.

Power Flow (Per Tick)

  1. Sum all generation on each grid
  2. Sum all draw on each grid
  3. Generation ≥ draw → all buildings run normally
  4. Generation < draw → accumulators discharge to cover the shortfall
  5. Shortfall persists → buildings shed by priority order, staged across several ticks, never all at once
  6. A shed building returns only when the grid would still be healthy with it running — never merely because a threshold has been crossed

Shedding requires hysteresis, and hysteresis by itself is not enough.

[25_Power System Design](<./25_Power System Design.md>) §4a is the authority and carries the whole mechanism: two independent triggers (grid deficit, a quantity, and local undervoltage, a ratio), stage sizing, shed and restore ordering with tie-breaks, and the accumulator interaction. The values and the invariant they must preserve are in §4b, and all of them live in the single PowerTuning resource.

The one point worth repeating here, because it contradicts the obvious reading: setting the recovery threshold above the shutdown threshold does not on its own stop the flicker. A building whose own draw is what breaks the circuit still oscillates, at the stagger period rather than the tick rate. Restoration must test the state that would exist after the building returns.

Power Priority System

  • Available after researching Power Management
  • Before this research, buildings shed in a fixed default order
  • After research: player can set per-building priority (1–5 scale) in the building detail panel
  • Default priority order (lowest → highest): Research Labs → Drones → Storage → Processing → Extraction

Priority sets the order in which buildings shed. It does not change the staged, hysteresis-governed manner in which they shed.

Module System

Modules are crafted items installed into fixed slots on a building's roof. They add capability to a building: power distribution, efficiency, productivity and status readout.

Authority: [24_Module System Design](<./24_Module System Design.md>). This section summarises it. Where the two disagree, that document wins.

Module Slots

Slots are at fixed positions on the roof, not freely placed. A module's position carries no mechanical meaning, so free placement would cost a per-building roof grid, footprint-dependent validation and art that must read correctly with modules anywhere, in exchange for nothing the player can use.

Every building has at least one slot from the moment it is placed. Slot count is not researched. It is derived from footprint size and Machine Mk level:

Size class Cells Base slots Example buildings
Small 1–4 1 Silo, Mining Drill, Solar Panel, Accumulator
Medium 6–9 2 Smelter, Gas Pump, Assembly Machine, Research Lab
Large 12–16 3 Refinery, Press Machine, Chemical Plant, Advanced Assembly
Huge 20+ 4 Advanced Press

Mk bonus: +1 slot per Machine Mk level above Mk1.

Machine Mk1 Machine Mk2 Machine Mk3
Small 1 2 3
Medium 2 3 4
Large 3 4 5
Huge 4 5 6

Range is 1 to 6. Slots come from Machine Mk, not Base Mk — Base Mk governs port throughput and filtering ([23_Port System Design](<./23_Port System Design.md>) §5.4). This gives Mk levels real mechanical weight rather than a flat stat bump.

No Stacking

Modules do not stack, and stacking order carries no meaning. Earlier versions of this document described modules as cubes stacked into a tower, with effects applying bottom to top. That model is removed. Slot count by Mk and stack depth by Mk are two mechanisms doing one job; slots are simpler to build, to explain, and to read from above.

There are no combination bonuses. Module pairings have no emergent effects.

Module Types (Phase 1)

Module Effect Unlock
Efficiency Reduces power draw Available from the start
Power Pole Distributes power over an area from the building roof Research — Module Technology I
Status Upgrades the free base-ring status to detailed / remote readout Research — Module Technology II
Productivity Increases output per input Research — Module Technology III

Efficiency is available from the start. Every building has a roof slot from the moment it is placed, so gating all four module types would leave a visible empty slot with nothing that could fill it for the whole early game. Research adds capability; it never switches the system on. See [24_Module System Design](<./24_Module System Design.md>) §3.1.

Open items for this document are tracked in docs/open-items.md.

Module tiers plus building tiers is a large combinatorial balance surface for a solo developer. The Basic / Advanced / Quantum module tiers described in earlier versions of this document are not confirmed design.

Power Poles

Power distribution is area-based, not port-based. Ports carry ITEM and FLUID only.

State Placement Unlock
Default Ground-placed pole, standalone building Available from start
Upgraded Roof-mounted module on an existing building Research-gated

Moving a pole onto a roof is a genuine spatial upgrade — reclaimed ground, tighter factories — rather than a stat bump. The power module is deliberately not a required tax: if every building needed one, slot one would be spent identically every time and the real slot count would be one lower across the board. Ground poles keep base power free.

Status Is Free

Status readout is free on every building, not gated behind a module. An unmodded building must never be blind. The Status module upgrades the readout; it does not enable it.

Module Crafter

All modules are crafted exclusively in the Module Crafter. It also produces the four Upgrade Kits (Base Mk2/Mk3, Machine Mk2/Mk3), giving it a second product line. The Module Crafter has roof slots of its own, so module production can itself be modded.

Mk levels are not researched — research unlocks recipes, and a recipe may require a building at a given Mk. Raising a building's Mk is a crafting and construction action: Genesis fetches a kit and applies it in place via task UPGRADE_BUILDING. An upgrade changes level and nothing else — installed modules, port configuration, storage contents, StorageRole and in-progress work all survive. Full specification in [24_Module System Design](<./24_Module System Design.md>) §5a.

Genesis Bot & Construction System

Genesis — The First and Only Starter Bot

Genesis is the player's sole companion from the crash landing. It is the foundation of everything.

Property Value
Name Genesis (one per session, shared in multiplayer)
Count Always exactly 1 — cannot be replicated or replaced
Destructible No — indestructible under all circumstances
Capabilities Mining, building placement, deconstruction
Automation Manual only until Bot Programming I is researched
Role in multiplayer Shared session resource — any player can direct Genesis

What Genesis Can Do

  • Mine any basic resource node (slower than a Mining Drill, but always available)
  • Place any building from the build queue
  • Deconstruct any building and return materials to storage
  • Execute blueprint stamps (places all buildings in a blueprint area)
  • Act as emergency fallback if the player has no Construction Bots

What Genesis Cannot Do (Until Researched)

  • Operate autonomously
  • Execute automated build queues without player direction
  • Be assigned to a patrol route

Genesis Research Path

Start: Genesis operates manually only
      ↓
Bot Programming I (research)
→ Genesis can be assigned simple automated tasks
→ Unlocks: auto-mine assigned node, auto-deliver to assigned chest
      ↓
Bot Programming II (research)
→ Construction Bot Bay building unlocked
→ Genesis graduates to supervisory role (oversees bot fleet)
→ Unlocks: automated build queue, blueprint auto-execution
      ↓
Advanced Bot Specialisation (research)
→ Unlocks specialised bot types: Mining Bot, Repair Bot, Scout Bot
→ These bots are produced by the Construction Bot Bay
→ Can be deployed into alien territory

Construction Bots (Post-Research)

  • Produced by the Construction Bot Bay using Bot Frame + Bot Core + Bot Cell
  • Can be destroyed by aliens — creates pressure to defend the bot bay
  • Execute player's build queue automatically
  • More bots = faster construction
  • Stored in Bot Depots when idle
  • Genesis supervises and coordinates the bot fleet

Bot Components Production Chain

Metal Plates + Hull Plating → Press Machine → Bot Frame
Circuit Boards + Drive Core → Assembly Machine → Bot Core  
Power Cells + Fuel Cells → Assembly Machine → Bot Power Cell
                                                      ↓
                              Bot Frame + Bot Core + Bot Cell
                                                      ↓
                                    Construction Bot Bay → Construction Bot

Research System

Hybrid A+D: Science Drives + Passive Field Data

Auto Warz uses a hybrid research system that supports both active and passive playstyles.

Active Research — Science Drives

The factory produces Science Drives — physical items consumed by Research Labs to generate Research Points (RP). Players who build dedicated Science Drive production lines unlock technology significantly faster.

Drive Produced From RP Rate Unlocks
Basic Science Drive Metal Plates + Circuit Board 1 RP/sec per lab Tier 1–2 nodes
Advanced Science Drive Power Cells + Silicon Wafers + Polymer 5 RP/sec per lab Tier 3 nodes
Quantum Science Drive Quantum Processor + Energy Conduit 20 RP/sec per lab Tier 4 nodes

Multiple Research Labs consume drives in parallel — build more labs to spend drives faster and generate more RP.

Passive Research — Field Data

All running factory buildings generate a small passive trickle of RP based on what they are doing:

Activity Passive RP Generated
Running any extraction building 0.01 RP/sec
Running any processing building 0.02 RP/sec
Producing components 0.05 RP/sec
Producing advanced components 0.1 RP/sec
Defeating alien enemies (Phase 1) 0.5 RP per kill

Passive generation is intentionally very slow — a player relying only on passive RP will progress through the research tree, but it will take significantly longer than active Science Drive production.

Design Intent

  • The Optimizer: Builds Science Drive production lines, pushes research hard, unlocks tech fast
  • The Builder: Focuses on factory automation, research opens slowly in the background — never blocked, just slower
  • The Multiplayer Specialist: One player dedicates their factory output to Science Drive production while others focus on raw materials or defence

Research Nodes

The research tree is specified in [08_Research Tree Design](<./08_Research Tree Design.md>), which is its single authority. This document names nodes where a building or recipe is gated by one; it does not restate the tree.

An Industrial Research Branch listing used to sit here, organised into TIER 1 to TIER 4. It was deleted (OI-242, OI-243). It contradicted the tree's own structure - that document states there are no tier gates - and had gone stale besides, unlocking Smart Buffers (a building deleted under OI-020), Assembly Machine Mk2 (Mk levels are not researched at all, Canonical §4) and a roof-mounted power pole module (since redefined as a transmitter range extender).

Supply Chain Diagnostics

Building Status Indicators

Authority: [07_Art Direction Style Bible](<../03_Art & Audio/07_Art Direction Style Bible.md>) §1.6–§1.7c. This section summarises it. Where the two disagree, that document wins.

Core principle: healthy is unlit. Idle and processing show nothing on the status channel. Only faults light up. A working factory has zero lit rings, which is what lets the fault signal be as loud as it needs to be.

Four channels, four physical locations, so no signal can ever mask another:

Where Carries Healthy Fault
Machine body Alive / working Cyan working-lights on Off
Base ring Fault status Unlit Amber or red, pulsing
Base edge tabs Mk level Always visible Always visible
Port geometry Port direction Always visible Always visible

The inversion: healthy is glowing on top with a dark edge; broken is dark on top with a glowing edge. Factory health reads from the balance of cyan to amber on screen, without inspecting any single building.

Base ring — fault status

Colour identifies the system. Rhythm identifies the severity.

State Ring Colour Pattern Body cyan
Idle Unlit — — On
Processing Unlit — — On
Output full (backed up) Lit #F5A623 Amber Slow pulse (1.6s) On
Input starved Lit #F5A623 Amber Double-blink On
Under-voltage / brownout Lit #E8433A Red Slow pulse On
No power Lit #E8433A Red Fast pulse (0.55s) Off
Manually disabled Lit, dim #5A6A72 Grey-blue Steady Off

Amber means logistics. Red means power. The two have completely different fixes, so grouping by colour tells the player where to look before they read anything.

Rhythm is the primary channel, not a decoration. Slow pulse, double-blink and fast pulse stay distinguishable with no colour perception at all, which matters because amber/red is the most common confusion. Never ship a status that relies on hue alone.

Output-full and input-starved must never share a signal. Output-full is success — consumers satisfied, storage full, nowhere left to put things. Input-starved is failure. Priority routing makes full storage a normal steady state, so a shared signal would leave a healthy factory permanently in alarm.

No power fires two agreeing signals: the ring floods red and the body cyan goes dark. Stalled lights the ring but keeps cyan on, correctly signalling a machine that has power and is simply backed up.

Machine body — alive, and decay

Cyan working lights are diegetic: windows, viewports, readouts and indicator pips belonging to that specific machine, not a shared kit strip. On when powered and working, off when unpowered or disabled.

Brightness carries decay, scaled continuously from energy 2.5 undecayed to ~0.9 fully decayed, so a neglected district sits visibly duller than the rest.

Decay is NOT a ring state. It is a continuous value, and continuous values do not belong on a binary alarm light. The precise figure lives in the Analytics tab. Brightness is the ambient hint, never the only way to learn something.

What this replaces

Earlier versions of this document specified green for running, yellow for waiting-input, orange for output-full and red for no-power, as icons plus colours.

That is removed, and it is not a palette change. Green-for-running has no equivalent in this model and does not survive: under "healthy is unlit", a running building shows nothing on the status channel. Lighting every healthy building would leave a working factory glowing in four colours and destroy the channel that carries fault information. The two states the old table could not distinguish at all — output-full and input-starved, which are opposite problems — are separated here by rhythm.

Supply Chain Overlay (O)

  • Belts coloured by throughput: Green / Yellow / Red / Grey
  • Buildings coloured by status
  • Bottlenecks pulse red
  • Animated directional arrows on belts
  • Power connection range shown as faint circles around buildings

Shortage Alerts

  • Building starved > 10 seconds → HUD notification
  • Click notification → camera jumps to affected building

Factory-Wide Readouts

There is no full-screen overview. The Factory Overview (F) was removed in [09_UI-UX Design Document](<./09_UI-UX Design Document.md>) v0.6 and its readouts were distributed across the right flap rather than replaced. That document owns the mapping; it is not restated here.

Blueprints & Copy-Paste

  • Blueprint Tool: select area → save to library
  • Blueprints capture: buildings, belts, pipes, rail, drones
  • Ghost preview on stamp — red = blocked, green = valid
  • Blueprint strings shareable in multiplayer chat
  • Quick copy-paste: Ctrl+C / Ctrl+V (session clipboard only)
  • Blueprint library persists across sessions

Alien Defence System

Full alien design in: [[06_Combat & War System Design]]

How Aliens Work (Phase 1)

  • Aliens inhabit the planet and have defined territory zones
  • Attacks are triggered by player expansion into alien territory — not timed waves
  • The more aggressively the player expands, the more intense alien pressure becomes
  • Alien aggression level (host setting) scales the overall threat intensity
  • Different planets have different alien types (discovered in Phase 2+)

Alien Aggression → P2W Supply Chain Pressure

Alien aggression directly increases demand on the factory: - More aggressive aliens require more ammo (turret consumption increases) - More frequent attacks mean more building repairs needed (repair materials consumed) - Higher aggression means the player must balance factory expansion against defence spending - This creates the core Phase 1 tension: expand = more resources = more alien pressure = need more factory output

Defence Buildings

See #Buildings — Defence Buildings section above.

Multiplayer Considerations

Shared Factory

  • All players share the same planet and factory
  • Any player can build, modify, or delete any building
  • Genesis is a shared session resource — any player can direct it
  • Research is shared — one global RP pool

Concurrent Building

  • Two players can build in different areas simultaneously
  • Simultaneous placement on same cell: first to arrive at host wins

Blueprint Sharing

  • Share via blueprint string in chat
  • No cross-session cloud sharing in Phase 1

Placeholder Art Strategy

All buildings represented as coloured voxel cubes during prototyping.

Category Colour Hex
Extraction Warm Brown #8B5E3C
Processing Bright Orange #E8871A
Chemical Acid Green #7BC832
Assembly Cool Blue #3A82C4
Belts Light Grey #CCCCCC
Power Bright Yellow #F5D000
Storage Purple #8B4FC8
Research Teal #2ABFBF
Modules White (roof-mounted slot units) #F0F0F0
Defence Military Green #4A6741
Construction Silver #A0A8B0
Trains / Rail Dark Grey #555555

Phase 1 Content List

Resources

  • 5 Raw resources
  • 5 Refined resources
  • 5 Components
  • 3 Advanced Components
  • 3 Science Drive types
  • 3 Bot Component types
  • 4 Fluids

Buildings (~35 total)

  • 5 Extraction
  • 8 Processing
  • 3 Storage
  • 2 Research
  • 1 Module Crafter
  • 2 Construction (Bot Bay + Depot)
  • 6 Defence
  • 4 Power
  • Belt types + special pieces
  • Drone buildings
  • Pipe types
  • Train infrastructure

Research

  • ~25–30 Industrial branch nodes across 4 tiers

Open items for this document are tracked in docs/open-items.md, area factory.

Revision History

Version Date Changes
0.11 2026-08-29 Drone design extracted to 21_Drone Logistics Design, leaving a pointer. Every carrier with real depth now has its own document, matching 22_Trains & Rail and 20_Belt Logistics - The Router, and this document stops being the place where one carrier is special.
0.10 2026-08-29 Cache boxes specified: one substance per box, several boxes per drone, boxes as ordinary items on the barrel pattern. Flat box and assembled box separated to break the ship-boxes-inside-boxes recursion. Cardboard and metal as two shapes of cost. Worn boxes are recycled, not repaired. Trip conditions stated. Simulation Level table extended to cover packing and box wear.
0.9 2026-08-29 Drone routing amended: pairs plus a shared reserve, not pairs alone. Demand pulls; nothing is pushed. The drone pit added — reserve drones stationed and charged there, serving any configured route at any distance, trips always finishing, and no fallback when the pit is empty.
0.8 2026-08-28 Drones designed. Pair routing rather than a pooled network; the drone module as pickup, dropoff, dock and charger; the Drone Port removed as every job it held moved elsewhere; power poles as en-route charging only; running out of power as a Simulation Level behaviour.
0.1 2026-02-22 Initial draft
0.2 2026-02-22 Power system rewrite (building-range, no poles), Hybrid A+D research system with Science Drives, Module system (stacking order matters, combination bonuses, Module Crafter), Genesis Bot + Construction system, Bot Components added to resources, defence buildings section
0.3 2026-02-27 M2.1 complete — RecipeDefinition multi-input format documented, FLUID tier noted, implementation notes added for all 17 resources and 9 recipes
0.4 2026-02-27 M2.2 complete — all 21 building .tres files created and linked to recipes. Architecture confirmed fully data-driven: dropping a .tres in data/buildings/ is sufficient to register a new building — zero code changes required. GUT test suite validates all definitions automatically.

This document defines the complete factory experience for Phase 1. Any new building, resource, or mechanic proposed for Phase 1 must be added here and assessed against the Phase 1 content list before development begins.

Pipe & Fluid System (M2.3)

Full spec in [07_Pipe & Fluid System Design](<./07_Pipe & Fluid System Design.md>). This section summarises the factory-layer integration points.

Logistics: Pipes

Pipes are the fourth logistics method alongside belts, drones, and trains. Fluids cannot travel on belts or be carried by Genesis.

Pipe placement: Click-and-drag. Pipes auto-connect to all adjacent pipe faces — no rotation required. PipeConnector provides explicit directional control when needed.

PipeConnector: Mirrors the IoConnector pattern. Blue input_face set by R key at placement; green output_face always opposite in Phase 1. 10-unit internal buffer. Chains output→input with adjacent PipeConnectors.

Fluid simulation: Pair-equalisation per tick — iterates all connected segment pairs, transfers 40% of the imbalance (dead-band 0.5 units). Stable on looping networks. See [07_Pipe & Fluid System Design](<./07_Pipe & Fluid System Design.md>) for algorithm.

Session config: pipe_complexity — Basic (no pressure/temp), Standard (pressure only), Full (pressure + temperature). Default: Standard. Supply chain contribution multipliers: ×1.0 / ×1.15 / ×1.30.

Fluid Resources

ID Name Source Notes
fld_coolant Coolant Water Extractor Pipes only
fld_fuel Liquid Fuel Chemical Plant Pipes only, flammable
fld_liquid_metal Liquid Metal Smelter (high temp) Insulated pipes only
fld_chemical_solvent Chemical Solvent Chemical Plant Pipes only, flammable
raw_chemical_gas Chemical Gas Gas Pump Pipes only. See the data divergence note under Resources → Fluids.

All fluids have phase = LIQUID or phase = GAS, which is why they ride pipes rather than belts. This follows from phase in code; it is not a per-resource flag, and ResourceTier no longer exists. See Canonical Design Facts §12a.

Implementation Status

Shipped in M2.3: - PipeSegment, PipeSystem, PipeNetwork, PipeConnector nodes - FluidDefinition resource class and all 4 fluid .tres files - PLACE_PIPE and PLACE_PIPE_CONNECTOR Genesis task types - Arm-based pipe visuals (hub + per-face arms) - Pair-equalisation fluid simulation - Save/load for pipes and pipe connectors

Blocked, tracked as a code/design divergence: - Fluid as a production input. No building can consume fluid in a recipe (RecipeDefinition.inputs is item-only; receive_fluid() does not exist). This blocks Chemical Gas becoming a true fluid, and with it both recipes that consume it. See the divergence note under Resources → Fluids.

Deferred to M2.3.1: - Full temperature simulation (heat loss, solidification, pipe damage, fire) - Fluid Pump building - Heat Exchanger, Pipe Heater buildings - Fluid network diagnostic overlay

Revision History (continued)

Version Date Changes
0.5 2026-03-13 M2.3 complete — Pipe & Fluid System section added: pipe logistics overview, PipeConnector pattern, pair-equalisation fluid sim, all 4 fluid resource definitions, implementation status (shipped vs deferred to M2.3.1)
0.6 2026-08-26 Reconciliation pass against 00_Canonical Design Facts. Module system rewritten (fixed roof slots, no stacking, slot count from footprint + Machine Mk); Module Expansion research renamed Module Technology and now unlocks capability, not slots; Efficiency made the starter module. Power poles reinstated at the distribution tier alongside integrated transmitters; connection range relabelled a backend tuning value; brownout shedding given the hysteresis rule; per-grid health repointed from the removed Factory Overview to the right flap Power tab. Chemical Gas reclassified as a fluid, with the classification rule (transport medium, not origin) stated and the live data divergence recorded. Splitter/Merger/Filter Splitter collapsed into the Router. Shared tables are now extracted from their authority documents rather than copied.
0.7 2026-08-29 Global Factory Overview (F) replaced by Factory-Wide Readouts. The section still listed four readouts as though the screen existed, though the same document already noted its removal elsewhere. The replacement points at 09_UI-UX Design Document v0.6 rather than restating the mapping, per this document's own extract-don't-copy rule. (OI-021)
0.8 2026-08-29 Power Flow per-tick step 6 corrected and the shedding note rewritten as a summary. It stated that a shed building returns once voltage clears the recovery threshold, which 25_Power System Design §4a.2 has since shown is not sufficient on its own. Now points at §4a as authority rather than restating it, keeping only the counter-intuitive warning. (OI-005)
0.9 2026-08-29 Power Buildings table completed from 25_Power System Design §5.1: the five TBD outputs filled (Biomass 40, Wind 60 base, Geothermal 300, Nuclear 600, Core 40-2240), fuel rates added to Coal and Fuel, and the Accumulator unit corrected from 500 PU to 500 PU·s - storage is energy, not a rate. Incinerator (20 PU) and Air Scrubber (12 PU) draw set from §9.3.
1.0 2026-08-30 Recipe Selection added (OI-320). Where the choice lives, and that it is a selector only on multi-recipe buildings while single-recipe and extraction buildings get a label rather than a dead control. Recipe changes are instant, abandon an in-progress job with its consumed inputs, keep unusable buffered stock rather than voiding it, and surface rather than clear an explicit port filter. Adds the rule that an OUTPUT port with an explicit filter drains that resource, which is what stops a building soft-locking on stock its new recipe cannot use.
1.1 2026-08-30 Storage resolved (OI-020). Two storage buildings, Silo and Tank, and no third: the Smart Buffer is deleted, its configurable filter superseded both by port filtering at Base Mk3 and by the Silo already holding one substance. Silo capacity set at 500 / 1000 / 2000 by Mk (OI-068), keeping the 500 the data already ships. Mk buys depth, not variety (OI-069) — the fill window cannot display a mixture. One port per face confirmed sufficient (OI-059): four ports at 1 item/sec matches four Basic Belts, and Base Mk raises it.
1.2 2026-08-30 Industrial Research Branch listing deleted (OI-242, OI-243) and replaced by a pointer to [08_Research Tree Design](<./08_Research Tree Design.md>), which is the tree's single authority. The listing was organised into TIER 1-4 gates, which that document forbids, and had gone stale besides - unlocking Smart Buffers, Assembly Machine Mk2 though Mk is not researched, and a roof-mounted power pole module.