Add ability produce multiple items from the same assembler.

[d6rks1lv3rz3r0]

Many compact factories rely on being able to produce a variety of items from the same assembler. I have sold many factories that can make 6 of any industry M an hour from 3 assemblers. So at any given time the factory needs to have enough stock to produce any requested industry at the requested rate, or any combination there of like 1 refiner and 2 smelters, but not enough to produce 3 of every industry at the same time.

Basically you are enforcing AND as the merging condition right now. Consider allowing OR.

[tvwenger]

@d6rks1lv3rz3r0 thanks for the suggestion! Unfortunately, I don't think we'll implement this any time soon since it really breaks several of the core assumptions/requirements/aspects of the current algorithm. As we've designed it, this algorithm is about building large, static factories. You put ores in and out comes all of things you need as quickly as possible with absolutely no interaction. What you are describing would require human interaction to change the recipes (and maybe links) on existing assemblers. This will require a whole new algorithm!

[d6rks1lv3rz3r0]

It shouldn't require a whole new algorithm. I went through the code and as far as I can understand, we are basically doing the exact same thing (I was doing it locally). There is no need to relink things, and the only interaction is at the assembler, which doesn't affect your algorithm since it is at the end. So basically all you need to do is instead of saying:

Assembly Line S

Rate	Amount	Name	Rate	Amount	Name
0.75	6	Basic Screw	0.125	1	Retro-Rocket Brake M
0.625	5	Basic Burner
0.125	1	Basic Ionic Chamber S
0.125	1	Basic Standard Frame S

Rate	Amount	Name	Rate	Amount	Name
0.75	6	Basic Pipe	0.125	1	Adjustor M
0.625	5	Basic Injector
0.125	1	Basic Gaz Cylinder S
0.125	1	Basic Standard Frame S

You instead say:

Rate	Any Assembly S
0.75	Basic Screw
0.75	Basic Pipe
0.625	Basic Burner
0.625	Basic Injector
0.125	Basic Gaz Cylinder S
0.125	Basic Ionic Chamber S
0.125	Basic Standard Frame S

This example makes Any Ship part that can come out of an Assembler S on the same assembler S. All that has changed here is that instead of working off the first list, you are working off the second. Notice how instead of adding the two entries for Basic Standard Frame S, all I did was use maximum. 0 change needed to your core algorithm.

[tvwenger]

@d6rks1lv3rz3r0 Thanks for the information! I understand your idea and how it could be useful to save space in a factory.

Your idea does change the algorithm and would not be easy to implement in the current framework. By change the algorithm, I mean it's changing both the goal of the algorithm and a core assumption. The goal is to create a nearly 100% efficient and static factory. The core assumptions are that each industry produces one item and each container stores only one item (with one exception).

Here are two cases that exemplify my concerns:

1. Your example used two ship parts, but what about other components? For example, I might set up my factory to produce Glass, Advanced Glass, and Basic LED. Will all three, because they're all factory outputs, be produced by the same Glass Furnace? How will the Basic LED industry be fed then? Yes, there are ways to check for this and make sure it works properly, but that requires large changes to the algorithm.

2. Your idea also adds another layer of complexity: what if I want Adjustor M and Atmo Brake M to be made by one assembler, but I want Basic Atmo Engine M and Basic Space Engine M to be made by a different assembler? Now the user will have to specify which items can be made by the same assemblers, and which we want to be on different assemblers.

Everyone will have different ideas for building a factory. That is not what this tool is for. This tool is for building a large, static factory.

[d6rks1lv3rz3r0]

1. Nope you will preserve your foundational principles. Glass, Advanced Glass will all be made by different industries, only 1 type of item in each container, nothing changes here. I don't think my point is coming across because nothing you say here is needed for what I am talking about. ALL I am saying in essence in the above example is when you conjoin two recipes and setup the factories, do not ADD the recipes, but take the MAX component of each unique recipe ingredient.

