[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.