[raiguard][2.1.8] Fluid is not shared evenly

[guardog]

I'm no specialist here, but assuming a pump attached before the EM plants fix the issue, could you simulate in the code that each EM (or passthrough) has an built-in "pump" from the pipeline to the EM input? This would pick-up fluid from the pipeline without affecting the general pipeline pressure. Just tossing a troubleshooting idea here

This has been explained by raiguard:

... even if I change EM plants to suck actively like directional connections, they won't be able to self-balance like directional connections do because they are operating directly on the segment, so the first machine to update will get the greatest share of fluid. There is literally nothing to be done about that.

I think someone should keep a canvas or whiteboard on this issue to curate all the problem statements so that we don't go in circle.

[AssaultRaven]

I should note, however, that even if I change EM plants to suck actively like directional connections, they won't be able to self-balance like directional connections do because they are operating directly on the segment, so the first machine to update will get the greatest share of fluid. There is literally nothing to be done about that.

Well, that's obviously not true, because "go back to the old system" is available. But setting that aside, I also just realized that if that's true then not only does it break the consistency of the 2.0 fluid overhaul, but by doing so in the EM plant specifically does so in exactly the context where operating under persistent fluid starvation is actually the norm for much of a game. Someone setting up a Fulgora base will now have the confusing issue of some random machines grabbing up more fluid in an unpredictable way.

And then what, build a network of PWM pumps to ensure even distribution between consumer groups? And even realizing you need to do that means understanding internal implementation details of why some consumers work different than others. Compared to before when balance within a segment just worked, this is a pretty big down-grade.

[Filcius]

I think someone should keep a canvas or whiteboard on this issue to curate all the problem statements so that we don't go in circle.

I think it is okay to give idea and let Raigard keep track of them. As a player, we can give our expectation from a gameplay point of view and let the developer think about the bigger picture.

[GN89]

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.

[raiguard]

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.

[GN89]

If a pipeline is considered a single fluid segment, we could rework throughput-crafting machines so that all crafting machines with fluid pass-through capabilities connected to this specific segment only activate when the total fluid amount in the system is equal to or greater than the combined consumption of all these entities. This is just a conceptual idea, and I am not entirely sure how it would impact UPS.The main upside to this approach is that all throughput entities would receive a sufficient amount of fluid simultaneously, regardless of the recipe. The downside, however, is synchronization: the entire system would end up running at the speed of the longest recipe. This could be optimized further to achieve more intuitive behavior, but likely at the cost of performance. Please don't crucify me for this!

[Aklo09]

Does this problem also affects Thrusters ?

[FasterJump]

Unpopular opinion: those complaining are the vocal minority / sheep effect.

To those having a problem with how it works in 2.1.8, let's consider this angle: If you are producing enough fluid, your fluid systems will be at least 10% full, and no machine will starve. Heck, it could even be 97.4% empty and it would still work. If your fluid system is 97.6% empty, the root cause of the issue isn't the EM plant not accessing these 2.4% drops of liquids in the pipe. I don't see any issue with the machine not working if its fluid system is 97.6% empty... If you have ever used a real life machine (such as a car, or an espresso machine) you will see that leaving it at 2.5% full will result in either not working, or critical engine damage.

@Aklo09 Yes, it affects thrusters. Thrusters will have lower acceleration (or speed assuming steady state) when the fluid system fill percentage is low. That's better in my opinion, more straightforward to control, and more buffer means smoother variations.

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

Well, not me. I am complaining about everyone! Players aren't always right.

[AssaultRaven]

To those having a problem with how it works in 2.1.8, let's consider this angle: If you are producing enough fluid, your fluid systems will be at least 10% full, and no machine will starve. Heck, it could even be 97.4% empty and it would still work. If your fluid system is 97.6% empty, the root cause of the issue isn't the EM plant not accessing these 2.4% drops of liquids in the pipe. I don't see any issue with the machine not working if its fluid system is 97.6% empty... If you have ever used a real life machine (such as a car, or an espresso machine) you will see that leaving it at 2.5% full will result in either not working, or critical engine damage.

Even if you accept that, why only apply it to pass-thru machines specifically? Shouldn't that just make you not like how every other machine handles it instead? Shouldn't the inconsistency bother your regardless?

