Factorio Forums

sarge945 wrote: Sat Jul 04, 2026 9:00 am Nope. I use the far more effective strategy of barreling it and then transferring it over using logistics bots.

Or even better, just place your cargo landing pad next to your uranium mine, then you can use rockets to transfer the barreled fluid to your uranium mine via a space platform, saving you the trouble of using bots AND wagons!

Actually seriously though, I wouldn't say fluid wagons are completely 100% useless in all cases. But they are extremely niche, and I can see piping fluids like that being more effective in a significant number of situations rather than using the wagons. They are very disappointing in just how little use they have.

I don't think you could at the same time send barrels to a platform and request them from the same platform at a different place on the same planet, i am missing something here ? you're talking about transfering barrels to another platform so it can drop it ? is this some new 2.1 thing ? x)

To be fair i don't see how using bots and barrels has anything to do with the changes the new fluid system introduce, like the new system helps players predict where fluid will flow when using pipes, but if you were not using pipes already because you used bots and barrels then it's fair to say one can ignore the complaints about long pipes being the one and only dominant strategy, it's clearly not the case, or something doesn't add up here x)

mmmPI wrote: Sat Jul 04, 2026 9:29 am

sarge945 wrote: Sat Jul 04, 2026 9:00 am Nope. I use the far more effective strategy of barreling it and then transferring it over using logistics bots.

Or even better, just place your cargo landing pad next to your uranium mine, then you can use rockets to transfer the barreled fluid to your uranium mine via a space platform, saving you the trouble of using bots AND wagons!

Actually seriously though, I wouldn't say fluid wagons are completely 100% useless in all cases. But they are extremely niche, and I can see piping fluids like that being more effective in a significant number of situations rather than using the wagons. They are very disappointing in just how little use they have.

I don't think you could at the same time send barrels to a platform and request them from the same platform at a different place on the same planet, i am missing something here ? you're talking about transfering barrels to another platform so it can drop it ? is this some new 2.1 thing ? x)

To be fair i don't see how using bots and barrels has anything to do with the changes the new fluid system introduce, like the new system helps players predict where fluid will flow when using pipes, but if you were not using pipes already because you used bots and barrels then it's fair to say one can ignore the complaints about long pipes being the one and only dominant strategy, it's clearly not the case, or something doesn't add up here x)

It was just a joke. But if you want a real answer, you could transfer them by requesting them on the platform and then manually trashing them once they arrive, which would launch them back down to Nauvis.

So not only is it an extremely expensive and inefficient way to transport fluids, it also has the added bonus of being a purely manual process without any automation!

Nobody in their right mind would actually barrel fluids to send them via rockets or bots. Even if I was seriously arguing in favour of doing that, it doesn't invalidate pipes as the dominant strategy because the alternative involves using such a stupid method to transfer fluids that in no way is desirable or even viable as a strategy.

sarge945 wrote: Sat Jul 04, 2026 10:07 am Nobody in their right mind would actually barrel fluids to send them via rockets or bots. Even if I was seriously arguing in favour of doing that, it doesn't invalidate pipes as the dominant strategy because the alternative involves using such a stupid method to transfer fluids that in no way is desirable or even viable as a strategy.

Actually i feel everyone that uses fluoroketone on their platform has to barrel fluid otherwise you can't send it to space, and using bots isn't uncommon for the subsequent step of moving the aforementionned barrel. It didn't sound like a joke to me when you mentionned using bots to move barrels around, it's also what some players use to avoid fluid sushi in their automall, at the cost of some fluid loss when the recipe changes...

On the other hand, the whole diatribe about reviving the fluid wagon because of the long pipes strategy being dominant, i felt was maybe a joke. That's why i asked if you use that strategy for oil and / or sulfuric acid mining currently, because to me , you collect uranium with trains, therefore you already have rails that goes to the outpost, so making a fluid wagon for uranium sound much more desirable than routing a super long acid pipes.

sarge945 wrote: Sat Jul 04, 2026 10:07 am It was just a joke. But if you want a real answer, you could transfer them by requesting them on the platform and then manually trashing them once they arrive, which would launch them back down to Nauvis.

