Nodes are the things you place in the planner. Machines, resources, logistics nodes, notes, groups, and subfactories are all node types.

This page covers the user-facing node types and the properties you can see or change in the planner UI. It does not document internal solver fields that never show up in normal use.

The icon table below uses the same planner icon system that appears in the context menu. Some node headers still change based on the selected recipe or item, so this is a node-family guide rather than a full visual catalog.

Node icon guide

How to read node properties

Some node properties are editable. Others are read-only and exist to show current state.

A good rule is simple:

• editable properties are the fields, toggles, sliders, and selectors you use to shape the plan
• read-only properties are the rates, warnings, summaries, and status labels the planner calculates for you

In the planner, not every node uses the same control pattern. Some nodes have a pencil or config button in the header. Others are edited directly in the node body, or use the small controls already visible in the header.

Common control patterns:

• Pencil button: opens machine or resource settings, switches notes into editing, or renames a subfactory.
• Config button: opens filter settings on smart and programmable splitters.
• Inline fields: some nodes are edited directly in the visible body instead of a separate panel.

Machine node

Machine nodes are the core production nodes in the planner. If a node is supposed to turn one set of items into another, this is usually the node you want.

A machine node does two jobs at once. First, it represents a real production building and the recipe running on it. Second, it is where the planner calculates whether the machine is actually getting the right inputs and producing the expected outputs.

Use a machine node when you want to answer questions like these:

• what recipe should this step use
• how many items per minute should go in and out
• whether this step is underfed, overfed, or blocked
• how overclocking, shards, or somersloops change the result

Editable properties:

• Recipe: chooses what the machine makes.
• Clock speed: sets machine overclock.
• Power Shards: raises the machine's maximum clock speed.
• Somersloop slots: adds production amplification on machines that support it.
• Locked pins: locks an input or output rate to hold a target value.

Read-only properties:

• Machine: the building that runs the selected recipe.
• Inputs: the required ingredients and their current rates.
• Outputs: the produced items and their current rates.
• Power: current power draw.
• Efficiency: current efficiency percentage when a recipe is selected.

Compact mode adds these machine properties:

• Quantity: how many identical machines are represented by the node.
• Base overclock: the base clock for the compact group.
• Total shards: the total shard budget across the group.
• Shard distribution: whether shards are spread evenly or filled first.
• Per-machine clock states: the compact machine can expand to show each machine's own clock.
• Somersloops: the total number of somersloops used by the compact group.
• Somersloop distribution: whether somersloops are spread evenly or filled first.

In practice, machine nodes are where most balancing work happens. If a layout is wrong, the first useful clues often show up here through wrong rates, missing inputs, or outputs that do not match the rest of the chain.

Resource Node

Resource Node is the source node for raw extraction. It is the point where outside supply enters the planner as mined ore, pumped liquid, or extracted gas.

This node matters because it defines the upstream limit of a chain. Before you even connect machines, the resource node tells you what raw material exists, what extractor is being used, and what the expected output ceiling is.

Use a resource node when you want to answer questions like these:

• how much raw material this source can produce
• whether the chosen purity and extractor support the target rate
• whether the rest of the plan is asking for more than the source can provide

Editable properties:

• Resource: the raw item being extracted.
• Extractor: the miner, pump, or extractor used for that resource.
• Purity: Impure, Normal, or Pure when the resource supports purity.
• Clock speed: extractor overclock in detailed mode.
• Power Shards: shard count in detailed mode.

Read-only properties:

• Output rate: current extracted rate.
• Power: current extractor power draw.
• Rate: the large output value shown in the node header.

Compact mode adds these resource properties:

• Quantity: how many identical extractors are represented.
• Base overclock: the shared base clock for the extractor group.
• Total shards: total shard count across the compact group.
• Shard distribution: even or fill-first distribution.

A common use for this node is testing limits before building the rest of the line. If the resource node cannot meet the target rate, the rest of the layout will always be compensating for a shortage instead of solving the real issue.

Logistics nodes

Logistics covers routing, node pin structure, filter behavior, and the utility nodes that shape flow through a plan.