[juliawtapp]

I am throwing my voice into the pile here too to say that I like the way passthroughs work now, and that maybe input-only pipes could be changed to act in a similar way to make them consistent.

My favourite use of the new passthrough pipes thus far has been that you can limit a thruster's fuel by simply limiting the fuel content of a pipeline, rather than by pulsing a pump to throttle the engine.

If players want to force fluid into a machine from a fluid system with a low level of fluid, that could be solved (as others have said) with pumps.

I do think it would make sense for fluid tanks to fill a pipe all the way up even if the tank isn't completely full, but I'm unsure if that's doable.

[robot256]

I like this idea a lot (making input only machines less greedy). It would put a little more thought back into the design of fluid systems. Pumps become very important when you want to "pressurize" high volume pipes. Plus it's just a prototype property change (I think).

The issue with storage tanks reducing the percent fill of every pipe is interesting. Not sure there's a solution in the existing system to fill all the pipes before filling the tanks. Seems like this is just more of a reminder to keep your storage separate from consumption, and to pressurize the tank outputs with pumps. Superficially this brings us back to how we normally played with the old fluid system, but without all the extra computations and inconsistencies.

[Bootstrap]

I am throwing my voice into the pile here too to say that I like the way passthroughs work now, and that maybe input-only pipes could be changed to act in a similar way to make them consistent.

My favourite use of the new passthrough pipes thus far has been that you can limit a thruster's fuel by simply limiting the fuel content of a pipeline, rather than by pulsing a pump to throttle the engine.

If players want to force fluid into a machine from a fluid system with a low level of fluid, that could be solved (as others have said) with pumps.

I do think it would make sense for fluid tanks to fill a pipe all the way up even if the tank isn't completely full, but I'm unsure if that's doable.

I'm pretty sure the change with respect to thrusters really just makes them run at their most efficient cruising speed by default instead of requiring smarts to have behavior better than "max thrust until empty, then best possible in bursts". So the change actually makes one puzzle less interesting while simultaneously making other behaviors less intuitive.

[zeldrakef]

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.

Surely having a dynamically sized buffer would alleviate the "level falls below the required threshold" issue? If the storage tank is only 50% full and as such a pipe contains 50/100, but the crafting recipe needs 200, the mini-storage-tank (i.e. buffer) inside the machine needs to calculate how big it needs to be based on how full the pipe is: 200 / (50%) = 400 (maybe add an extra margin on top for safety, so like 440), so its buffer needs to be 400 in order to be filled by the 50% pipe. Then if the pipe level drops (e.g. because there are lots of machines on the line), say to 25%, the buffer needs to update again: 200 / (25%) => a buffer of 800 to be filled by a 25% pipe.

Because each machine on the line will be proportionally filled with respect to its buffer, which in turn depends on its crafting amount, no one machine gets to hog all the fluid on the line.