Couldn't the manual part be removed with circuitry. I.e. a circuit on the space platform requests them. Then the request gets turned off and conversly circuitry at the landing pad (far away from the rocket silo) requests those items from the space platform?

meganothing wrote: Sat Jul 04, 2026 1:45 pm Couldn't the manual part be removed with circuitry. I.e. a circuit on the space platform requests them. Then the request gets turned off and conversly circuitry at the landing pad (far away from the rocket silo) requests those items from the space platform?

In 2.0 no as you can't control request with circuits like you suggest. In 2.1 maybe , that's why i was asking You could also have a platform that request barrels from Nauvis, a platform that request barrels from that other platform, and Nauvis requesting the barrels, it wouldn't receive them from the first platform that request them from Nauvis, this is in the game to avoid back-and-forth logistic, but maybe using a third platform you then have a clear resolution for the request that avoid back-and-forth.

mmmPI wrote: Sat Jul 04, 2026 1:53 pm

meganothing wrote: Sat Jul 04, 2026 1:45 pm Couldn't the manual part be removed with circuitry. I.e. a circuit on the space platform requests them. Then the request gets turned off and conversly circuitry at the landing pad (far away from the rocket silo) requests those items from the space platform?

In 2.0 no as you can't control request with circuits like you suggest. In 2.1 maybe , that's why i was asking You could also have a platform that request barrels from Nauvis, a platform that request barrels from that other platform, and Nauvis requesting the barrels, it wouldn't receive them from the first platform that request them from Nauvis, this is in the game to avoid back-and-forth logistic, but maybe using a third platform you then have a clear resolution for the request that avoid back-and-forth.

Before posting my question I started the game and updated to experimental exactly to check if there is a way . Without actually building it I can't be sure, but it did look like being possible theoretically.

meganothing wrote: Sat Jul 04, 2026 2:04 pm Before posting my question I started the game and updated to experimental exactly to check if there is a way . Without actually building it I can't be sure, but it did look like being possible theoretically.

Yeah well last time i played the space casino looked like possible in theory too, but looking at it more closely, i realized nope, the catalyst part was gone too, i only had time to quickly update couple mods and that it's, i may not have the time for a full game before a while, so toying with space platform in editor is more likely in a near future, provided there's some fun possibly over-engineered new stuff to try, and as such interplanetary logistic may be of of them, with the radar addition to carry signals and the new feature on the hub and the platform to platform transfer, that would be like a bingo of new feature for 1 platform... if only it could do quality too

Tertius wrote: Fri Jul 03, 2026 9:39 am - The ability to use molten metal in a production base breaks the boring "main bus" paradigm. Instead of distributing vast belt lanes of plates and plate products, you just distribute molten metal and craft metal products on the spot where they are needed. This opens up variety vastly. Don't underestimate this - this is a completely different paradigm. If you grew up without foundries, it's possible you don't see what possibilities this will open up.

It feels a bit like people read that FFF about the fusion reactor where it was stated that sometimes simplicity is the "absence of good" and then ran with that concept. If anything in Factorio is simple, that means it's bad.

Simple can be good. Mega base scale in Space Age invites a more scalable solution for basic intermediates like iron plate. You could run multiple rail lines with insanely long trains, or 50 to 100 stacked turbo belts, but why is that "good"? Why is that better than just shoving it all through pipes and forging parts on site?

I dunno why it's better. There's plenty of belt logistics you have to tackle at the science production location, much more interesting problems than "run this line for 1000 tiles". I don't feel like there is something missing that this challenge adds.

Simplicity comes at a cost, and that is that overly simplistic gameplay usually ends up being disappointing or unsatisfying.

I guess if we took it to it's logical extreme we could argue that Factorio would be much simpler if we could just launch infinite rockets with no resource costs and no build time, and it would probably also be better for UPS since the game wouldn't need to calculate resource amounts and build times, or simulate the thousands of assemblers that you need in a megabase to make constantly launching rockets viable.

The complexity is there for the sake of gameplay. Things cost resources because the game wouldn't be satisfying if they didn't.

