Suggestion: Shows assembler count for each product that the intermediate product is used

[frank-segui]

Challenge:

When building a factory often a intermediate product is used by different products. The calculator makes it easy to know the total amount of assemblers needed, but not the portion of the assemblers needed by each product. I often want to separate the assemblers and put them close to what is going to use them, but I have to calculate how many assemblers each use manually.

For example:

I want to produce 9 processing units per minute. That requires 180 electronic circuits and 18 advanced circuits. The advanced circuits in turn require 36 electronic circuits. The total amount of electronic circuits is 216 which are produced by 3.6 assembling machines.

The amount of electronic circuits required by each product is clearly shown but not that advanced circuits require 0.6 of the total 3.6 electronic circuits assemblers and processing units require 3 of them.

Proposal(s):

• Show the amount of assemblers required for all dependencies of highlighted product on the visualized tab.
• Toggle display mode in visualize tab. (Resources/Assemblers/Belts?)

I am not sure how the first one would be done UI wise, but the second one should not be too bad.

[frank-segui]

2nd one may also address https://github.com/KirkMcDonald/kirkmcdonald.github.io/issues/102 and https://github.com/KirkMcDonald/kirkmcdonald.github.io/issues/85

[piegamesde]

Another proposal on how to solve this

The visualized dependency graph is always directed and acyclic. To be more precise, we have a polytree.

It's not hard to split a polytree into a list of directed rooted trees; one for each product. If we split the polytree the other way around, we get a directed rooted tree for each ingredient (personally I find this less useful, but it comes in handy at times).

With this proposal implemented, there will be three ways to visualize a factory: a "normal" view, a product view and an ingredient view.

[KirkMcDonald]

It is not acyclic. Consider uranium. And it's a bit of an artificial example, but consider the case in 0.16 of smelting copper by burning small electric poles. Various mods introduce other recipe cycles.

A second complication is that portions of the recipe graph involve entity ratios which depend on the ratios of outputs. These multivariate solutions mean that (for example) the solution for making 200 plastic and 100 solid fuel is not the same as the sum of making each one on its own. You can't naively split these into separate sub-trees.

[piegamesde]

Didn't think of those. The only cycle I knew until know is the kovarex enrichment on its own, which can be trivially eliminated.

Can't we just ignore all those cases and simple split where it's possible? I think it would still be useful in most of the cases (normal assembler stuff). I don't know how easy it is to determine if a subtree can be split or not though.

[piegamesde]

I tried to implement this and in theory it should not be too hard, but the data structures currently used to build the graph don't contain the information needed for splitting.

My idea is to split makeGraph(totals, ignore) into two functions: One that generates the graph with abstract data (nodes contain the recipe and rate, edges contain the item and the rate) and another that converts this graph into a dagreD3 with all the information that renderGraph(totals, ignore) needs.

Between these functions, we could then add further processing code that splits the graph if possible according to some settings.