Issue with Chemical Plants, "Read ingredients" circuit

[Fred_Svev]

TL:DR;
When playing Factorio [Version: 2.0.23, Vanilla] with the new assembly machine + circuit mechanics, an issue arises for machines with multiple fluid inputs. If you try to build a circuit that uses the new "Read ingredients" option, it is ambiguous which fluid input it should go into. This cannot be sensed or determined with the circuit network directly. This causes issues when attempting to make a dynamic crafting system using one of these machines. I propose that recipes order their fluid inputs consistently with how the circuit network orders signals but also propose another solution.

What:
When a crafting machine with multiple fluid inputs is connected to a circuit network with the "Read ingredients" option enabled, there is no direct way to determine which input each fluid from a multi-fluid recipe is supposed to go into. This could affect any machine with multiple fluid inputs (and circuit connections):

• In the base game: Chemical plants and oil refineries
• In Space Age: Foundries, electromagnetic plants and cryogenic plants (Cannot confirm, I do not own Space Age. I would love to see a reply with results)
• In any mods: Any modded recipes with multiple fluid ingredients in vanilla machines
• In any modded machines with multiple fluid inputs.

Where/When:
In practice, this is only an issue (in vanilla) with the chemical plant's double-fluid recipes: Light oil cracking and heavy oil cracking. All three of the (vanilla) oil refinery recipes work with the following circuit, and match to the results of Light oil cracking. One way to approach such a machine is as shown below:

Factorio Bug Report.png (407.42 KiB) Viewed 497 times

Here, a chemical plant has the "Read ingredients" option selected and outputs it onto the red line. Then, the fluids are filtered (using the constant and arithmetic combinator), and output on the green line. This is indexed using the new Selector combinator, with an index of 1 on one, and 0 on the other. The resulting fluid is then displayed on the Display panel. It can be seen that the Light oil cracking is incorrect while the Heavy oil cracking is. You could reverse the indices of the Selector combinators, but then the heavy oil combinator would be wrong.

Why:
What does the circuit do: The circuit outputs the greatest value signal to the left, and least to the right.

• For Heavy oil cracking, the recipe consumes 40 heavy oil and 30 water, so heavy oil on the left and water on the right.
• For Light oil cracking, the recipe consumes 30 light oil and 30 water, since these are at the same value, they are ordered by the order property. This means that the water is on the left, and light oil on the right.[\list]
• For the two oil refinery recipes with two fluid inputs (Advanced oil processing and Coal liquefaction) have the ingredient needed in greater quantity on the right.

In the circuit, the direction which each signal is sent to is determined by: Ingredient Count -> Item Order

What does the recipe/chemical plant do:
When a recipe is loaded for a type with a machine, the ingredients are in an array of 'ingredient' prototypes. The order of these changes which input the fluid required in. This can easily be seen with an example mod that introduces 'flipped' versions of two-fluid-input existing recipes.

The mod, and results

Code: Select all

--data.lua
local heavyOilCracking = table.deepcopy(data.raw["recipe"]["heavy-oil-cracking"])
heavyOilCracking.hide_from_signal_gui = false --Allows the recipe to be selected in combinators
heavyOilCracking.name = "reversed-" .. heavyOilCracking.name --Unique name
heavyOilCracking.enabled = true --This recipe is unlocked by default. Makes Debugging Easier
heavyOilCracking.ingredients ={
      {type = "fluid", name = "heavy-oil", amount = 40},
	  {type = "fluid", name = "water", amount = 30}
	} -- Reversed order of recipe as defined in "/base/prototypes/recipe.lua"

local lightOilCracking = table.deepcopy(data.raw["recipe"]["light-oil-cracking"])
lightOilCracking.hide_from_signal_gui = false --Allows the recipe to be selected in combinators
lightOilCracking.name = "reversed-" .. lightOilCracking.name --Unique name
lightOilCracking.enabled = true --This recipe is unlocked by default. Makes Debugging Easier
lightOilCracking.ingredients ={
      {type = "fluid", name = "light-oil", amount = 30},
	  {type = "fluid", name = "water", amount = 30}
	} -- Reversed order of recipe as defined in "/base/prototypes/recipe.lua"

local advOilProcessing = table.deepcopy(data.raw["recipe"]["advanced-oil-processing"])
advOilProcessing.hide_from_signal_gui = false --Allows the recipe to be selected in combinators
advOilProcessing.name = "reversed-" .. advOilProcessing.name --Unique name
advOilProcessing.enabled = true --This recipe is unlocked by default. Makes Debugging Easier
advOilProcessing.ingredients ={
      {type = "fluid", name = "crude-oil", amount = 100},
	  {type = "fluid", name = "water", amount = 50}
	} -- Reversed order of recipe as defined in "/base/prototypes/recipe.lua"

