[raiguard][2.1.8] Fluid is not shared evenly

[GN89]

A few technical counterarguments regarding internal buffers and thruster control:

1. Continuous recipes don't need buffers: Shifting pass-through machines to a per-tick continuous consumption model completely eliminates the need for any internal fluid buffers. A common concern with this approach is what happens when a recipe is canceled mid-craft. However, in Factorio, input fluids are already wiped irreversibly upon recipe cancellation anyway, so this behavior introduces no new issues or resource voids. It achieves the smoothness of continuous consumers without cluttering the engine with hidden volumes or artificial percentage thresholds.
2. The thruster logic remains a complex puzzle: The idea that reading pipeline fullness directly via wires makes space platform throttling "too simple" is a misconception. The relationship between thrust and pipeline fullness is non-linear. A simple wire connection to a pump with a fixed percentage cutoff will cause the platform's speed to oscillate violently due to mass and acceleration physics. Achieving precise speed control and preventing overshooting still absolutely requires advanced circuit design, precise timers, or PWM.
3. Benefits for both casual and hardcore players: This fluid mechanic actually creates a perfect balance for the community. Casual players are no longer punished with erratic burst-thrusting and can just look up optimized baseline values from a guide for a smoother ride. Meanwhile, hardcore players still have a deep, interesting engineering challenge to solve if they want to build flawless, predictive speed-regulation systems.

[Bootstrap]

[*] The thruster logic remains a complex puzzle: The idea that reading pipeline fullness directly via wires makes space platform throttling "too simple" is a misconception. The relationship between thrust and pipeline fullness is non-linear. A simple wire connection to a pump with a fixed percentage cutoff will cause the platform's speed to oscillate violently due to mass and acceleration physics. Achieving precise speed control and preventing overshooting still absolutely requires advanced circuit design, precise timers, or PWM.
[/list]

I like the idea of reading from the pipes themselves instead of needing a tank, but my concern is that if there is a tank and the thrusters fill to how full the pipe is, then they'll automatically reach efficient cruising speed because low fill means even lower consumption rate & high fill means even higher consumption rate. So you'll slow down until you meet consumption that matches production which is one of many answers to the current "max thrust until empty" problem.

[AssaultRaven]

1. The thruster logic remains a complex puzzle: The idea that reading pipeline fullness directly via wires makes space platform throttling "too simple" is a misconception. The relationship between thrust and pipeline fullness is non-linear. A simple wire connection to a pump with a fixed percentage cutoff will cause the platform's speed to oscillate violently due to mass and acceleration physics. Achieving precise speed control and preventing overshooting still absolutely requires advanced circuit design, precise timers, or PWM.

"oscillate violently"? That's just not true. I tested it before I made my earlier post about it by testing my old PWM system and then replacing it with the simple system I described, and the pumps are able to hold the pipe level and thrust dead steady. More so than my PWM pumps were.

You're right that achieving "precise speed control" requires more work, even for a given platform, because gravity affects you in opposite directions on each half of the orbital transfer. So without compensating for that you'll go slower on the start half and faster on the end half. But within each leg speed was more steady with the simple system than the PWM system. The PWM was still pretty steady, but the simple system was even more so. (PWM speed oscillated on the depart leg between 84.10 km/s and 84.37 km/s, compared to steady 84.24 km/s at equilibrium for the new system after a few seconds of tweaking the target level.)

But the first step, throttling, which ended up being all I really needed for an entire run, used to be a puzzle (and a deliberate one, that they removed wires from thrusters to force), and now it's not.

[GN89]

While the pass-through fluid mechanic makes thruster control feel more "casual", it is definitely user-friendly and serves as a great entry point. Early space platforms are notoriously clumsy and prone to smashing into asteroids if they go too fast. For a general audience or a first playthrough, having a simpler way to throttle down is a lifesaver.

Before I redesigned my own PWM system, handling the speed oscillations was quite a chore. The new pipeline logic, especially when combined with the new "else" branch introduced in the 2.1.9 Decider Combinator, certainly simplifies speed regulation. For instance, my previous PWM setup required several combinators just to check 4 speed ranges; now it can be compressed down to just 2 devices. But we should ask ourselves: how many players actually complete the game entirely and reach the shattered planet? Such simplifications don't push players away; they make the game more accessible, while leaving plenty of room for hardcore optimization when flying to the edge of the solar system and further to the shattered planet.

Returning to the assembly machine (EM-plant) issue, we must keep in mind that overhaul modifications can introduce extreme speed modules and near-instant recipes, pushing crafting speeds to be faster than 1 tick per craft. In this specific scenario, a continuous (streaming) recipe model is the best option.

From the engine's perspective, it all comes down to checking if there is enough fluid for the current tick of crafting, and if so, executing it. Of course, with a naive implementation, if a machine is supposed to complete 2 crafts in a single tick but the pipe only has enough fluid for 1, neither craft would execute. But this is a solvable math problem (e.g., calculating a unified fractional consumption rate per tick).