The issue with the new fluid system isn't that it's simple, it's that it's simplicity undermines existing alternatives (in the case of fluid wagons), and generally makes laying pipes uninteresting. Even if it's overall kept more simple than the 1.1 system, as long as there's some interesting mechanics there, then it should be good to engage with.

People don't really play Factorio for simplicity. There's plenty of cinematic AAA "press X to continue to next cutscene" games for that. Factorio's complexity is one of it's biggest features, and the brilliance of it's design is that it creates simple systems that interact in complex ways, so you get a lot of depth without systems being obtuse and ultra performance intensive. The fluid system is just an outlier.

sarge945 wrote: Sun Jul 05, 2026 2:57 am Simplicity comes at a cost, and that is that overly simplistic gameplay usually ends up being disappointing or unsatisfying.

I guess if we took it to it's logical extreme we could argue that Factorio would be much simpler if we could just launch infinite rockets with no resource costs and no build time, and it would probably also be better for UPS since the game wouldn't need to calculate resource amounts and build times, or simulate the thousands of assemblers that you need in a megabase to make constantly launching rockets viable.

The complexity is there for the sake of gameplay. Things cost resources because the game wouldn't be satisfying if they didn't.

The issue with the new fluid system isn't that it's simple, it's that it's simplicity undermines existing alternatives (in the case of fluid wagons), and generally makes laying pipes uninteresting. Even if it's overall kept more simple than the 1.1 system, as long as there's some interesting mechanics there, then it should be good to engage with.

People don't really play Factorio for simplicity. There's plenty of cinematic AAA "press X to continue to next cutscene" games for that. Factorio's complexity is one of it's biggest features, and the brilliance of it's design is that it creates simple systems that interact in complex ways, so you get a lot of depth without systems being obtuse and ultra performance intensive. The fluid system is just an outlier.

I agree 100%. The new fluid system is much easier. Not having to deal with fluid throughput makes dealing with fluids boring, now. Laying pipe is just a simple thing to do now; it's a simple task to do that gets you to get to another interesting problem to solve, instead of the piping being an interesting problem to solve in itself. I'm a little disappointed, to be honest.

1.1 fluids weren't an actual challenge to solve except in the very simplest cases, because they were fundamentally inconsistent and impossible to meaningfully debug. Solving them mostly just meant adding pumps by trial and error until things worked.

Not that it couldn't theoretically be improved, but the 2.0 fluid system is an enormous improvement over 1.1.

Not using fluid wagon is a choice, that's not an incentive from the game, it's like using 4 row of yellow belt, when you could use a blue one. It doesn't mean there's a problem with the yellow or the blue belts.

NineNine wrote: Sun Jul 05, 2026 6:43 am it's a simple task to do that gets you to get to another interesting problem to solve, instead of the piping being an interesting problem to solve in itself.

Maybe this is where we agree to disagree. I think it's fine to be that way. The way it was before wasn't really complex either, at least not in the way you solved it. You still placed a lot of pumps, just in series and not in parallel. /shrug. Not having to use fluid wagons is no great loss either, since it's the same mechanics as for solid item delivery (like ore).

No one complains about bots making it easy to place a blueprint, for example. They are exactly what you just said: A way to make that task simple so you can skip to the interesting part.

I am fine with that.

I think the thread lost its direction. IMHO sarge945 wanted to search for solutions, not argue about current vs. old fluid system.

Except for Panzerknacker it seems we all agree that the 1.1 fluid system had to go and the current system is better. And most of us think it would be even better with some more limits or disadvantages.
I don't think it needs any debate about this point because it is obvious the developers agree as well: They tried to find a better system than 1.1 fluid system again and again. And they added the new system not because it was ideal but it was the only one that solved all problems but one and added no new ones. It was the best compromise they could find.

So in my opinion it is just wasted effort to argue whether a change is needed, we instead need to find a solution that

A) doesn't increase UPS by much (meaning CPU cycles not scaling with individual pipes, but with segments like now)

B) is presumably easy to implement (which rules out any totally new system, it must be a rather simple upgrade to the current system).

C) adds a better disadvantage or limit to the lengths or size a pipe network has. The current system has a limit, but it is arbitrary, gamey and easily circumvented by pumps.

