[1.1.32] Cannot connect systems with SAME fluids

[roninpawn]

In 1.1.32 (build 58364, win64)

I have a light-oil-cracking chemical plant with logic. If light oil > petro gas 'L'=1... if 'L'==1, turn on light-oil cracking.
After quite a while with just the one plant, I tried to add a second next to it. But the petro gas output won't connect to any other petro gas line.
Throwing the "cannot connect systems with different fluids" notice.

factorio fluid bug.jpg (464.49 KiB) Viewed 9579 times

Petro won't connect to petro.
Destroyed and rebuilt the new plant and the pipes... No joy.
Persists across game restart.

[roninpawn]

Adding save file and log.

[Silari]

The chemical plant on the lower right has the petroleum gas line hooked up to it's water input. That's enough for the game to consider those fluid boxes joined and there to be water and gas in there. Clicking on the pipes would show you the water. Remove the pipe to the chemical plant and it'll work.

Building inputs count as a connection even if the input is for a different fluid, even if it's the inputs of two different buildings touching.


Here's an example screenshot:

fluidsystems.jpg (223.63 KiB) Viewed 9557 times

As you can tell from looking at the pipe windows (and was in the entity tooltip before I cut the picture down), the highlighted pipe and connected pipes are all completely empty and only hooked up to the sulfuric acid input of the leftmost chemical plant. However because the other input of the plant is touching the water input of the second plant, and that plant's other water input is hooked up to a pipe system with water, the completely empty pipe system is considered to have water in it for the purposes of the fluid mixing check.

[Serenity]

By the way, if you want to turn cracking on and off it's easier to switch pumps instead of using power switches

[roninpawn]

Thank you for that.
I stared at it for a while thinking I had to be missing something before posting it as a bug. And I was!
That said, while maybe I wouldn't call this a Bug with a capital-B, it's certainly some color and flavor of "design issue."

I figure I got to this fluid-locked state after changing which plant was doing what -- to move certain facilities down the line. One of the buildings that used to do sulfur took over acid. It still had the input it needed to function so it came online and I never noticed the unneeded petro connection. That's what I figure anyway... So, let's look at this.

--- The Problem ---

If the pipe-placement/connection rules allow a player to change factories to a new type while there's filled-invalid connections at its inputs, you need to do some error-handling there. If an overlap like the one described is going to invalidate connections to the entire fluid system it's connected to (which could be vast and share hundreds of connection points) you need to point to the source of that problem for the player -- highlight any joint that creates a fluid mixture, flash it red; point an arrow in it's direction if it's off-screen. That kind of thing.

Alternately, if you want to leave it for the player to find their own error, at a minimum you have to provide a less generic message for the reason a connection can't be made. Because visually, the alt-mode of the game (and even without it, the fluid-filled-pipe sprite) tells the player in no uncertain terms that the line only contains one "fluid." More importantly, the top-level ruleset of the game strongly implies that it is impossible for the player to connect two different fluid systems, as if you try it, you're given the exact same message seen here.

And that's how you get this circumstance, where I wind up on the forums filing this as a bug report. Because fundamentally the game is telling the player two different things at the same time. Speaking from both sides of its mouth.

--- Solutions? ---

The fact that the water "connection" (or the line-impurity) didn't prevent other factories connected to it from producing says to me that the implementation of pipes doesn't really care that there's an improper fluid connection somewhere on the line. I'm guessing it operates based on whatever it was defined as in the moment it was first filled, and nothing can override that. I'm also guessing that the intention was to create a generic class for these networks without a lot of conditional logic baked in, and then just prevent the user from breaking intended usage by limiting their interactions via the UI. But then the UI of factories ended up needing to break that intention, because the alternative of restricting factory type assignment by an input-output check would produce a more confusing and less intuitive system.

But I digress. A pipe can't be connected to another with different 'contents' through the UI, but it CAN end up in that state through a factory. After which any placement-check of "if pipesys[0].contents == pipesys[1].contents" will always return false because 'petro' is not equal to 'petro;water.'

(Although... if you setup two pipe networks, breaking them both in the same way, with water AND gas in the line. Hmm... Can I connect petro;water to petro;water? And isn't this all starting to sound bug-like, now!)

Anyway, solutions: Create a specific "mixed-pipe state" that checks the in-out connections of a factory on assignment. If the contents become "impure" on factory reassignment / connection (multiple contents in the line) define that pipe as a new network with contents = "mixed." That network would have it's own sprite and alt-mode logo to provide a visual indication to the player where an error is. Boom. That solves the lack of communication to the player problem.

That solution could also be used to prevent this from really BEING a problem at all. If the single petro-pipe that touched water through a factory reassignment becomes its own "mixed" network, it could be functionally cordoned off to itself, maintaining the usability (and connection validity) of everything else. The cordoned pipe would be visually connected, but not considered attached to the line. And the class properties of 'mixed' lines could restrict any and all interaction with them, except to be removed.

Were that the state of things, I wouldn't have had an issue attaching petro to petro at a completely different location on the line because only the pipe touching water would be mixed. I would have also had a clear visual indication that I'd left a pipe somewhere I shouldn't have by the new alt-mode and sprite images for a mixed-pipe. AND, even if I never-ever-ever noticed that wrong connection through those visuals... it wouldn't have mattered at all. Everything else would have remained completely functional.

And all that implementation would need is a conditional check at factory assignment, a method that reassigns the single pipe section at an invalid input to be its own independent network, a few color swaps on existing sprites to indicate THIS PIPE NEEDS TO BE REMOVED, and a UI rule disallowing empty pipes to connect to 'mixed' networks. Outside that, the in-place rules would likely handle any other concern.

---

One way or another this is an "issue" that wants a better solution. The factories present a scenario where the player is able to break out of the intended UI-restriction on creating mixed-fluid pipe networks. After which, an entire - and potentially massive - fluid network ceases to be interactable until the one pipe on the line creating a mixed-state is found and eliminated. And despite that, no readily accessible visual communication with the player has been designed to show them where, or even what the problem is. What /does/ exist in the form of the floating error-text provides a message so generic that you have to have already had the problem and solved it once before to be able to infer that the error it's throwing might indicate something that's not even on-screen right now.

I might not have every guess I'm making at how these systems work, or what their intentions are exactly right, here. It's a lot of assumptions on my part.
But whether I've described a valid solution in the pile of text above -- I've definitely described a PROBLEM.

And, for the sake of getting around to fixing it, I'd auger to throw it on the pile of "bugs."

[Silari]

They already tried a very indepth fluid mixing prevention system. It got thrown out because there were far too many corner cases and workarounds and they spent way too much time on something that could still break. Now it's just a simple check when the player tries to place a pipe as a 'hey maybe you didn't mean this?' kinda thing. It'd be nice if inputs didn't count, but it is what it is.

You can easily troubleshoot the issue: clicking a pipe will show you what fluids are in the system, and by removing a pipe and seeing which side of the now split system has the issue you can track it down to any sources. It's how I found it in your map.

[roninpawn]

Well... Fair enough, then.
I'll add it to my impressively short list of design flaws in Factorio.

Hmm. Fluid mixing. So, 'F.'
Let's see... Yes, it'll slot in right here between 'Circuit logistics: One Computer = One Abacus' and 'Trains: My god what have you done to trains.'