2. This is not a concern. Any assembler can make any part that it's size can support. You will get this functionality automatically. It makes no sense to segregate assemblers of the same size to different products. All you enter is items need making, number of assemblers and maintain number like usual, but check the box that says "Serialized Production".

Again, I assure you I have been doing exactly what you are doing, and I have virtually the exact same algorithm written in MATLAB. You don't need to change ANYTHING at all. Only MAX UNIQUE instead of SUM.

About your last statement, that is true. Everyone may have a different sense of what the best factory is. I totally understand if this doesn't go in a direction you want to pursue. I am just trying to make sure you understand what you are rejecting fully before doing so because it is much more trivial (literally 2-3 lines) of a change than you make it out to be.

[lgfrbcsgo]

Yeah, I think that would be possible. We would take the two final recipes and merge their ingredients. We support recipes with more than 7 ingredients, right, @tvwenger? So we wouldn't run into issues there either.

I am just trying to make sure you understand what you are rejecting fully before doing so because it is much more trivial (literally 2-3 lines) of a change than you make it out to be.

I agree, there are actually no changes to the algorithm required. However, the algorithm is only one part of the generator. We would need to change the UI and serialization.

[tvwenger]

@d6rks1lv3rz3r0 I appreciate your concerns and am happy to chat about this! I want this tool to be as useful as possible. :-) Maybe it would be easier to have a voice chat about this? Join us on discord!

1. Nope you will preserve your foundational principles. Glass, Advanced Glass will all be made by different industries, only 1 type of item in each container, nothing changes here. I don't think my point is coming across because nothing you say here is needed for what I am talking about. ALL I am saying in essence in the above example is when you conjoin two recipes and setup the factories, do not ADD the recipes, but take the MAX component of each unique recipe ingredient.

Our algorithm currently does not discriminate between those things that are produced in Assembly Lines and those that aren't. All it knows about is what is a "factory output". So in your example, where we combine the Adjustor M and Retro-Rocket Brake M factory outputs into a single assembly line, our algorithm would have to make some distinction so that it doesn't do that for Glass and Advanced Glass factory outputs. You see what I mean?

2. This is not a concern. Any assembler can make any part that it's size can support. You will get this functionality automatically. It makes no sense to segregate assemblers of the same size to different products. All you enter is items need making, number of assemblers and maintain number like usual, but check the box that says "Serialized Production".

I'm not sure that I made myself clear. What if I, as the user, wanted to have an Assembly Line M that makes Adjustor M or Retro-Rocket Brake M, and then another Assembly Line M that makes Basic Space Engine M or Basic Atmo Engine M? I don't want to combine all four of those recipes into a single Assembly Line M for whatever reason.

We would take the two final recipes and merge their ingredients. We support recipes with more than 7 ingredients, right, @tvwenger?

That's correct.

[tvwenger]

@d6rks1lv3rz3r0 I had a chat with @lgfrbcsgo and I concede that your idea would not need to change the algorithm, but it would need to change some of the infrastructure/UI as he mentioned. I'm not sure how much time I will have to implement this, but we'd be happy to look over a pull request if you can do it!

[d6rks1lv3rz3r0]

Ah I see, you are saying you have absolute recursion. Your algorithm doesn't know if what it's unfolding is the final output or an intermediate product? If that is the case I do see some change is necessary indeed.

The assembler segregation is an interesting question. I mean I see absolutely no point in a setup like that as described because it defeats the purpose of the serialization in reducing repetition of capacity for things that are commonly associated. But you could technically accommodate use cases where maybe someone wants to use 4 assemblers, but wants only 2 of them to be able to make say large containers at any given time but all 4 of them can make medium containers. In this case all 4 are still capable of producing large containers so factory setup logic doesn't change, but the recipe/requirements are setup to satisfy only 2 of them. So if they ran all 4 on large containers it would bottleneck. This can be accommodated with no additional change other than those necessary to accommodate the original proposal.