Suggestion for parametrization of 2.0 fluid system.

[Sopel]

This will be a mix of high-level and implementation detail, as I want to make it clear that it is implementable with almost zero-overhead. This is a suggestion for yet unavailable content, so if my assumptions are incorrect please let me know.

The fluid system as described in https://factorio.com/blog/post/fff-416 is very simplistic. Fluid system segments have unified storage, transfer throughput is proportional to source fullness, maximum throughput between system segments is a constant (potentially unbounded). I believe it could be parameterized to enable tiering and increased modding opportunities without complicating the implementation.

The gist of the idea is to have all fluid boxes have 2 additional parameters:

- `maximum_flow` - modelling how fast fluid can pass via this fluid box
- `flow_impedance` - modelling how scale reduces maximum flow

I'd expect these values to be fixed-point, to facillitate incremental computation without precision loss, and portability.

With the simplistic model these parameters would impact the system in a simple way too, to allow for efficient implementation and easy reasoning by the player.

-----------------------------------------------------

`maximum_flow` would specify the absolute maximum output (disregarding input, to reduce implementation complexity and update order dependence) flow for a system segment. Since a system segment consists of multiple fluid boxes, which may have a different `maximum_flow` value, this value could be either a minimum, or an average (or think about something else), over all fluid boxes in the system. Using the average would have a nice property that the difference after adding or removing a fluid box could be computed in O(1) time. O(1) update per output could be maintained by first computing the desired transfer for each output and then normalizing it to fit the maximum.

Advantages:
- Allows multiple tiers of piping
- Allows mods to explore edge cases to produce unique behaviour
- Superset of null-behaviour, i.e. can be left unused in vanilla if that's desired
- Still easy to reason about by the player
- The player can't mindlessly create an infinitely large fluid segment to accommodate the needs as more complicated systems will result in reduced output flow

Disadvantages:
- May push players to split some fluid systems into multiple independent ones to improve throughput (since the maximum is combined for all outputs) in unnatural cases. For example 2 straight parallel 1-input 1-output pipelines connected in the middle.
- Requires further balancing

-----------------------------------------------------

`flow_impedance` would specify how much inclusion of this fluid box impacts the overall maximum throughput of the system. The `flow_impedance` of the whole system would be calculated as `1-prod(1-flow_impedance for every fluid box)`. For example, assuming a pipe having impedance of 0.1% a system with 1000 pipes would reduce the maximum flow (as calculated from the first parameter) to 36.7%, while a better pipe with 0.05% impedance would result in 60% maximum throughput. O(1) implementation for adding/removing fluid boxes is a bit more problematic due repeated multiplication/division in finite precision but tractable. I would suggest a precomputed lookup table (with higher accuracy fixed point numbers) for powers of 2 up to the limit 2^N for every unique impedance value. The actual value for any system size could then be computed by multiplying at most log2(N) values from this lookup table, with some additional multiplications if multiple different fluid box impedances are used within the same system (as for each such value its own count will have to be used with its own lookup table). Assuming the number of different fluid box impedance values is low this would result in effectively constant complexity of addition/removal of a fluid box.

Advantages:
- Allows multiple tiers of piping
- Allows mods to explore edge cases to produce unique behaviour
- Superset of null-behaviour, i.e. can be left unused in vanilla if that's desired
- Still easy to reason about by the player
- The player can't mindlessly create an infinitely large fluid segment to accommodate the needs as larger systems would diminish in maximum achievable throughput.

Disadvantages:
- Requires further balancing.

-----------------------------------------------------

As one additional consideration, a `viscosity` parameter could be added for fluids. It would further affect the maximum flow of the fluid within the system. For example a fluid with `viscosity = 2.0` would half the maximum flow.

-----------------------------------------------------


Please let me know what you think about this. My main motivation is modding support, even if this is not utilized in vanilla. In my view it would really be a shame if the simplistic system that's to be done in 2.0 was not configurable in any way.

[Panzerknacker]

Gotta say this is imo the best proposal so far. Also because those values will all be computed only once while the fluid system is being built so have no performance implication.

When you're gonna have different tiers of pipes you can also add stuff like pipes that are resistant to high temperature fluids like molten metal.

Only problem I can think of, it does not matter where in the pipeline you connect a plant, it will still be bottlenecked by the length of the entire pipeline, even tho it might be sitting very close to the source. So maybe then fluid segments must be split up differently, by having every consumer it a separate segment? Or maybe I am not fully understanding your explanation.

[Sopel]

Only problem I can think of, it does not matter where in the pipeline you connect a plant, it will still be bottlenecked by the length of the entire pipeline, even tho it might be sitting very close to the source.

Yes, you understand correctly, it's the only realistic disadvantage I can think of. The systems can be split by the player using a pump. I don't have a good resolution, I'm hoping this would not be an issue in practice, or at least that the player would easily realize what's up due to the mechanics being simple.

[mmmPI]

This will be a mix of high-level and implementation detail, as I want to make it clear that it is implementable with almost zero-overhead. This is a suggestion for yet unavailable content, so if my assumptions are incorrect please let me know.

I couldn't tell for all the assumptions, but there is this link that was dropped by Loewchen in the FFF thread with the enigmatic caption The old new system which you may be interested in, for a more detailed implementation proposal and how it would compare to the old system.

I will make sure to revisit such topics once the expansion is released !

[Panzerknacker]

I can't get that link to load.

[mmmPI]

That's the first hurdle on the way of fluid mechanic ! It may have to do with your browser ? because i can load the link when clicking on it i can confirm no typo

[Sopel]

This will be a mix of high-level and implementation detail, as I want to make it clear that it is implementable with almost zero-overhead. This is a suggestion for yet unavailable content, so if my assumptions are incorrect please let me know.

I couldn't tell for all the assumptions, but there is this link that was dropped by Loewchen in the FFF thread with the enigmatic caption The old new system which you may be interested in, for a more detailed implementation proposal and how it would compare to the old system.

I will make sure to revisit such topics once the expansion is released !

I'm confused, what's that implementation in the link? If that's some other kind of a proposal then it's offtopic here.

[mmmPI]

I'm confused, what's that implementation in the link? If that's some other kind of a proposal then it's offtopic here.

It seem to me the current fluid mechanic, in a form that i thought could be used to demonstrate your ideas, since you seem to have already thought of implementation.