This is where splitter-style controls belong. If you are looking for filter config or pin count changes, this is the section to read.

Common logistics controls:

• Plus and minus controls change pin count on splitters and mergers.
• Config button opens filter settings on smart and programmable splitters.
• Inline values and badges show what is flowing, where it is going, and whether a rule is active.

Splitter

Splitter is the basic node for taking one incoming line and branching it into several outgoing lines.

A splitter does not create or destroy throughput. Its job is to distribute a single feed across multiple destinations while making the resulting branch rates visible.

Use a splitter when you want to answer questions like these:

• how one supply line is divided between multiple consumers
• whether each branch is getting the right share of the flow
• how many outputs the current routing step needs

Editable properties:

• Output count: you can add or remove output pins.
• Locked pins: you can lock output rates.

Read-only properties:

• Center item display: the item, or mixed item state, currently being routed.
• Incoming rate: the current total feed.
• Per-output rate: the rate shown for each output branch.

The key thing to watch on a splitter is not just whether something is connected. It is whether the outgoing branches still make sense together. A splitter can look valid while still starving one branch and overfeeding another.

Merger

Merger combines several incoming lines into one outgoing line.

A merger is the opposite of a splitter in layout shape, but you usually read it differently. Instead of watching how one line gets divided, you watch whether several feeds can safely share one output without exceeding what comes after it.

Use a merger when you want to answer questions like these:

• whether several upstream lines can be collected into one destination
• whether the merged rate still fits the output line and the next machine
• whether each incoming branch is actually contributing what you expect

Editable properties:

• Input count: you can add or remove input pins.
• Locked pins: you can lock input rates.

Read-only properties:

• Center item display: the item, or mixed item state, currently being routed.
• Per-input rate: the rate shown on each incoming branch.
• Outgoing rate: the merged result shown on the output side.

Mergers are often where hidden overcapacity starts. Several valid-looking branches can still create a bad combined rate once they meet.

S* Smart Splitter

Smart Splitter always has one input and three outputs.

This node is for rule-based routing. Instead of treating every outgoing branch the same, it lets you decide what each branch is allowed to carry.

Use a smart splitter when you want to answer questions like these:

• where a specific item should go in a mixed flow
• whether overflow and undefined items are handled safely
• whether each branch has the right routing rule

Editable properties:

• Output filter: each output gets one rule.
• Filter type: each output can be set to Any, None, Any Undefined, Overflow, or a specific item.

Read-only properties:

• Incoming item: the item or item mix arriving at the node.
• Incoming rate: current total feed.
• Per-output rate: the rate on each output.
• Filter badge: a small badge shows the active rule for each output.

The most important thing to read here is the relationship between the rule and the actual rate. A rule can look correct on paper but still pass less or more than expected once the incoming mix changes.

P* Programmable Splitter

Programmable Splitter uses the same basic shape as Smart Splitter, but each output can hold a broader rule set.

This is the node to use when single-rule routing is not enough. It works better for mixed lines, broader exceptions, or outputs that need more than one accepted item.

Use a programmable splitter when you want to answer questions like these:

• whether one branch should accept several items instead of one
• whether a mixed line still has a predictable rule set
• whether fallback and overflow behavior is clearly defined

Editable properties:

• Output rules: each output can hold multiple item rules.
• Rule content: item-based rules can include more than one item.

Read-only properties:

• Incoming item: the current feed.
• Incoming rate: current total feed.
• Per-output rate: the rate on each output.
• Filter badge: the badge summarizes the active rule set.

Because the rules are broader, this node is also easier to misread later. It helps to treat it as a routing contract, not just a convenient branch.

Storage

Storage is a solid-item buffer.

In planner terms, storage is mostly a visibility node. It helps you see what is passing through the buffer and whether the connected flow still makes sense.

Use storage when you want to answer questions like these:

• what item is being buffered at this point in the layout
• whether mixed flow is reaching storage
• whether the storage point is part of a stable route or a messy one

Read-only properties:

• Main item display: the incoming item, mixed state, or empty-state message shown in the top box.
• Throughput: the current rate through the node.
• Contents: when the feed is mixed, the node lists tracked items and rates.

