protocol_1903 wrote: Fri Sep 27, 2024 10:42 pm[...]you would need to propogate down the system until it reaches a low point[...]

I'm just not seeing how you could generalize this across networks of arbitrary complexity without pretty much checking every last leg, and that won't look pretty, computationally.

[...]The logic is sound, assuming a wrote it correctly.[...]

Assume a T-shaped pipe with 3 along the top and 2 on the vertical.
According to instructions: [...]Each pipe keeps track of a value representing the distance to the furthest pipe.
3 2 3
- 2
- 3
Add a pipe: Whenever a new pipe is placed ...

[...]yeah? the FFF proposal is a heavily simplified system, of course it'll have lower resource usage.[...]i don't imagine this will actually use that much more seeing as these calculations would need to be done anyways (just done every tick), and variables are never free.
fluid simmulations (even ...

[...]Each pipe keeps track of a value representing the distance to the furthest pipe. Whenever a new pipe is placed, it sets its own value to the lowest value around it + 1. Then each adjacent pipe updates using the same logic if it's distance + 1 is greater than the value , starting with the pipes ...

[...]could go for a node based system where network flows, latency, and storage are precalculated between nodes (building connection points) when you construct the network to avoid constant runtime overhead.

or split pipes into separate networks (condition being where 2 pipe components never touch ...

[...]The arbitrary number of junctions also doesn't mean anything, as the logic doesn't need pathing.

It would need pathing to figure out which branch of the network has the "furthest" fluid box. It's trivial if you have an "L" shaped pipe, but if it's "H" shaped, or more complex, you'd need to ...

CrazyAmphibian wrote: Fri Sep 27, 2024 9:27 pm[...]what if the 1.0 fluid system core was kept, but fluids are given inertia?[...]

The #1 reason the devs are reworking fluids is performance, so any idea that doesn't slash performance costs to a level comparable with what they've got in these FFFs is probably not gonna fly.

[...]What if the pipe limitation was a point-to-point limit instead of a square? Each pipe can only be (for example) 500 fluid boxes away from the furthest pipe before the network becomes invalid.[...]
This would be nice, but in the first fluid FFF, the devs mentioned that one of the motivations ...

I'm trying to understand the new changes. So you are maxed at 6000/s throughput / max 5 pumps?[...]
No. The 6000 hard limit is per flow operation, and flow operations only happen between machines and machines, or between machines and pipe segments. There is no flow within pipe segments, so as ...

Myriapode wrote: Fri Sep 27, 2024 5:30 pmdid i got it

Yes.
(Or, at least, the math is correct. In that specific picture, the pumps would be pointless because just connecting the pipe across them would give more unlimited flow)

[...]Iit's just ridiculous how dense people are around here[...]
The IRONY I CAN'T—
If we really are all that dense around here, o esteemed one, then mayhaps it would serve everyone better if you were to explain, in terms even the densest of us could understand, your reasoning. Surely you're not ...

[...]
97% if that whole system works exactly as you think it does,
why do you even play factorio, if 97% is good enough for you?

Are you seriously trying to tell me that you can't buffer 1 cycle of your reactor if the effective capacity of your tanks drops from 100% to 97%!? You don't have space ...

[...]
#3: to make full use of the storage tanks capacity, and ignore current fill lvl in the pipes and ignore fluid mechanics, you do need to use pumps, actually 2 per storage tank

Well there's your problem. Ignoring fill levels looks like it's entirely unnecessary due to this bit:
[...]there ...

[...]
No you did not, you missed the part where pumps are limited to 1200/s, 1/10th of what it was,
and go on, tell me if I'm wrong on the storage tanks, but you will still need pumps, likely as it is now, 2 pumps per tank to make full use of its capacity because that's just how the fluid ...

[...]
what is, post expansion, the limit of what I can put through pipes without using pumps?

go on, tell me!, if it's less than 2k/s it will break reactor design in an absolutely fundamental way

From this FFF:
[...]there is no limitation on the total flow through a pipeline in a given tick ...

[...]
I mean before I used a design that doesn't pump directly into/from a tank, there was a pipe segment between them. Yea, it limited the output to around 6000 IIRC, but it allowed for a rather compact design with load balancing too. Here's an example.
09-27-2024, 18-51-39.png

Now, I will have ...

The Water to Steam ratio change makes it more possible to supply power or nuclear setups using fluid wagons or even water barrels.
The reason I never even tried this is not throughput limitations; it's because there's no unpowered way to get fluids from barrels or wagons into pipes.
It feels like ...

[...]To me, that artificial 250x250 space limitation sounds, well, artificial and unfun. It may not be constraining, but it sure sounds like it might be annoying when *suddenly* the pipe magically stops working and needs a pump because some weird limit is reached.

I think my biggest issue with it ...

[...]
- heat exchangers still output the same amount of steam, pre and post expansion release
- after expansion, pumps will be transporting 1/10th of the previous throughput
[...]
And you'll need 1/10th the water as compared to before, so 0 change...why do you need so many pumps to move steam ...

[...]
You missed a bit where it states that steam expands now so you use 1 water to make 10 steam. So overall use of water for reactor stays the same.

[...]
So thanks for making me clear this part as well:
- any halfway sophisticated reactor will have the same amount of offshore pumps as ...