Wube tried and didn't find anything better, and I don't think they'll try again, unless a good solution is presented to them.

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

If you need a refresher, the current system is explained in https://factorio.com/blog/post/fff-416 and https://factorio.com/blog/post/fff-430

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

And here is an idea I have extending on the idea already circulated here to have pumps equivalent to pipes when calculating segments. I don't think this is a good solution as the directionality of the pumps allows setups that act illogical, and it should be still possible to make larger pipe networks through pumps. But lets keep segments exactly as they are and add super segments:

All segments connected by pumps would be viewed as one super-segment and collected in a list together with their size. Then this total size could be used to further decrease the existing flow rate limit by a factor.

Similar to the calculation of the segments the super-segments need to be only updated when building or destroying part of a pipe segment. It solves the problem of pipe networks that get too large because of pipes. Calculating the size of the super segment from the individual size and position of segments is trivial.

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.

If you need some background info: According to FFF 430 there is already a flow rate factor that limits the rate at all sinks and that depends on the fullness of the pipe segment. And if we assume for simplicity that all sinks try to pull nearly the same amount of fluid then the fullness of the pipe segment is **approximately** depending on the number of sources compared to the number of sinks, if I understand the algorithm correctly.

Now if that flow rate limit is decreased by the super-segment factor as well then the fullness of each segment would decrease and consequently the maximum rate at which all sinks can get the fluids in such a super segment.

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.

I think the current discussion is more about whether or not the new system is actually fine or not in it's current implementation, based on less-objective factors of game design (like complexity vs fun vs incentives vs freedom), rather than discussing the mechanics themselves because they have largely already been covered.

I'm personally okay with that, I find it interesting, but unfortunately these sorts of discussions tend to never go anywhere because they are deeply personal in many ways, and people probably see factorio differently - some of us will see it as a complex logistical challenge towards and end goal that should be solved efficiently, in which case all the possibilities need to be equally viable in order to justify using them - while others of us will see it more as a free sandbox, which means that the different possibilities merely existing is enough - you can use fluid wagons if you want, it's purely about personal choice, and it doesn't matter if they are worse than the alternatives.

Personally I sit more in the first camp, but I can see where the people who are more sandbox focused are coming from.

Either way, I feel like several very good solutions have already been presented. So now it's really up to Wube to decide if they want to go with one of the solutions presented - or if they even see the design of the new fluid system as a problem in the first place.

At this point, even if Wube doesn't plan to actually change anything, I really hope they can open up the modding API a bit more to allow more low-level access to the fluid system, even if it means potential mods will absolutely tank UPS, because I feel like if they aren't going to do anything about it, then we should have the freedom to decide if we want a more complex fluid system or not. Wube has done a very good job of opening up various parts of the engine for modders, but the fluid system is still quite locked down, from what I understand.

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.

Except for Panzerknacker it seems we all agree that the 1.1 fluid system had to go and the current system is better. And most of us think it would be even better with some more limits or disadvantages.
I don't think it needs any debate about this point because it is obvious the developers agree as well: They tried to find a better system than 1.1 fluid system again and again. And they added the new system not because it was ideal but it was the only one that solved all problems but one and added no new ones. It was the best compromise they could find.

So in my opinion it is just wasted effort to argue whether a change is needed, we instead need to find a solution that

A) doesn't increase UPS by much (meaning CPU cycles not scaling with individual pipes, but with segments like now)

B) is presumably easy to implement (which rules out any totally new system, it must be a rather simple upgrade to the current system).

C) adds a better disadvantage or limit to the lengths or size a pipe network has. The current system has a limit, but it is arbitrary, gamey and easily circumvented by pumps.

Wube tried and didn't find anything better, and I don't think they'll try again, unless a good solution is presented to them.

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

If you need a refresher, the current system is explained in https://factorio.com/blog/post/fff-416 and https://factorio.com/blog/post/fff-430

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

And here is an idea I have extending on the idea already circulated here to have pumps equivalent to pipes when calculating segments. I don't think this is a good solution as the directionality of the pumps allows setups that act illogical, and it should be still possible to make larger pipe networks through pumps. But lets keep segments exactly as they are and add super segments:

All segments connected by pumps would be viewed as one super-segment and collected in a list together with their size. Then this total size could be used to further decrease the existing flow rate limit by a factor.

Similar to the calculation of the segments the super-segments need to be only updated when building or destroying part of a pipe segment. It solves the problem of pipe networks that get too large because of pipes. Calculating the size of the super segment from the individual size and position of segments is trivial.

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.

If you need some background info: According to FFF 430 there is already a flow rate factor that limits the rate at all sinks and that depends on the fullness of the pipe segment. And if we assume for simplicity that all sinks try to pull nearly the same amount of fluid then the fullness of the pipe segment is **approximately** depending on the number of sources compared to the number of sinks, if I understand the algorithm correctly.

Now if that flow rate limit is decreased by the super-segment factor as well then the fullness of each segment would decrease and consequently the maximum rate at which all sinks can get the fluids in such a super segment.

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.

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.

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.

Therefore the solutions appears more related to tutorials or gameplay help to me. The fluid wagon wasn't always there, it used to be that player were forced to use barrels, because long pipes had throughput dimishing and "realistically simulated", you could overcome it with adding pumps every X pipes to maintain Y throughput, but even then players didn't do that for long distance, they used train + barrels lol.

When fluid wagon were added it was really welcome by most players as a big simplification. It was a solution for long distance fluid transport. It still is. It is simpler than using fluid barrels, but apparently more complex than setting up super long pipes.

Later the fluid system was reworked, with some restriction on pipe distance, making short and intermediate distance easy to connect, but increasingly a chore when the pipe network throughput increases and your stuff comes from 4, 5 - 10 segment away, and you need to add extra pumps to all of them to increase the throughput. Whereas the increase in distance has no real effect on fluid wagons usage, or you can make it so you only need to change 1 place, which is the oil unload area, to increase the train stackers, because you need more train "incoming" at all times if they come from further and you have more of them.

When players have a "small" ( or non-rail world base) i don't mean that as a derogatory terms, then sure pipes are the obvious choice, but as soon as the scale increase, it's not the case anymore, it becomes a choice to stick with pipes despite the existence of fluid wagons, like keeping the early game weapon in the mid game and late game, you can still kill the monsters, but if it appears slow and tedious it's because you are not using the proper weapon x).

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).

I think the reasonning is "backward" not in a derogatory way, in a spacial way, or like causal way, instead of making "pipes" (even more) of a chore to use in long distance, because no-one wants that, or they can use mods to increase the "base difficulty" , rather the solution would revolve around making the fluid wagon easier to use. But it is already "easy" to use, and it got some special attention with the pumps interaction, they can now be stationned on curvy rails ,and share fluid from one another. There were already "boosts" to them, those changes were in the right direction i feel and if it's not enough i'd be curious to have illustration from map view from those players, what their base look like when they are not using fluid wagons, to have an idea of the scale or methods used, because i couldn't really see "large" base like those in multiplayer.

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.

waterBear wrote: Sun Jul 05, 2026 3:41 pm 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.

That's a good point for another discussion i feel, space casino were never "declared fun" or "made to be a thing" , it just became one, when often times developpers or players making suggestion really struggle to create engagment toward a mechanic they introduce, sometimes it's the reverse, it's something no-one actually planned for that gain traction and becomes fun.

mmmPI wrote: Sun Jul 05, 2026 4:30 pm That's a good point for another discussion i feel, space casino were never "declared fun" or "made to be a thing" , it just became one, when often times developpers or players making suggestion really struggle to create engagment toward a mechanic they introduce, sometimes it's the reverse, it's something no-one actually planned for that gain traction and becomes fun.

There are plenty of simple mechanics in Factorio, including the power network (poles and such) and the bot network. You could make those into complicated puzzles. Why though? They affect a lot of other parts of the game. Can you really think of a way to turn them into a puzzle that makes the entire game more fun and doesn't break some other thing?

It's not as easy as it sounds. Whatever power poles bring to the game, it's not a complex puzzle to solve. It's doing something else.

I think it takes a lot of wisdom as a game designer to know which thing to make complicated and which thing is doing something else. I don't think I can do that, personally.