Storage is useful as a checkpoint. It makes a route easier to inspect without changing the logic of production.

Dimensional Depot

Dimensional Depot tracks uploaded item flow.

Like storage, this is mostly a read-heavy node. Its value is in showing what upload stream exists and whether it stays clean and predictable.

Use a dimensional depot node when you want to answer questions like these:

• what item stream is reaching the depot
• whether mixed uploads are happening
• what the current upload rate looks like

Read-only properties:

• Main item display: the incoming item, mixed state, or empty-state message shown in the top box.
• Upload Rate: the current incoming rate.
• Tracked Items: when mixed items exist, the node lists them with rates.

This node is usually about monitoring, not tuning.

Awesome Sink

AWESOME Sink tracks sinkable flow and point output.

This node shows how excess or dedicated sink flow behaves. It is useful both for understanding rates and for checking whether the incoming stream is actually worth sinking.

Use an awesome sink node when you want to answer questions like these:

• how much material is being sunk
• how many points that stream produces
• whether unsinkable items are mixed into the line

Read-only properties:

• Incoming Feed: the current item display, mixed state, or warning message shown at the top.
• Rate: total incoming rate.
• Points: current points per minute.
• Breakdown: when the feed is mixed, the sink shows item-by-item points.
• Warning message: the node warns when some incoming items produce zero points.

The warning state matters here. A sink line can look busy while still wasting part of the incoming material.

Note

Note is a text node for planning comments.

A note node does not affect flow. Its job is to keep reasoning, reminders, naming, or local instructions inside the layout itself.

Use a note when you want to record things like these:

• why a route exists
• what a section is supposed to do
• what still needs to be fixed later
• what assumption the current setup depends on

Editable properties:

• Content: rich text content inside the note.
• Formatting: bold, italic, strike, bullet list, and numbered list.
• Font size: adjustable text size.
• Size: the note can be resized.

Read-only properties:

• Title: the node header stays Note unless the implementation changes later.

Notes are most useful when a layout is large enough that you would otherwise forget why a certain choice was made.

Group

Group is a visual container inside the current workspace.

A group does not create a new internal factory. It is for visual organization at the current level of the layout.

Use a group when you want to:

• separate one stage from another without changing the planner hierarchy
• keep a section readable
• collapse or lock a region so it is easier to manage

Editable properties:

• Label: rename the group by editing the group title.
• Color: choose a background color for the group.
• Lock: locks the group so it cannot be edited accidentally.
• Collapse: collapses the group into a compact pill.
• Size: groups can be resized when unlocked.

Read-only properties:

• Item count: the planner shows how many items sit inside the group in summary views.

The simplest distinction is this: a group is visual structure, not planner hierarchy.

Subfactories

Subfactories are what you use when one big factory starts feeling too crowded to manage in one view.

This section covers the three parts that work together:

• the Subfactory node you see in the parent layout
• Factory Input, which brings material down from the parent factory
• Factory Output, which sends a finished feed back out

These are the nodes that let one factory section live inside another without turning the whole layout into a mess.

Subfactory

Subfactory is a full factory node inside another factory.

This is not just a visual box. A subfactory has its own inside area, and it can have its own inputs and outputs.

Use a subfactory when you want to:

• break a large layout into meaningful internal modules
• give one section its own inputs and outputs
• simplify the parent layout without losing structure
• reuse the same mental model at another level of the plan

How you create and enter one

The normal flow starts from the right-click menu on empty space:

1. open the right-click menu on empty space
2. choose Subfactory
3. open the subfactory options
4. choose New if you want a blank subfactory
5. choose the name and mode in the subfactory picker

If you do not want a blank one, the same menu also gives you From Your Library.

That opens the Add Subfactory picker, where you can choose from:

• My Library: your saved subfactories
• Imported: imported community factories

When you pick one of those, Ferrumium places it as a subfactory node with its inside content already filled in.

There is also a second creation flow while building from an existing line. If you branch out from an item flow and choose Subfactory, Ferrumium can create the subfactory with a matching boundary already set:

