This one is a good catch, a very realistic and also serious issue. Thanks.
It is quite certainly connected to the 74269. I will check it out now.

The annoying situation in 0.16 happened when you tried to pump out fluid from pipes, and the pipes closest to the fluid went to 0, while pipes farther from the pump stayed at 0.0..1 - therefore preventing you from ever being able to pump that fluid out.
(IIRC this situation didn't always happen ...

I figured out a fix for it with low performance impact. It is ugly but since it will (hopefully) soon all be replaced, then what the fuck.

Hi Fuzen,
the report is quite detailed but I can't find any issue. It certainly does not crash and I am not sure what else is supposed to be wrong.
With the first reproduction - removing the machine erases the water so the water step is irrelevant. And so is a water pipe two tiles away.
The crash is ...

This is actually a very funny bug. It is caused by an oversimplification and asymmetry of the current fluid algorithm and a very special combination of the pipe order and fluid batch size and some constants of the algo. Notice that if you put the pipe to the left of the machine, it will work again ...

Hi, thanks for the report. Quite a simple bug related to the assembler only having one fluidbox when disabled.

We asking about liquids flow in pipes , that works kinda bad now. We see a pipe of a good diameter (I'd say about one meter+ visually, and it performs so badly. :-(


Isn’t it less than 1m diameter considering the tiles are 1m square?

Still, yes, it’d be nice to have the fluid mechanics ...

Yes, preventing the action in the first place would be nice, but it is not realistic.
"user can't fix the issue by rotation" - deleting the pipe is what I would think of to fix it, not rotating the pipe.
I left it only at the message as this issue is really rare - before it would cause mixing and we ...

Yes, the gui crashes when the fluids are already in a broken state. That is known.

I have blocked upgrading anything that has a fluid system with the block.

For this one, I have to unfortunately do won't fix. It is not really something people would realistically encounter and rewriting several places in the code, force change logic, is just not worth it.

So all these three reports (this, https://forums.factorio.com/viewtopic.php?f=182&t=73840 , https://forums.factorio.com/viewtopic.php?f=182&t=73890 ) were very similar in that the issue would require rewriting and complicating the current code beyond what is reasonable, considering how rare these ...

Resolved this by preventing the action altogether if the blocked connection is in play. See viewtopic.php?f=182&t=73884 for more.

Resolved this by preventing the action altogether if the blocked connection is in play. See viewtopic.php?f=182&t=73884 for more.

Yeah I would really love that, get rid of this whole blocked pipe thing. But that is the last resort and I don't want to do that when I have already sunk so much work into it

Oktokolo solving problems by just splitting the pipes usually does not solve the actual problem. While having the better pipe building would be nice, it is not good a solution to mixing problems. (not like my solution is good, but it does not take two weeks to make)

I remember that I spent long time fixing this one with pipes connecting wrong during the hidden prototype replacement.

I am quite familiar with it as this "clamping" is internally quite sick and created some difficult bug.

What do you mean by clamping?
We have the same number of posts.

Isn't that what any computer graphics do?