[0.17.16] Wrong "can't mix fluids" message when changing recipe

[drNokard]

Hello.

When copying and pasting (default ctrl-c) if the copied entities are Chemical plants with their connecting pipes, it's not possible to change recipe of the chemical plant even if the pipes are still empty and not yet connected to the full pre-existent pipes.

In the screenshot you can see the copied pipes have not yet the connections to the left pipes, those would be added later.

[coderpatsy]

If I'm seeing it right, the chemical plant is connected to the output pipe, which is reserved for light oil.

[drNokard]

No input or output pipes are yet attached in the screenshot, there is only the left "pipe to ground" but there is no "ground to pipe" placed.
The upper chemical plants are correct (they are the source of copy), the lower four are the copied entities.

[boskid]

Well, this is how fluid mixing detection is implemented. You must first clear recipe in all chemical plants so input/output pipe will not be assigned to any fluid, then you can set proper recipe.

Same goes with oil refinery and game progression: you first have "basic oil processing" that uses second input for crude oil. This prevents you from setting up all pipes for water for "advanced oil processing" - after researching advanced oil processing you are forced to make pipe changes in addition of changing recipe. This is inconsistent with other aspects of playing factorio: with assemblers you can set any recipe, worst case it will be missing ingredients, and then fluids: cannot change recipe because of fluid mixing, try first removing half of pipes, change recipe then setup pipes again

@coderpatsy: no, chemical plants are connected only to other chemical plants and because they have recipe they force fluid-type for pipes

[factoriouzr]

I agree this is not implemented well. I would rather have fluid mixing the way it was then this annoying limitation. Even better is if this bug is just fixed .

[cellular]

Yeah, this is incredibly annoying and stupid, and has bitten me repeatedly when trying to fill in ghosted buildings in PyMods (since the buildings in that mod are expensive relative to pipes). The easiest "correct" behaviour would be to check on recipe selection whether there's any valid rotation of the entity which doesn't cause a fluid mixing error, and if so rotate to match it.

[Absolute]

May be it is better to just exclude all inputs from the mixing check...

[GlassDeviant]

It's not about inputs. They have put the cart before the horse, by defining pipe contents based on what the machine expects to be coming in, so you can't switch the recipe because the new recipe wants to redefine an input that is being defined by the existing recipe. The more I look at it, the more ridiculous it seems. The contents of a pipe, to be even remotely realistic, should be defined by only one thing: what is being put into it. If there is something already in a pipe and you try to put something else in, then I have no problem with being told I can't do that, but to base it on the receiving machine's expectations just blows my mind. I'm not a huge stickler for overdoing realism in games, especially when it's at the expense of gameplay, but this devalues both realism and gameplay.

[drNokard]

It's not about inputs. They have put the cart before the horse, by defining pipe contents based on what the machine expects to be coming in, so you can't switch the recipe because the new recipe wants to redefine an input that is being defined by the existing recipe. The more I look at it, the more ridiculous it seems. The contents of a pipe, to be even remotely realistic, should be defined by only one thing: what is being put into it. If there is something already in a pipe and you try to put something else in, then I have no problem with being told I can't do that, but to base it on the receiving machine's expectations just blows my mind. I'm not a huge stickler for overdoing realism in games, especially when it's at the expense of gameplay, but this devalues both realism and gameplay.

I totally agree, this is exactlry what I meant.
But since this topic is on "not a bug", I doubt it will get a second chance.

[mrvn]

It's not about inputs. They have put the cart before the horse, by defining pipe contents based on what the machine expects to be coming in, so you can't switch the recipe because the new recipe wants to redefine an input that is being defined by the existing recipe. The more I look at it, the more ridiculous it seems. The contents of a pipe, to be even remotely realistic, should be defined by only one thing: what is being put into it. If there is something already in a pipe and you try to put something else in, then I have no problem with being told I can't do that, but to base it on the receiving machine's expectations just blows my mind. I'm not a huge stickler for overdoing realism in games, especially when it's at the expense of gameplay, but this devalues both realism and gameplay.

I totally agree, this is exactlry what I meant.
But since this topic is on "not a bug", I doubt it will get a second chance.

To be fair the reported problem has that the output of the chemical plants prevents the change in recipe.

I also have to disagree that "defining pipe contents based on what the machine expects" is wrong. I've setup a big refinery and then accidentally connected water to the crude oil pipe or vice versa. Then the whole pipe system is flooded with water and you have to deconstruct it all again. By connecting a fluid box to a pipe you are declaring the intended use and I like that the pipe will show what that use is going to be.

The problem comes with changing recipes, especially with recipes that you could switch without altering the pipe. Like oil processing and advanced oil processing. Or oil cracking and solid fuel. And this applies to outputs and inputs. Because when you change a recipe the inputs will flow back into the pipe so they are temporarily a output too.


Thinking about it yet again I might suggest the following compromise:

1) When the first fluid box connects to a pipe it will show the type of the expected liquid.
2) Connecting to a pipe with the wrong type fails on first try (connecting pipes, changing recipes, ...)
3) If the pipe is empty a second try following the first to mix fluids will succeed.
4) Any fluid put into a pipe system locks the type of the type.
5) Fluid boxes will not flow into pipes of a different type.
6) If a fluid box is disconnected from an empty pipe then it picks a random fluid box that is still connected ant takes its type or becomes typeless.

[invisus]

Thinking about it yet again I might suggest the following compromise:

1) When the first fluid box connects to a pipe it will show the type of the expected liquid.
2) Connecting to a pipe with the wrong type fails on first try (connecting pipes, changing recipes, ...)
3) If the pipe is empty a second try following the first to mix fluids will succeed.
4) Any fluid put into a pipe system locks the type of the type.
5) Fluid boxes will not flow into pipes of a different type.
6) If a fluid box is disconnected from an empty pipe then it picks a random fluid box that is still connected ant takes its type or becomes typeless.

I hope something like this is workable, I think this sounds like a great compromise.