• branching forward from an existing output can create the subfactory with an input already prepared
• branching backward from a needed item can create it with an output already prepared

Once a subfactory exists, double-clicking the node drills into its internal workspace.

What you can change on the parent node

Editable properties:

• Name: rename the subfactory from the pencil button in the header.
• Inputs: add new boundary input slots from the plus button.
• Input item: each input slot can be assigned to an expected item.
• Input removal: unconnected input slots can be removed.

Read-only properties:

• Mode badge: shows whether the subfactory is Detailed or Compact.
• Input rate: the shown rate updates automatically from the actual flow.
• Outputs: outputs are defined by the Factory Output nodes that exist inside the subfactory.
• Mixed output state: if an output carries multiple item types, the parent node shows that as mixed.
• Internal size: the footer summarizes the internal node count and machine count.

The most important thing to remember is this: you set up incoming slots on the parent subfactory node, but outgoing slots are created by what you build inside it. In simple terms, you choose what can go in, and the inside work decides what comes back out.

Connected input slots also behave differently from empty ones. Ferrumium reads the real incoming flow there, and mixed inputs stay mixed instead of turning into a normal single-item slot.

Compact-mode subfactories keep the same meaning, but the internal view and the parent badge change to match the compact factory style.

Factory Input

Factory Input is used inside a subfactory to bring material in from the parent factory.

This node marks the handoff between the outer factory and the inside of a subfactory. It does not make anything by itself. Its job is to bring one parent input into the inside view so you can build from it.

There are two common ways it appears:

• Ferrumium creates it automatically when the parent subfactory already has an input slot and you drill into the subfactory
• if that input node already exists but is not being used yet, you can find it from Unused Inputs in the right-click menu and jump to it

Use a factory input when you want to answer questions like these:

• what material is supposed to enter a subfactory
• whether the parent layout is providing that material
• how much imported flow is available inside the subfactory

There is not much to edit directly on this node. In practice, the real setup happens on the parent subfactory input slot, not on the Factory Input card itself. You do not place this node manually as a new boundary from the normal right-click menu.

Read-only properties:

• Parent Feed: the incoming item display, including mixed state when needed.
• Incoming Rate: the current imported rate.

How to use it well:

1. define or connect the input from the parent subfactory node
2. drill into the subfactory
3. use the Factory Input node's output handle on the right as the start of the internal line
4. connect that feed to the machines or other nodes inside that section

If the parent feed is mixed, the node shows Mixed and lists the item-by-item breakdown. That is your sign that this input is carrying several things, not one clean item line.

Factory Output

Factory Output is used inside a subfactory to send material back to the parent factory.

This node does the opposite of Factory Input. It marks what leaves the inner layout and becomes available again at the parent level.

The usual creation flow starts from a branch-out inside the subfactory. When you branch forward from an internal item flow and choose Factory Output, Ferrumium places the boundary node for that line.

Use a factory output when you want to answer questions like these:

• what the subfactory is actually producing for the outside
• whether the expected export is reaching the boundary
• whether the parent layout is consuming the exported flow correctly

Like Factory Input, this node is mostly for showing what is happening at the edge of the subfactory, not for lots of local editing.

Read-only properties:

• Internal Feed: the current internal item display, including mixed state when needed.
• Outgoing Rate: the current exported rate.

How to use it well:

1. branch out from the internal line that should leave the subfactory
2. choose Factory Output
3. verify the node shows the expected item and rate
4. return to the parent scope and use the new or updated output pin on the subfactory node

If the connected child feed is mixed, the parent output becomes mixed too. That usually means the subfactory is sending out a bundle of items instead of one clean product.

How the full boundary works

The whole parent-child loop is easiest to read in this order:

1. add or connect inputs on the parent Subfactory node
2. double-click into the subfactory
3. use Factory Input nodes as the imported starting points
4. build the internal machines, routing, storage, or sinks
5. end exported lines with Factory Output
6. go back up and connect the resulting subfactory outputs in the parent layout

That sequence is the real difference between a Group and a Subfactory. A group just helps you organize what you already see. A subfactory lets one part of the factory have its own inside space while still connecting back to the main layout.