You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Two linked capabilities that together let a plan account for things it needs but that no recipe in the chain directly consumes — the classic case being "Py Science 1 needs steel" only because the buildings that run the chain are made of steel.
1. "Keep N in stock" goal
A goal type that means "make sure this good exists / keep a buffer of it" rather than "produce it at X/s forever". Today every goal is a continuous throughput target (BlockData.goals: { name, rate }[]); a one-off or buffer item has to be faked as a tiny rate. A stock goal should:
declare a target quantity (e.g. 100 steel on hand), not a per-second rate;
expand the recipe chain needed to make it (so its intermediates are covered) without implying a meaningful continuous production rate;
be visually distinct from rate goals in the block editor and summaries.
2. Capital / build-cost requirements
The machines a plan requires are themselves built from materials, and those materials must be produced even when nothing in the production recipes consumes them. Example: a Py Science 1 block uses assemblers/furnaces/etc. that are made of steel, so steel is genuinely required to stand the factory up — but it never appears as an ingredient of the science chain, so the planner currently shows zero steel demand.
Desired: roll the build cost of the buildings a plan needs into its demands as a one-time / coverage requirement. The solver already computes per-recipe building counts (machineReqs in app/src/server/factorio.ts); this feature would take those counts, look up each building's own item recipe, and surface the materials (and their sub-chain) as required — so steel, circuits, etc. show up as things to build.
Open questions
Stock and capital requirements are "coverage" demands (expand the chain, no continuous rate) vs the existing throughput goals. Do they share a goal mechanism or stay separate? See the coverage angle raised in Planner: support rate windows and low-throughput stock goals #10 (which otherwise covers rate windows/units — this issue takes over the stock/coverage half of it).
How deep does capital expansion go — just the building's direct materials, or the full sub-chain (steel → iron → ore)? Probably the full chain, surfaced as demands the factory view can satisfy with other blocks.
Buildings get replaced/upgraded over time; is capital a one-time cost, or amortized? Start with one-time "to stand this up you need X".
How do coverage demands interact with the factory-level coherence/seam model and "build the supplier block" flows?
Two linked capabilities that together let a plan account for things it needs but that no recipe in the chain directly consumes — the classic case being "Py Science 1 needs steel" only because the buildings that run the chain are made of steel.
1. "Keep N in stock" goal
A goal type that means "make sure this good exists / keep a buffer of it" rather than "produce it at X/s forever". Today every goal is a continuous throughput target (
BlockData.goals: { name, rate }[]); a one-off or buffer item has to be faked as a tiny rate. A stock goal should:2. Capital / build-cost requirements
The machines a plan requires are themselves built from materials, and those materials must be produced even when nothing in the production recipes consumes them. Example: a Py Science 1 block uses assemblers/furnaces/etc. that are made of steel, so steel is genuinely required to stand the factory up — but it never appears as an ingredient of the science chain, so the planner currently shows zero steel demand.
Desired: roll the build cost of the buildings a plan needs into its demands as a one-time / coverage requirement. The solver already computes per-recipe building counts (
machineReqsinapp/src/server/factorio.ts); this feature would take those counts, look up each building's own item recipe, and surface the materials (and their sub-chain) as required — so steel, circuits, etc. show up as things to build.Open questions
Part of #31.