local coalLiquefaction = table.deepcopy(data.raw["recipe"]["coal-liquefaction"])
coalLiquefaction.hide_from_signal_gui = false --Allows the recipe to be selected in combinators
coalLiquefaction.name = "reversed-" .. coalLiquefaction.name --Unique name
coalLiquefaction.enabled = true --This recipe is unlocked by default. Makes Debugging Easier
coalLiquefaction.ingredients ={
      {type = "item", name = "coal", amount = 10},
	  {type = "fluid", name = "steam", amount = 50},
      {type = "fluid", name = "heavy-oil", amount = 25, ignored_by_stats = 25}
	} -- Reversed order of recipe as defined in "/base/prototypes/recipe.lua"

data:extend({heavyOilCracking, lightOilCracking, advOilProcessing, coalLiquefaction}) --Adds all of the prototypes to the game

Alternating between these two recipes with circuits creates the following gif. Notice how the fluid inputs change but the display panels do not.

Changing Ingredient Order.gif (896.39 KiB) Viewed 497 times

In summary: a circuit network orders the signals based on the amount of ingredient, and then a property hidden to players (essentially arbitrary). The chemical plant (and other multi-fluid machines) orders the fluid inputs based on the order of the ingredients in the RecipePrototype. (Also arbitrary to players, but I would be interested to hear from a dev if there was a specific reason that the inputs are ordered like this) This disconnect leads to issues when trying to use the circuit network to control fluid inputs

How (I propose to fix it):

Follows are some proposed fixes, ranked by my preference (most to least preferred):

1. Add a condition to the selector combinator for "Sort by recipe"/"Sort by fluid input order". Feeding the recipe and its ingredients into a selector combinator could allow it to "sort" these based on the prototype definition. This change does not add any entities and is only noticeable to those who use the circuit network to a detailed level. Seems like the least invasive solution.
2. In the factorio "/base/prototypes/recipe.lua", change the order of the Heavy oil cracking recipe, as it is the only one where the highest fluid in the "Read ingredient" signal is on the left instead of right. In the future (and someone with the Space Age DLC should check those buildings as well) this should be standardized in base game content. It could be possible that recipe loading of these could default to this behavior, as there is an option in FluidIngredientPrototype for overriding this behavior. This solution has been ruled out since there is a pretty good reason that the two multi-fluid recipes in the chemical plant are the way that they are. See this post.
3. Somehow detect which fluid is preferred in each input port with the circuit network. This could be in the machine itself, or letting the fluid preference propagate to tanks. The difficulty here is that machines already have issues with how many circuit conditions they have (~6) compared to the number wires that can be connected (2, but signals output by the machine are on both.) Perhaps multiple connection points, like combinators, on each fluid input? It seems like a large change for such a small fringe case, but this still allows for the freedom to arbirarily order fluid inputs in a recipe.

Things that can't be done to fix it:
Before you comment one of these things, read why I am proposing my change, and not just doing one of the following.

• "Why not just make a mod to change the one vanilla recipe that is wrong?"
  Because if I want to share a blueprint for a dynamic crafting chemical plant, it would not work without this mod. One of the big promises with the new circuit control is "All these things together should make it possible to make more generic assembler setups for those who like to dig deep into the automation of automation." That is all well and good for the assemblers, but the circuit control is clearly lacking for other machines (oil refinery, chemical plant, and furnace )
• "You know that you can flip the chemical plant, right?"
  If you flip the chemical plant, it flips the fluid inputs for every recipe in it. Not just the offending one. And standing there and flipping the machine each time it changes recipe goes against the principal of automation. The double-edged sword on this argument, my first proposed solution is not technically a breaking change as you can just mirror the chemical plant in every Heavy oil cracking setup.
• "Why not account for the edge case in circuitry?"
  This is a good point actually. I have made a solution that uses two decider combinators and a constant combinator to hold the recipe. The problem with this is if the order of fluids in the recipe is truly arbitrarily chosen, then why not have it so that this is not even an issue? Of all 5 of the vanilla recipes that use two fluids, only one does this. Also having to identify these cases for any non-vanilla playthrough also seems pointless if the ordering of ingredients is arbitrary.

[Koub]

[Koub] Moved to Ideas and Suggestions.

[DefGie]