[Bootstrap]

While the pass-through fluid mechanic makes thruster control feel more "casual", it is definitely user-friendly and serves as a great entry point. Early space platforms are notoriously clumsy and prone to smashing into asteroids if they go too fast. For a general audience or a first playthrough, having a simpler way to throttle down is a lifesaver.

Before I redesigned my own PWM system, handling the speed oscillations was quite a chore. The new pipeline logic, especially when combined with the new "else" branch introduced in the 2.1.9 Decider Combinator, certainly simplifies speed regulation. For instance, my previous PWM setup required several combinators just to check 4 speed ranges; now it can be compressed down to just 2 devices. But we should ask ourselves: how many players actually complete the game entirely and reach the shattered planet? Such simplifications don't push players away; they make the game more accessible, while leaving plenty of room for hardcore optimization when flying to the edge of the solar system and further to the shattered planet.

Returning to the assembly machine (EM-plant) issue, we must keep in mind that overhaul modifications can introduce extreme speed modules and near-instant recipes, pushing crafting speeds to be faster than 1 tick per craft. In this specific scenario, a continuous (streaming) recipe model is the best option.

From the engine's perspective, it all comes down to checking if there is enough fluid for the current tick of crafting, and if so, executing it. Of course, with a naive implementation, if a machine is supposed to complete 2 crafts in a single tick but the pipe only has enough fluid for 1, neither craft would execute. But this is a solvable math problem (e.g., calculating a unified fractional consumption rate per tick).

I'd be fine with the new fluid system IF it applied to all machines. Right now, it only meaningfully changes the behavior of a subset of recipes for one machine & that's far more frustrating than needing to figure out how to throttle a thruster (and making that easier would be easiest by allowing wire connections anyway).

[GN89]

I have to disagree with making this model strictly global for all machines, as doing so would seriously limit flexibility for overhaul mods. Keeping it as a toggleable property allows modders to design unique batch-processing setups and complex factories that actually rely on discrete buffers.

And hey, if you really miss the old mechanics, you can always just slap pumps right in front of every thruster input. Sure, you'll need way more pipes and space, but problem solved!

[Bootstrap]

I have to disagree with making this model strictly global for all machines, as doing so would seriously limit flexibility for overhaul mods. Keeping it as a toggleable property allows modders to design unique batch-processing setups and complex factories that actually rely on discrete buffers.

And hey, if you really miss the old mechanics, you can always just slap pumps right in front of every thruster input. Sure, you'll need way more pipes and space, but problem solved!

Again, I don't care about how it's working under the hood, but the user's experience with fluids should be consistent instead of having one machine that acts differently because the devs didn't like that people figured out sushi pipes.

[nzer]

This doesn't seem like a huge deal to me given the answer is to just add a pump, but I agree that it definitely cannot be how the system works. Even ignoring that it makes passthrough buildings work differently than non-passthrough buildings, the behavior just doesn't make any sense. The central conceit of fluids 2.0 is that if you're providing sufficient input to the pipe network, everything "just works." This breaks that principle by introducing the requirement that you saturate the pipe network to whatever completely arbitrary level is required by the craft in question, which is both unintuitive and inconsistent from one recipe to the next. I'm all for making fluids more logistically involved, in theory, but this is a bad way of doing that.

I'm not an expert on how the system works, but intuitively I'm not sure why passthrough and non-passthrough buildings would need to interact with the rest of the network differently in the first place. There's functionally no difference between connecting the buildings in series with passthrough, and connecting them in parallel to an existing pipe. So... just make that how the passthrough works? Give the buildings a dummy pipe segment internally, or whatever, so they can pull in the same way non-passthrough buildings do.

[AntiElitz]

That all entities draw fluids equally was fixign a lot of things in 2.0 and was one of the best features. I don't liek that beeing goen either. IMO all entities shall draw inputs equally from the entire fluid network (not just the close pipe) to also avoid fluid throughput issues.

[GN89]

To build upon what @AntiElitz mentioned, a continuous (per-tick) consumption model solves this "uneven sharing" beautifully while respecting fluid physics.

In Factorio, fluid injection is inherently discrete — upstream machines dump batches into the pipe instantly when their craft finishes.

Pros of the streaming model:
* No greedy buffers: The first machine only sips a tiny fraction needed for that single tick, allowing the rest of the fluid wave to pass through to downstream machines instantly.
* Consistent with Fluids 2.0: Eliminates the artificial requirement to 100% saturate pipes just to kickstart the assembly line.

Cons/Limitations:
* Not a magic fix for shortages: If the injected fluid batch is physically too small, it will still only satisfy the first few machines in the simulation queue before running dry. It distributes the wave evenly, but it cannot duplicate resources.

[nzer]

Give the buildings a dummy pipe segment internally, or whatever, so they can pull in the same way non-passthrough buildings do.

I reread the FFF, and I guess this is how the system worked before?

