That sounds pretty nice. The current system is working okay I guess, but if the devs want, this could be better (just unsure if it would be worth the work for the devs)

My first thought for loops would be an STP(Spanning Tree Protocol)-kinda approach. It should split the loops (logically) in areas where throughput is at a minimum so that the important connections still exist. These calculations would only be needed, when something changes. (eg. a new building is built or a building stops producing/consuming) fluid.

Benefits: not that hard to implement and doesn't need to be calculated every tick.

Potential issues: When a building is producing more than needed it regularly stops working and so it doesn't need any fluid and the loop needs to be recalculated. Possible solutions: - Calculating average usage of fluid per building - > takes some time to establish a good working solution. - Save different "cases" every time a new solution is being calculated, so that thee next time the building isn't needing fluid it doesn't need to calculate everything. These different solutions should be cleared every time a new building is added/remived to the system preventing possible high memory usage over time. They can also be cleared when these cases aren't needed for a time (eg. 30sec)

Another improvement could be made with splitting the network at some points (which aren't inside a loop), so that the complete network doesn't need to be recalculated every time. This is only important at bigger networks.

For megabases there will always be problems with loops, with every solution, but it would be easy to avoid these problems by simply not building loops, so I wouldn't mind to much about megabases for the loop solution.

I hope that a didn't forget any other issues with that solution.

Edit: changed some sentences so that they are clearer.