I'm very surprised by your order of preference on these two possible solutions. I completely see your point why this, though a bit niche, breaks the promise of next-level automation with "set recipe" by circuit signal. But option one has multiple problems. In no particular order really:

1. Heavy oil cracking and light oil cracking currently take water in the same input. This undoubtedly informed the ordering of ingredients in the recipe, as it feels natural in anything but the type of recipe-change automation you're looking at.
2. You noted it's "not technically a breaking change as you can just mirror the chemical plant in every Heavy oil cracking setup". If this change were to be implemented, when it goes live everyone's bases would break because these input pipes would suddenly be swapped. And this might lead to a broken mixed-fluid system that's more hassle than you expect to resolve, I'm not sure.
3. Rather than tackling the inherent problem, you seem to be suggesting the recipe definition should be tuned with this somewhat niche concern in mind. Calling it niche here isn't to diminish the validity of the concern, rather, the point is that it will not be top of mind when writing or rebalancing recipes. The problem could easily resurface. This applies to WUBE, although this kind of change to the standard game will be infrequent, and it applies to modders. The problem should be solved in such a way that regardless of what recipe is defined, the circuit network can be used to dynamically configure your environment for the recipe.

Turning all fluid input/outputs into discrete circuit network attach points sounds like a much better direction to me, though it does raise questions. It seems like the best flexibility would be to the tune of - Attach to center of the building provides all existing functionality; inputs/outputs always read their fluid type and never building-level options like read recipe. When the update rolls out, existing circuit connections to affected buildings would be translated as "attach to center". But you have to worry about visual clarity and how the player is going to know they can do this or understand what's happening if they do it by accident.

I think a simpler approach would be to give the selector combinator an option to "sort by recipe order", where recipe is either a constant or circuit network signal (when there are multiple signals choose by the same logic as "set recipe", which I haven't actually absorbed what is).

[Fred_Svev]

Thank you for replying, and in such a kind tone.

This undoubtedly informed the ordering of ingredients in the recipe

It is good to know the reason that the two chemical plant recipes are like that. This makes sense for machine + recipe combos that have one consistent fluid input. I wrote this post assuming that the order in the recipe was arbitrary, which is why I ordered my proposed solutions that way. Now knowing this, I do not think it is the better solution. Not that I personally like this logic, I understand why it is good to have water always go in the same input from both gameplay and realism points of view. ("I already have a setup for heavy oil cracking" -> "Light oil cracking involves a similar recipe, and similar real-world process" -> "I should just be able to CTRL+C, CTRL+V and put light oil in where the heavy oil goes")

The problem should be solved in such a way that regardless of what recipe is defined, the circuit network can be used to dynamically configure your environment for the recipe.

This is very true. The concern I have is actually one in a bunch on the topic of automation of crafting machines using the circuit network, but to prevent bloating one forum post with too many changes I thought I would tackle them one at a time, with the simplest one first.

But you have to worry about visual clarity and how the player is going to know they can do this or understand what's happening if they do it by accident.

Looking back with this new focus on visual clarity, it is interesting to note the lack of polish actually working with circuits have gotten, in comparison to almost every other facet of gameplay mechanics as of late. Breaking it down by each step of making a circuit connection:

1. First you select "Make green/red wire" from next to your tool bar
2. You click the first circuit connection point
   The only visual issue here is if the entity you click does not allow circuit connection, it shows a floating "Cannot connect to wire" message, and progress through this list stays at the same step.
3. You click the second circuit connection point
   When attempting to make the second connection to an entity that does not allow them, clicking again makes the "Cannot connect to wire" message appear. Additionally, there is a visual indication before clicking the second connection, in the form of the "red circle with cross through it", which is rendered below GUI effects.

This does seem to be an issue separate from the one proposed here, so I will look and see if anyone else has proposed a change here and if not, create a post for it.

I think a simpler approach would be to give the selector combinator an option to "sort by recipe order", where recipe is either a constant or circuit network signal (when there are multiple signals choose by the same logic as "set recipe", which I haven't actually absorbed what is).

This is the new #1 solution. It feels like it fits naturally into the Factorio gameplay, and does not involve changing too many existing mechanics. I will update OP to reflect the changes you have brought up.

[zig1000]

As noted, but actually true for all chem plants recipes, not just cracking, is that in every case where two liquid inputs are required, one is always water, and always the same side. So, you can hardcode that pipe, which saves a lot of time spent flushing pipes. Do note that if your water pipe is ever empty you could get issues with backflow from single fluid recipes if they eject their inputs while switching recipes, contaminating your empty water pipe with some other fluid.