[raiguard][2.1.8] Fluid is not shared evenly

[raiguard]

I am afraid that it does not fix the plan where the far most consumer may never receive fluid. I would prefer these 3 cases to work the same, like they did in 2.0, I think it was easier to figure out for new and casual player. The 2.1 change may make the EM Plant not an easy replaceament for Assembler builder Blue Circuit for example.



The fix allow the tank not to wait to have many K of fluid before being used, but it does not change the main concerns I had in my original post.

The distance has no bearing on whether or not it receives fluid - it's simply whichever entity updates first, which is dependent on the entity build order. And yes, I am aware of this, which is why this bug report is not in the resolved section.

[Filcius]

Thank you for the update. Good luck figuring this out Raiguard, have a wonderful day

[CryptoWyvern]

I see raiguard's name on a lot of software and blog posts about factorio that I enjoy on what seem to be a wide variety of areas. Just tossing that out there

[raiguard]

I have been thinking about this for a long time, and the solution I am leaning towards is to re-introduce isolated buffers for passthrough entities as it was in 2.0, but setting the volume of the segment portion of such an entity to zero. This solves the double-fluids and hidden-buffers issues nicely and makes passthrough entities behave identically to directional entities again, but introduces some new complexities.

A segment's volume is entirely made up of the pipes, underground pipes, and storage tanks comprising it. Thus, if you have a segment with entirely boilers, the segment has zero volume, so the boilers must pull directly from the sources feeding the segment:

08-06-2026, 16-01-56.png (142.67 KiB) Viewed 851 times

And if you add a pipe, they must switch to pulling from that pipe instead:

08-06-2026, 16-02-41.png (165.46 KiB) Viewed 851 times

This could cause potentially unexpected bottlenecks at high flow rates (>6000/s) since in the second case the available fluid in the segment is only 100. But that is already the case for non-passthrough entities, so at least it would be consistent.

This would require significant refactoring to accomplish. Fortunately, I was already planning on a major refactor, as the current fluid code is a giant pile of hacks and band-aids. This would also open a doorway to removing the fluid mixing warnings, which some people have expressed a desire for, but I would like to keep them if possible (with a few tweaks to fix issues with modded entities).

Edit: This is the topology with two pipes. Pipes and storage tanks are merged together, but other entities are not.

08-06-2026, 16-14-30.png (192.14 KiB) Viewed 835 times

Multiple producers and consumers with no pipes:

08-06-2026, 16-29-42.png (198.67 KiB) Viewed 815 times

Multiple producers and consumers with pipes:

08-06-2026, 16-36-40.png (238.14 KiB) Viewed 811 times

[Nauviax]

Would this mean reverting the current thruster behaviour too? I don’t really have any strong opinions on this topic, but I’ll miss how easy it is to run thrusters at 10% consistently. (Due to them not sucking in fluid up to 100%)

[raiguard]

Would this mean reverting the current thruster behaviour too? I don’t really have any strong opinions on this topic, but I’ll miss how easy it is to run thrusters at 10% consistently. (Due to them not sucking in fluid up to 100%)

Thrusters are an interesting case, because they already have a "performance curve" which adjusts their consumption based on their fullness ratio. It would make sense for them to remain as they are now, but it adds yet more complexity to the redesigned system, so I cannot say for sure on way or the other quite yet.

[Filcius]

In the first and second diagram, why is the pump not in the same segment as the pipe? If that would be the case, you would not hit the said limit at 6000/s

I have been thinking about this for a long time, and the solution I am leaning towards is to re-introduce isolated buffers for passthrough entities as it was in 2.0, but setting the volume of the segment portion of such an entity to zero. This solves the double-fluids and hidden-buffers issues nicely and makes passthrough entities behave identically to directional entities again, but introduces some new complexities.

A segment's volume is entirely made up of the pipes, underground pipes, and storage tanks comprising it. Thus, if you have a segment with entirely boilers, the segment has zero volume, so the boilers must pull directly from the sources feeding the segment:

08-06-2026, 16-01-56.png

And if you add a pipe, they must switch to pulling from that pipe instead:

08-06-2026, 16-02-41.png

This could cause potentially unexpected bottlenecks at high flow rates (>6000/s) since in the second case the available fluid in the segment is only 100. But that is already the case for non-passthrough entities, so at least it would be consistent.

This would require significant refactoring to accomplish. Fortunately, I was already planning on a major refactor, as the current fluid code is a giant pile of hacks and band-aids. This would also open a doorway to removing the fluid mixing warnings, which some people have expressed a desire for, but I would like to keep them if possible (with a few tweaks to fix issues with modded entities).

Edit: This is the topology with two pipes. Pipes and storage tanks are merged together, but other entities are not.

08-06-2026, 16-14-30.png

Multiple producers and consumers with no pipes:

08-06-2026, 16-29-42.png

Multiple producers and consumers with pipes:

08-06-2026, 16-36-40.png

[raiguard]

In the first and second diagram, why is the pump not in the same segment as the pipe? If that would be the case, you would not hit the said limit at 6000/s

Because that's not how the system works. Segments are a set of fluidboxes connected via bi-directional connections. Pumps have directional connections, so they are not joined into segments.

[embermctillhawk]

Would it be possible to add a radio button to the gui which toggles the fluid box between "Reserved" and "Shared"?
So in reserved mode, the fluid box dynamically changes size to one recipe instance, and in shared the fluid box is set to not hold any?
Or would that be too complicated?
Or have I misread the thread entirely and that wouldn't actually solve the complaint