[1.0.0] Fluid does not show in pipe window

[GluAp]

Hi there.

I was just setting up my advanced oil, when I discovered I coudn't connect a pipe system that should be empty (without assigned fluid) to one which has light oil. When I clicked the pipe the tooltip showed me that there actually was water in that pipesystem. But the pipe's fluid window didn't show water and was never connected to any water. Also, after flushing the pipe system it always refilled with water without being connected to any water source.

I could trace this behaviour to the chemical plant, which was setup for light oil to solid fuel processing. Water was already connected to the corresponding (water) input. But seemingly the chemical plant works as some kind of connector that assigns a type of fluid connected to it to every other pipe segment connected to the other input. But it will actually never fill the other pipe with the fluid.

This only happens, if the set recipe has the same input requirement on both inputs. I guess I can somewhat understand the reason for this behaviour. But on the other hand it makes some setups impossible which intuitively should work without this problem. And I think, that I used this exact setup in 0.17 and it worked(?).

This screenshot should show you what the problem is.

I'm a picture

fluuuuuuuid.png (3.27 MiB) Viewed 1705 times

[Loewchen]

Post the save please.

[boskid]

Thanks for the report. Everything here is fine. Due to the way pipes are working internally, when you have chemical plant (craftin machine) with mutiple input pipes for the same ingredient or multiple output pipes for same product, those inputs or outputs are considered as connected internally, however fluid can flow in only one direction. Because they are connected internally, connected pipes are merged into single fluid system and the pipe gui shows content of the whole fluid system ignoring the flow restrictions.

[Squelch]

I have had this issue too, and would like to give reserved confirmation and a possible explanation.

I encountered this in a modded game where a factory had multiple inputs of the same fluid in one recipe, but reused one of them for another recipe. If a pipe passed by both inputs such that it connected to both, same fluid inputs, and then the recipe changed, the changed input will "leak" into the pipe. This happens regardless of whether the pipe is purged first, and will continue to constantly contaminate the pipe with the wrong fluid. I could not find an example in the vanilla game that exhibits this behaviour due to the fact that any multiple inputs of the same fluid type are avoided (possibly for this reason) Conversely, the factory appears to reject the incorrect fluid in the pipe, so therefore does not become contaminated itself. This rather indicates that there might be a flaw in the connection logic that allows inputs to output for a few ticks at a time. The fluid amounts are small, but accumulate over time.

The closest example I could find is the basic oil refinery to advanced oil refinery, where the second crude oil input is changed to water. I have not considered that this could be reported as a bug because there is no other way to connect the refinery for both fluids for proper operation. However, it can be recreated by;

1. Placing two refineries close together.
2. Connecting crude oil to three of the four inputs.
3. Setting both refineries to use the basic recipe.
4. Change the singularly connected refinery's recipe to advanced with the corresponding input connected to water

Result:
The basic refinery will end failing due to contamination of the oil pipe with water. It does not accept water, but the input will end up blocked by the water in the pipe from the advanced refineries input.

This scenario was never possible while the connection logic blocked being able to switch recipes that would result in one of the inputs on the basic refinery being connected to water. It is also not possible to connect the pipes after the recipe has been changed. I would postulate that this is the result of some legacy logic from the prior method that did allow pipes to be contaminated.

It does seem that fluid inputs will leak out under some circumstances, and this only appears to affect mods that have multiple same inputs and multiple recipes. The example shown in the image is an artificial recreation, along with my reproduction, and wouldn't expect either to work, but does demonstrate that an unexpected leak occurs between inputs. The savegame, when it arrives, should show the problem. I'm not able to create one with my scenario above at this time, but I hope the information I supply helps.

[Edit to remove incorrect assertion]

[Squelch]

It seems I crossed posts with you @boskid.

While I understand your reply and marking it as "not a bug" and hence my reluctance to report it before. Would you please review the extra information that I provide? I think there is an underlying issue that is a gotcha for modified games, and the rare misconnections in vanilla.


[Edit] I'm doing this from memory and realise that the repro I suggest isn't possible after all. This is unlikely to happen in a vanilla game, but is definitely possible in a modded game. I suspect that it probably deserves a separate report - if at all...

[boskid]

Changing recipe pushes fluid out of fluidbox and this is intended behavior.

Multiple inputs leading to the same fluidbox and so merging fluid systems is also intended. To let fluid flow into both inputs, when all fluid systems are updated in parallel (multiple threads), it is not allowed to transfer fluid from 2 different fluid systems to a single fluid box because that would be a race condition and could lead to desyncs. Because of this, if fluid box is connected to 2 other pipes (not connected externally), it will merge them into single fluid system. I see no good reason into doing some internal separation introducing another layer of "fluid system update group" so that inputs would be in separate fluid systems but would be guaranteed to be updated by the same thread in the same order.

If you have fluids mixed, fix pipes, flush wrong fluid and continue playing.

[Squelch]

Changing recipe pushes fluid out of fluidbox and this is intended behavior.

Multiple inputs leading to the same fluidbox and so merging fluid systems is also intended. To let fluid flow into both inputs, when all fluid systems are updated in parallel (multiple threads), it is not allowed to transfer fluid from 2 different fluid systems to a single fluid box because that would be a race condition and could lead to desyncs. Because of this, if fluid box is connected to 2 other pipes (not connected externally), it will merge them into single fluid system. I see no good reason into doing some internal separation introducing another layer of "fluid system update group" so that inputs would be in separate fluid systems but would be guaranteed to be updated by the same thread in the same order.

Understood, and as I have already pointed out, this really only affects mods with three or more fluid inputs where one can be changed due to a change in recipe. This scenario seems to have been avoided in the vanilla game, so it probably falls within the affected mod, or needs a mod api request.

If you have fluids mixed, fix pipes, flush wrong fluid and continue playing.

Unfortunately, the contamination will continue even after flushing as noted above. I'll try and work up a simple reproduction to demonstrate the result, but in another report as it is related but not quite the same as the OP. However, the image in the OP does show that water is present in the pipes upstream from the initial input, so therefore could only have flowed in the wrong direction via the input. My problem is an edge case, but I suspect will be encountered again. It took me a long time debugging my factory to isolate the problem when initially encountered, and was the result of a change in the base recipes for the mod, and existing pipe connections being incorrect as a result. It is still possible to produce the problem, but never in a vanilla game.

[GluAp]

Thank you boskid for the explanation.

I'm pretty sure I read something similar to this some time ago in a FFF but couldn't remember anymore.

To conclude this topic: It will never be possible to build (or rather use) this version.

I'm a picture, tooo.

fluuuuuuuid2.png (1.65 MiB) Viewed 1608 times

You would always have to build it like that version (or similar), correct?

I'm a butterfly.

fluuuuuuuid3.png (1.31 MiB) Viewed 1608 times