hypothetical example: say a pipe+storage tank is 50% full, and three machines are on the line. Machine A needs 5 fluid to craft, Machine B needs 25 fluid, and Machine C needs 100 fluid to craft. The buffer sizes respectively are (5/50%), (25/50%),(100/50%) or 10, 50, and 200 respectively. If all the machines were completely empty (eg: they'd just finished their craft), then the flowrate in would be proportional to the buffer size: so Machine B gets 5 times as much fluid as A, and C gets 4 times as much fluid as B: which is exactly the ratios of the fluid needed in!

Then, if all the machines guzzling fluid from the pipe drops the fullness in the pipe to 25%, the machines recalculate their buffer to be 5/25%, 25/25%, 100/25% : that's 20, 100, and 400 respectively: still ensuring that B gets 5x as much as A and C gets 4x as much as B while still ensuring the machines get enough from the pipe to craft!


Calculating buffer size based on pipe % fullness may be computationally expensive, though.

[juliawtapp]

I am throwing my voice into the pile here too to say that I like the way passthroughs work now, and that maybe input-only pipes could be changed to act in a similar way to make them consistent.

My favourite use of the new passthrough pipes thus far has been that you can limit a thruster's fuel by simply limiting the fuel content of a pipeline, rather than by pulsing a pump to throttle the engine.

If players want to force fluid into a machine from a fluid system with a low level of fluid, that could be solved (as others have said) with pumps.

I do think it would make sense for fluid tanks to fill a pipe all the way up even if the tank isn't completely full, but I'm unsure if that's doable.

I'm pretty sure the change with respect to thrusters really just makes them run at their most efficient cruising speed by default instead of requiring smarts to have behavior better than "max thrust until empty, then best possible in bursts". So the change actually makes one puzzle less interesting while simultaneously making other behaviors less intuitive.

You still have to control the level of fluid in the system, it's just possible now to do so by throttling the chemical plants themselves.

[GN89]

No matter how much I think about this issue, the only easy fix seems to be bringing back the hidden buffer. However, I actually think the current mechanic is quite good. It brings a fresh challenge to logistics. Also, if thrusters use the same mechanic (I haven't updated the game yet), it makes their control way more precise. The engine won't try to suck all the fluid from the system into its internal buffer, but will consume it proportionally to the pipeline's fullness. Any other ideas would just waste UPS and memory.

[GN89]

Idea: Continuous fluid consumption instead of instant draining

The main issue with assembly machines (like EM plants) right now is that they try to drain the entire fluid amount required for a recipe instantly, on the very first tick of the crafting cycle. Because of this, the first machine in the simulation update queue takes everything, and the downstream machines starve.

Perhaps this could be solved without bringing back hidden buffers, by changing how the recipe logic itself works:

1. Solid items are grabbed by the machine as usual — all at once and upfront. After that, the crafting progress bar starts moving.
2. Fluids are NOT taken upfront. Instead, while the crafting is in progress, the machine sips a tiny portion from the pipe every tick, exactly matching what is needed for that specific tick.
3. If there isn't enough fluid in the pipe on any given tick, the crafting progress simply pauses (just like when a machine runs out of electricity), until fluid becomes available again.

It is hard to say how difficult this would be to implement in code or how it would affect UPS, but such logic could eliminate the "selfish draining" of the first machine and distribute the fluid more smoothly along the chain.

[AssaultRaven]

You still have to control the level of fluid in the system, it's just possible now to do so by throttling the chemical plants themselves.

No matter how much I think about this issue, the only easy fix seems to be bringing back the hidden buffer. However, I actually think the current mechanic is quite good. It brings a fresh challenge to logistics. Also, if thrusters use the same mechanic (I haven't updated the game yet), it makes their control way more precise. The engine won't try to suck all the fluid from the system into its internal buffer, but will consume it proportionally to the pipeline's fullness. Any other ideas would just waste UPS and memory.

The thruster situation seems to be working at cross purposes now, because since pipes are effectively the internal level of the thrusters, you can just put a pump on each line to the thrusters, connect them to a downstream pipe segment with a wire, and set them to enable on fluid level in the downstream pipe being lower than a given level, and that will be the percent level of the thrusters.

Preventing you from doing this specifically was the reason why thrusters cannot be connected to wires, so you can't just read their ingredients level, forcing either a pulse-width modulated pump control circuit, or equivalent, or accepting inefficient thrust.

[GN89]

You still have to control the level of fluid in the system, it's just possible now to do so by throttling the chemical plants themselves.

No matter how much I think about this issue, the only easy fix seems to be bringing back the hidden buffer. However, I actually think the current mechanic is quite good. It brings a fresh challenge to logistics. Also, if thrusters use the same mechanic (I haven't updated the game yet), it makes their control way more precise. The engine won't try to suck all the fluid from the system into its internal buffer, but will consume it proportionally to the pipeline's fullness. Any other ideas would just waste UPS and memory.

The thruster situation seems to be working at cross purposes now, because since pipes are effectively the internal level of the thrusters, you can just put a pump on each line to the thrusters, connect them to a downstream pipe segment with a wire, and set them to enable on fluid level in the downstream pipe being lower than a given level, and that will be the percent level of the thrusters.

Preventing you from doing this specifically was the reason why thrusters cannot be connected to wires, so you can't just read their ingredients level, forcing either a pulse-width modulated pump control circuit, or equivalent, or accepting inefficient thrust.

Yeah, I've always considered the inability to read thruster data with wires a downside. I spent half the night on my first PWM version just to get the platform to fly at the speed I needed. The current mechanic gives us a legitimate workaround.