My thinking now is that the change to remove the internal fluid buffer was just unnecessary to begin with. The way the FFF describes it, fluid mixing prevention and fixing the 6000 units/tick limit were separate changes that should still be able to work properly with the internal buffer. So the only reason for removing the internal buffer is that it simplifies the implementation, which is not a good enough reason.

The simplest thing to do here is to just put the buffer back. Maybe the new behavior can be kept for thrusters, because in that use case specifically it's very convenient.

[Bootstrap]

Give the buildings a dummy pipe segment internally, or whatever, so they can pull in the same way non-passthrough buildings do.

I reread the FFF, and I guess this is how the system worked before?

My thinking now is that the change to remove the internal fluid buffer was just unnecessary to begin with. The way the FFF describes it, fluid mixing prevention and fixing the 6000 units/tick limit were separate changes that should still be able to work properly with the internal buffer. So the only reason for removing the internal buffer is that it simplifies the implementation, which is not a good enough reason.

The simplest thing to do here is to just put the buffer back. Maybe the new behavior can be kept for thrusters, because in that use case specifically it's very convenient.

Heck, keep it for all the continuous draw buildings (fusion, thrusters, boilers, etc). But if having 90 in the machine for a recipe that won't start until it has 90 and requires that the connected tank have 22500, something is wrong.

[Villfuk02]

07-06-2026, 17-30-44.png (291.32 KiB) Viewed 2702 times

Anything wrong with doing it like this?
The main pipeline capacity is the capacity of all the pipes plus the passthrough fluidboxes, the input-only and output-only buffers are separate. However, the input buffers fill from the pipeline only when the fraction they are filled to is smaller than the fraction of the amount necessary to fill the pass-through macine fluidboxes of the pipeline. This is the simplest solution I could think of that would distribute fluid somewhat evenly and still prioritizes machine inputs (both input-only and pass-through) over fluid tanks and such. No continuous consumption needed.

[DarkLordKelvin]

non-sucking machines could simply be treated as a pipeline segment with an internal buffer size large enough to hold at least one (or even more) craft's worth of fluid. This would solve the issue of lacking a crafting buffer while keeping the pass-through connection fully operational.The only catch here is that if the overall system technically has enough fluid for the recipe, but the level within that specific segment falls below the required threshold, the craft won't trigger.

This is exactly how it works right now and is exactly the behavior that everyone is complaining about.

Do I understand that this "fluid passthrough issue" only causes a major impact in situations where EM plants are starved for fluid resources? So as long there is sufficient upstream production, everything works as expected? Or are there other situations where EM plant factories with fluid passthroughs produce unexpected/inconsistent behavior in 2.1?

[1nc0mpetence]

I am also going to chime in, as my posted bug report is a duplicate to this.
134911

For me it is very unintuitive, that for the machines, that allow flow through, fluids can flow back out of the machine, and adding a tank even worsens this issue.
From my point of view (as a casual player) the 2.0 changes were just what i wanted, and i never used sushi pipes.
I would expect all machines to draw equally and once a fluid is in a machine, it can not flow out again. I would also expect all machines to draw as much as they can, and not stay at the same "level" that the pipe next to it has - which is impacted by adding a tank.
For me this mostly applies to the electromagnetic plant, but I have noticed this also for the thrusters.

[Bootstrap]

non-sucking machines could simply be treated as a pipeline segment with an internal buffer size large enough to hold at least one (or even more) craft's worth of fluid. This would solve the issue of lacking a crafting buffer while keeping the pass-through connection fully operational.The only catch here is that if the overall system technically has enough fluid for the recipe, but the level within that specific segment falls below the required threshold, the craft won't trigger.

This is exactly how it works right now and is exactly the behavior that everyone is complaining about.

Do I understand that this "fluid passthrough issue" only causes a major impact in situations where EM plants are starved for fluid resources? So as long there is sufficient upstream production, everything works as expected? Or are there other situations where EM plant factories with fluid passthroughs produce unexpected/inconsistent behavior in 2.1?

Right now, 6k electrolyte in a tank is not enough to craft a tesla gun which only requires 100 or a tesla turret which needs 500. The gun turns on at ~6.2k and the turret starts crafting at just over 8.3k. So you can have sufficient fluid in the system but it's insufficient for that building because it's different from any other fluid consumer in the game for minimal benefit.

[raiguard]

For 2.1.11 I have changed passthrough assembling machines (EM plants) to consider the whole fluid segment as available fluid for crafting. This will serve well enough until I can come up with a more permanent solution.

07-13-2026, 12-32-20.png (490.45 KiB) Viewed 2093 times

[Filcius]

Thank you Raiguard for checking into this.

I don't quite understand the impact on this change regarding some specific scenarios, I will be happy to try it out in 2.1.11 when it comes out.

[agmike]

Thank you for the fix.

I remember before 1.0 there was discussion about two step order-independent fluid calculations; IIRC prototypes worked well. Were there some other problems with it, like presumably performance due to needing to pass twice over pipe entities?

[Filcius]

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.