waterBear wrote: Sun Jul 05, 2026 3:41 pm
There is also a criteria D) which should be: Does it add an interesting challenge to the game?
It is very easy to say "well this mechanic is simple, maybe we could make an interesting puzzle out of it". It is very hard to propose a solution that actually does it.
Yes, D is another criteria by itself. But you could fullfil it as well by (C) limiting the pipe network so some other more puzzle-worthy alternative like a train system is needed for longer distances.
Another criteria I forgot to mention is that whatever is added should be simple to understand and preferably similar to real world physics.
mmmPI wrote: Sun Jul 05, 2026 4:30 pm
meganothing wrote: Sun Jul 05, 2026 2:10 pm
I think the thread lost its direction. IMHO sarge945 wanted to search for solutions, not argue about current vs. old fluid system.
It's difficult to find solutions when no-one agrees on what is the problem. I just joined a few random multiplayer games and more often than not when players are building large base they are using fluid wagons it seemed, and it gets very obvious when you check railwords maps. Therefore it would appears that the problem is more on minority of players that seems to not want to be using it than on the game balance, to me, the game is nice enough to gives different methods, and not force one upon players.
. Using railword maps as part of your statistic is without any value because players playing railwords would be the first players who would ignore any superior system and use trains instead just because. To paraphrase Maslov; "it is tempting, if the only tool you
want to use is a hammer, to treat everything as if it were a nail."
The same choice could be happening in other random multiplayer games you are seeing. The two interesting question are:
Are the players who are not using fluid wagons for long distance fluid transport do that because it is easier even though they think pipes are boring? And if that group is large enough to matter, would some force or suggestive limitation of the pipe system compel them to use something else that would improve their experience with the game?
Are some of the players who use trains use them not because of a meta reason like "I want to play with trains" but because they actually see a good reason not to use large pipe networks, like the need to protect the pipes from wildlife, or because they already have a train network for solids to that area.
If a player decide not to use fluid wagons, and then complain that they don't use fluid wagon, one obvious solution is to start using fluid wagons
Why are they not using fluid wagons already ? It can be deciphered that "pipes are easier to set up and works fine enough so there is no need for the fluid wagon". Which is quite illustrating of a choice similar to using only yellow belts and complaining that red and blue exists. And suggesting to make the yellow belt "worse" isn't going to help. Suggesting to make the pipes more complex to use to me is a non-sense when coming from players who already expressed their desire to not engage with the offered complexity in the game by avoidind the fluid wagons.
Currently using very long pipes isn't a viable strategy for large base imo, because if you want to increase oil throuput in your "main-central nauvis base" by adding an oil outpost and another one and another ect "far away from your base", you will have to add additionnal pumps all along, in every segment, it's tedious, i think that's why most players doing large base actually use trains wagons because not doing so is a chore.
I would disagree to the "tedious" argument. Placing pumps at intervalls would be negligible if it weren't necessary to power them. Powering them at least triples the effort which is still far below the effort of train access. Naturally if someone uses (preexisting) blueprints, effort is not really a criteria anymore.
I think the danger of biters and preexisting train networks are far more compelling reasons to use trains instead.
meganothing wrote: Sun Jul 05, 2026 2:10 pm
It probably isn't advisable to solve increase by using stationary fluid wagons as well by combining those into the super segment as well. Detecting such setups would actually be possible but would have ugly edge cases because of pipe wagons 2 block size and setups with two unconnected segments filling the same wagon at a train station. Detecting such setups, even with two pumps one block apart, is possible, but it could mean that 2 unconnected pipe segments could actually be thrown together into a super segment. So, if someone really wants to use such an obvious exploit to increase pipe throughput, let him.
And then you have a player that makes their "stationnay wagon" move 2 tiles back and forth every so often to throw away your detection logic. Such logic which risk to inadvertedly connect fluid network together when other player are just trying to load a fluid on one side and another on the other side, or anything "legit" which appears to make it look like they are trying to game the arbitrary limit on super-segment x).
The detection logic I was thinking of would have combined any pumps pointing to a rail, not a wagon, as long as at least one pump was directed to and one directed away from that spot (reasoning: wagons would acts like a valve that is closed while the wagon is absent, and a valve would still connect segments to super-segments). Not at all easy to fool AFAIK, but we obviously agree the ugly edge cases make this not a good solution
And lastly , unfortunaly, i'd like to mention that discussion on fluid network are often filled with enthusiast and naive amateur, like me who sometimes have no clue what their technical proposition means, it can appears that a "solution" has no drawbacks from any players after one suggested it, but that it is a mathematical impossibility to achieve and none of the players had a clue. I feel the technical side is often overlooked, the fluid teleporting isn't something the devs were pleased to add, it is a consequence of optimization, of a simpler internal representation of the fluid, to reduce the time spent each frame by the computer to do the simulation. Some proposition seem to be a bit "magical" like it's not possible to have a CPU friendly system like the 2.0 that also has the granularity of the 1.0, that is able to tell the distance between end points and keep track of the topology of the network.
Discussing this in a forum is exactly to give more eyes a chance to find drawbacks that others missed. That ultimately a proposed solution is still not workable after a Wube programmer looks it over is a danger we have to accept. The chance that we arrive at a solution that Wube missed and with a lot more insight into the code ultimately comes to think it would be worth implementing was quite low from the start.
