max_fluid_flow as a fluidbox prototype

[protocol_1903]

max_fluid_flow should be a fluidbox prototype, not a utility constant. Currently, there is no way to have "high throughput" pipes, the only way to differentiate pipes is to have ones with larger extents. This effectively removes a potential technological improvement where the player starts with low throughput pipes, and eventually gets higher throughput pipes. If there's concerns about mixed flow rate fluidboxes connecting, just average it out over all pipe and pipe-to-ground fluidboxes in a network. That, or use the lowest value of the network.

A bit of reasoning: Playing pY in 1.1 with a 73x science multiplier, I had to make some larger than usual builds for science, even in the very early game. I had something like 4 or 5 water lines running across the base, because I needed so much water to different places. A couple of the builds were so large that I needed some FluidMustFlow ducts to supply the whole thing. It was an interesting mechanic to have to use bigger ducts to bring fluids in bulk, then split off smaller arteries for specific builds. I'd really like to have something like that in 2.0

[MrSmoothieHuman]

+1

[protocol_1903]

Pinging for relevancy

[SwozzleSticks]

+1

[Rseding91]

The fluid system flow logic simply does not work if there are mixed pipe flow speeds in one fluid network. So instead of trying to keep them split, while also making sure every single thing in one network has the same speed - we simply make it one value across the logic.

[protocol_1903]

The fluid system flow logic simply does not work if there are mixed pipe flow speeds in one fluid network. So instead of trying to keep them split, while also making sure every single thing in one network has the same speed - we simply make it one value across the logic.

As mentioned in the original post, could it not be restricted to be the lowest flow_rate of the system? The value would only need to be updated when a fluidbox is added/removed.

[Osmo]

+1, the latest suggestion would basically function like extents do already, and no one seems to have problems with them this part of their impelmentarion

[protocol_1903]

+1, the latest suggestion would basically function like extents do already, and no one seems to have problems with them this part of their impelmentarion

Actually yeah, I hadn't thought about that. Extents function in exactly the same fashion.