Friday Facts #416 - Fluids 2.0

[GregoriusT]

This is probably a ridiculous idea but couldn't it be possible to optionally hardware-accelerate fluid calculations by offloading it to the GPU? Like neural network should be able to perform that? Then have all the data ready in memory for when the next game update is gonna be done by the CPU. Like, the CPU calculates the segments where fluid is drawn from a pipe segment into a machine and the GPU handles evening out the segments in the pipe. But yeah, probably complicated like multithreading.

From a hardware standpoint, offloading anything to the GPU is not viable, mainly because every GPU is vastly different and the only thing they have in common are the graphics APIs, which do not really facilitate this type of stuff. Not to mention some mean green GPU manufacturers love locking people out of the computing power of their GPUs for no damn reason. Also latency between CPU and GPU would be a huge issue with keeping the game in lockstep, not to mention dedicated Servers dont really have GPUs all that often.

[Loewchen]

The "arbitrary" numbers would be "how many ticks are needed for the fluid in the video show in the FFF to fully be into the last tank of the snake pipe" vs "in the not snake pipe". It would be more complicated than that of course, but how much more complicated is still not fully understood for me , i suppose that's part of the fun of playing with the new system

It is visible on the last video that the "short straight" pipes and the "long snake" yield different time , so there will be some throughput limits induced by pumps which are entities that "cut" fluid segment into different ones. And the "length" or "volume" of that segment seem to impact the throughput.

I don't think so, I think what we see in that video is way simpler to explain than that.

All that is needed is this:

• Machines can push fluid into a segment at an unlimited rate, and can pull from a segment at a rate proportional to how full the segment is. In other words, if a segment is half full, then the pulling rate is half of the maximum.
• As a special case, pumps can pull at a faster rate if they are connected directly to a storage tank.

So:

• The pumps on the left can pump faster than on the right as they pull from a tank instead of a pipe.
• The output level on the left pumps is only limiting when the whole segment is completely full otherwise pull-from-tank-factor * tank-fluid-level is limiting factor
• The upper pipe segment can hold way less fluid than the lower one
• The upper segment gets completely full almost immediately
• The lower segment gets completely full way later or not at all (not clear from visual)
• Therefore the upper tank will be empty later than the lower one as the pump stalls less if at all
• The average fluid level in the snake is way lower than in the straight
• Therefore the lower pipeline will be empty later than the upper one as the pull-from-pipe-factor * pipe-fluid-level is lower for the lower pipe

Nothing about what I can see needs any more limits than the ones already stated.

[Panzerknacker]

After reading the FFF again and seeing the animation of the space platform section with the 3 chem plants I can understand where the frustration is. In this situation the system is starved for water and the chem plant on the left is gonna fill up the tank first all the way before the other side will also get enough and the engines start working.

I still think this is pretty nornal and obvious to the player though since the plant on the left is sitting closer to the middle plant so the fluid choses mostly the path of least resistance. I think there is a flaw in the design here. Are there too many engines on the platform? Do you really need a tank or are a couple of pipe segments enough of a reservoir? How about letting us limit the storage capacity of tanks like we can with chests? That doesnt seem too unrealistic, just a matter of a valve closing after a certain fluid level is obtained. Maybe the general working of the space platform and it's resource gathering/spending loop is not designed well enough yet within the constraints of the game's existing systems.

[mmmPI]

I don't think so, I think what we see in that video is way simpler to explain than that.

I feel like you have explained more in details what i attempted to sum up under a very generic term and in doing so made it a bit more clear to me what i had not fully understood. What are the "arbitrary numbers" i mentionned that would induce a throughput per segment would then be the quantity of fluid that can fit into a single tank and/or the rate for the special case at which the pump can pull from a tank, for one, and the other being the quantity of fluid that can fit in a single pipe /or the rate when it's not special case, at which pump can pull from a pipe that would be full. ( max pulling rate of pump). ( if those are the only required to explain behavior).

If you do a 1-pipeline-for-all-the-factory none of that matters. Same if you expect pipes to be always 100% full.

Now if one use pumps like a nuclear plant to move fluid in and out segment or buffer and want "predictability", it would be required to know the amount of time for the fluid to travel to the end tank in both cases. (explain behavior with some "arbitrary numbers" told by the game ). Those could then be used to measure the "absolute limit" under which the fluid cannot be expected to have travelled to the end tank. ( maybe i didn't used the word properly or misunderstood your previous post and the whole context, but that's what i meant to say x)).

• Machines can push fluid into a segment at an unlimited rate, and can pull from a segment at a rate proportional to how full the segment is. In other words, if a segment is half full, then the pulling rate is half of the maximum.
• As a special case, pumps can pull at a faster rate if they are connected directly to a storage tank.

• The pumps on the left can pump faster than on the right as they pull from a tank instead of a pipe.
• The output level on the left pumps is only limiting when the whole segment is completely full otherwise pull-from-tank-factor * tank-fluid-level is limiting factor
• The upper pipe segment can hold way less fluid than the lower one
• The upper segment gets completely full almost immediately
• The lower segment gets completely full way later or not at all (not clear from visual)
• Therefore the upper tank will be empty later than the lower one as the pump stalls less if at all
• The average fluid level in the snake is way lower than in the straight
• Therefore the lower pipeline will be empty later than the upper one as the pull-from-pipe-factor * pipe-fluid-level is lower for the lower pipe

Nothing about what I can see needs any more limits than the ones already stated.

I'm not saying it needs more limits than the ones already stated, i'm saying there will be some sorts of throughput limits ( "absolute" ) because of the pumps , but i didn't realize it was possible to explain the "time required for the fluid to reach the end tank" only using the thing you quoted with such an explanation as your list.

It explain to me what will be the "absolute limit" in a way, or how to math it out for predictability; The time for the fluid to reach the end tank depend on the number of pipes, because that's the reason why the two segment can hold different quantity of fluid, throughput as emergent property of volume. Which is not without reminding me of the old system as in the case of a straight line it's the same as distance

In the new system, segments are a single unit, so fluid no longer propagates across a pipeline. Longer pipelines have higher throughput, but take longer to fully empty. The exact throughput numbers are subject to change based on further playtesting.

This is/was the most enigmatic quote from the FFF to me, what are those numbers ???? I think your list offers an explanation on which numbers are to be tweaked to influence throughput and how they would do so. ( mostly the special case of pull rate for pump-attached-to-tank as the "volume" or maybe the volume of each entity, like tank not holding 25K anymore, or pipe not 100 from what i understand and "pull-rate-for-pump-attached-to-pipe".)

I'm not sure that's all there is to the new system and i wouldn't mind reading some more about it though x)

Edit: removed some some words like this

[Sirad]

Hello Alltogether.

Ive Read to all the Posts here, took a load of Time (english is not my native Language)

There are a Lot of Points that advocate Pro and Con to the new Fluid Mechanics.

As for my Point of View, it is not Perfect but a Change into the right Direction. I Understand that some the Players that Optimize their factories to the max and have The Time to Dig up all the Quirks that came with the old system are dissatisfied.

But: Not everyone has the Time to dig up that junctions dont work as the common Logic implies (fluids should evenly distribute to both sides. why does Building order affects this ?)


I often stood besides the Problem why a Robot-Built Blueprint worked sometimes and the other times not. This is a behaviour that kills game fun because it SHOULD work in any cases and the need to rebuild Pipes, because Robots didnt used the proper Build order is just blatant nonsense and inconsistent.
I could have accepted the old system if there was a fix that deleted that issue but there wasnt one so throw it in the Bin was the right to do.

As for my Point, i have 971 Hours gametime Logged, but i still consider myself as the typical casual gamer. If i have Time i run the game Try some new designs and whatever. I dont have the Time to look around and try to make some extra effort to get something working that should work intuitively regardless if you place pipe 'a' first or last.

Dont forget, there are People out there that just want to play and from time to time, challenge their ability to optimize their factory. And those (like me, the casual player) have a Life that restricts them to also dedicate all their sparce free time to dig up in what order a pipe have to be placed to work properly.

We just want to play this Game.

[wild_dog]

I have... mixed feelings on this one.

On the one hand, the pipe unpridictability could indeed be quite frustrating.

On the other hand: having to think about pump/tank placements for optimal throughput, having to run multipel parralell lines to increase througput, and having to add 'represurization' pumps partway through in stead of just having it all flow through 1 pipe at max throughput made the fluid handling a bit more complex in a fun way.

"Longer lines have higher throughput" sounds like the OPPOSITE of what should happen.

Maybe introduce an aditional, static penalty factor of the max throughput based formulaically on the amount of pipe blocks in the segment? Or mayme on the total distance between 2 points in 1 segment farthest from eachother.

That would still maintain 100% predictability while injecting a little more complexity in the system for verry complex/large/long pipe installations.

The current system, i could see just running a single underground pipe max distance in stead of making fluid train stations to be a VERRY viable, if not outright more desirable, alternative. Their main appeal is routing simplification and having a decent/good throughput over verry long distances with little to no added complexity. But if all pipes are on the same segment, and longer pipes have BETTER througput with no penalty, I predict that in stead of pre-wiring cirquits to powerpoles in rail blueprints, it will also add a few pipes to have a max throughput pipe bus running alongside your tracks, and i don't think that was the intended result.

[Mooninaut]

I have... mixed feelings on this one.

On the one hand, the pipe unpridictability could indeed be quite frustrating.

On the other hand: having to think about pump/tank placements for optimal throughput, having to run multipel parralell lines to increase througput, and having to add 'represurization' pumps partway through in stead of just having it all flow through 1 pipe at max throughput made the fluid handling a bit more complex in a fun way.

"Longer lines have higher throughput" sounds like the OPPOSITE of what should happen.

Maybe introduce an aditional, static penalty factor of the max throughput based formulaically on the amount of pipe blocks in the segment? Or mayme on the total distance between 2 points in 1 segment farthest from eachother.

That would still maintain 100% predictability while injecting a little more complexity in the system for verry complex/large/long pipe installations.

The current system, i could see just running a single underground pipe max distance in stead of making fluid train stations to be a VERRY viable, if not outright more desirable, alternative. Their main appeal is routing simplification and having a decent/good throughput over verry long distances with little to no added complexity. But if all pipes are on the same segment, and longer pipes have BETTER througput with no penalty, I predict that in stead of pre-wiring cirquits to powerpoles in rail blueprints, it will also add a few pipes to have a max throughput pipe bus running alongside your tracks, and i don't think that was the intended result.

Full long lines will have higher throughput in 2.0 than they did in 1.0. Partly full long lines will still have low throughput, because the speed with which you can remove fluid from the pipe is based on how full the whole segment is, and very long segments will take a long time and a lot of fluid to fill.

I don't see fluid trains becoming obsolete for long haul transport, because a very long pipeline will likely transport fluid at a snail's pace, unless you have an incredibly high production rate that can fill the whole pipeline in a reasonable amount of time.

Note that even if you fill that very long pipeline, you're using a huge volume of (presumably) useful fluid just to keep the pipeline full enough to maintain flow. You're buffering all of that fluid instead of using it, and that's quite inefficient.

[FuryoftheStars]

I have... mixed feelings on this one.

On the one hand, the pipe unpridictability could indeed be quite frustrating.

On the other hand: having to think about pump/tank placements for optimal throughput, having to run multipel parralell lines to increase througput, and having to add 'represurization' pumps partway through in stead of just having it all flow through 1 pipe at max throughput made the fluid handling a bit more complex in a fun way.

"Longer lines have higher throughput" sounds like the OPPOSITE of what should happen.

Maybe introduce an aditional, static penalty factor of the max throughput based formulaically on the amount of pipe blocks in the segment? Or mayme on the total distance between 2 points in 1 segment farthest from eachother.

That would still maintain 100% predictability while injecting a little more complexity in the system for verry complex/large/long pipe installations.

The current system, i could see just running a single underground pipe max distance in stead of making fluid train stations to be a VERRY viable, if not outright more desirable, alternative. Their main appeal is routing simplification and having a decent/good throughput over verry long distances with little to no added complexity. But if all pipes are on the same segment, and longer pipes have BETTER througput with no penalty, I predict that in stead of pre-wiring cirquits to powerpoles in rail blueprints, it will also add a few pipes to have a max throughput pipe bus running alongside your tracks, and i don't think that was the intended result.

Full long lines will have higher throughput in 2.0 than they did in 1.0. Partly full long lines will still have low throughput, because the speed with which you can remove fluid from the pipe is based on how full the whole segment is, and very long segments will take a long time and a lot of fluid to fill.

I don't see fluid trains becoming obsolete for long haul transport, because a very long pipeline will likely transport fluid at a snail's pace, unless you have an incredibly high production rate that can fill the whole pipeline in a reasonable amount of time.

Note that even if you fill that very long pipeline, you're using a huge volume of (presumably) useful fluid just to keep the pipeline full enough to maintain flow. You're buffering all of that fluid instead of using it, and that's quite inefficient.

I'd argue it's not that inefficient... fluids are infinite, after all.

You could also potentially segment the pipe segments some with a tank & pump.

[Loewchen]

You could also potentially segment the pipe segments some with a tank & pump.

Even that I don't think is necessary, unless you consume more of a fluid than you produce, the segment will fill up completely anyway. And if you don't produce enough, using pumps will only allow you to produce in a burst. The only use for this I could see is if you cannot produce some fluid anymore and want to use what little is in the segment as fast as possible.

Fluid trains will not go away for the simple reason that they are way easier (and more fun) to setup than long pipelines and you will have the train network for the ores anyway.

[GTexperience]

A propose a different solution. Have u considered using linear gradients? U can use the slope as well as height to control how fluids would behave in the pipe. The height would be proportional to the liquid contents inside of the segment. The slope would be determined by the pumps pulling or pushing liquid about the system.

This would effectively keep the "one segment" concept while also fixing the instant fluid transfer independent of pipe length.

[coppercoil]

I can't stop thinking about the fluids. Here's my latest conclusion: we must reject all the principles inherited from the old fluids that are based on open channel flow, which cannot be fixed by design, because we want closed channel flow. This involves different physics.

The closed channel flow does not have a fill level concept, it has a pressure (some of my explanations may be simplified, incomplete, or slightly incorrect, which is acceptable for the Factorio universe) that spreads at the speed of sound. If we have no sound speed limit, pressure changes reach all points in a pipeline at the same tick, so there are no transient processes, which is essential for 2.0.

Higher pressure (formerly fill level) makes pumps work slower and provides stronger flow for consumers, which sounds logical even in our universe. We need to choose some logarithmic functions for pump transfer, producer transfer (including tanks that have a volume), and consumer transfer; they all take one argument: pressure. Then, recalculate the new pressure considering the calculated values for the next iteration.

Note, the pipeline has zero volume, and the pipe has a near-zero diameter, but this is not important because we also have near-zero viscosity and near-zero friction, and no relativistic effects near the speed of light limit.

[DrentalBot]

after thinking about it more and reading through many of the suggestions in this channel, I'm mostly convinced that the handling shown in the FFF is the right call.

Pipes have the challenge of somehow getting all the inputs and outputs connected (and fitting inserters), fixing the cracking ratios, and in theory dealing with backed up fluids. I assume that Space Age will also have some more fluid recipes that can cause backups later in the tech tree, or that the constant demand for Rocket fuel might make Petroleum the bottleneck at some point where light oil is empty (I don't think this is likely, and there are ways to fix it too. Just a possibility)

All this is already enough to act as a somewhat strong filter for new people, as I'm sure many here are aware. There are challenges, and there are known solutions to them.

now to my second point: Transparency.

I can look at a belt, and I know how fast that belt is, I can see if it's a compressed belt or if it's loose, and all that. It's information that I have at a glance. Whenever pipes get involved I have only the barest hint of it flowing in one direction or not, and most of the time I wouldn't notice how full it is. I always need to inspect my pipes closer and on multiple points of my factory to see if the fluids get where I need them to go or if they are starved somewhere. Belts give this information immediately.

The FFF solution makes sure that all parts of my factory that use the same fluid "pool" can give me information about the fluid loads when I inspect them. I still have to look closer than for belted items, but I can see the fluid situation for a whole section by hovering over every pipe that is connected to one entity in a whole row (or just open the entity to see the counts in the input/output). Any solution that involves re-segmenting the pipes into more things I need to check takes away from that transparency. Any solution that changes the throughput of the whole pipe when I add a few additional pieces of pipe to the far end is adding more points of not immediately obvious failure to tweaking my builds.

I think with all this we can agree that there are advantages to the new system. Clear and obvious ones.

That said, I think that thinking about pipes and how to design interesting challenges around them is great. My only requirement for these ideas is, that they are either optional (modded pipes, like the Idea I saw someone suggest here early about a mod that "just disconnects" the pipes from each other), or that the change actually has enough interesting payoff that it is worth adding.

Most of the ideas are about finding ways to make long pipes hurt, and that's fine. But if it doesn't also add ideas how to make these restrictions interact with the rest of the game, I don't see why any of these should be added to the core game. Like the inventory limit - we all agree that the inventory is highly unrealistic and with weight being added to the game in Space Age I wonder about the total weight that one engineer can comfortably lift and move around. it must be a ridiculously high number. But the inventory size interacts with the game. It makes storage a more important concern, it interacts with the personal roboport and logistics network, and it gets increased as the game goes on and you have more items that you want to carry around. The inventory limit achives a purpose and validates trains beyond just being the automation of running between the mine and your factory every half hour. And if fluids are to be more complex than the suggestion - then this added complexity needs to have a justification in the gameplay. I want to read more suggestions that have the added value of a change first, and then a design that adds this value. And I don't think realism is enough of a justification to make the game less transparent and harder to math out in your head when I can craft nuclear fuel in my pocket and carry a mid sized industry complex around in my combat suit.

sorry for the rant.

[XT-248]

I have read every single reply on this topic, and I am taking your feedback seriously. However, any solution that involves fluid physics and/or splitting segments at junctions is not going to happen. There are too many architectural changes that I would have to undo to reintroduce physics.

The problem with the old system wasn't that it had limits, but that the limits were completely nonsensical and not communicable to the user. The new system can be adapted to have some limits as long as they are clearly communicated and consistent. I am working on some ideas for how to do this.

Please help me understand something.

The old system had well-documented limits that may not have been communicated in-game but were documented by people on Wiki and elsewhere. IE: The order of pipe placement influences junction fluid flows, and the number of fluid entities between source and destination lowers the effective amount of potential fluid flows.

The order of pipe placement and the 'non-sequitur flow' at junctions can currently be overcome through the use of pumps. So why not lean on this a bit more? Multiple mods went with this approach with configurable pumps/valves having extra features built-in (flow only over 80% on outlet side or under 20% on outlet side, etc.).

The lower flow fluid rate over distance can be taught through a tutorial on fluid mechanics or documented in-game.



By resorting to the completeness removal of the fluid simulation approach, there is no longer a fluid logistic problem to solve when a single long pipe through the entire megabase solves everything. The only time logistics (barrelled fluid) become a part of the fluid experience is when one wants to ship fluid between worlds (source world -> rocket silo -> space platforms -> destination world).

The consequence is that people will likely devalue anything that is not a pipe when it comes to fluid movement. This includes train fluid wagons.

[mmmPI]

Please help me understand something.

The old system had well-documented limits that may not have been communicated in-game but were documented by people on Wiki and elsewhere. IE: The order of pipe placement influences junction fluid flows, and the number of fluid entities between source and destination lowers the effective amount of potential fluid flows.

The order of pipe placement and the 'non-sequitur flow' at junctions can currently be overcome through the use of pumps. So why not lean on this a bit more? Multiple mods went with this approach with configurable pumps/valves having extra features built-in (flow only over 80% on outlet side or under 20% on outlet side, etc.).

The lower flow fluid rate over distance can be taught through a tutorial on fluid mechanics or documented in-game.

I think you underestimating the difficulty some players had when attempting to use the old system, here is an example :

viewtopic.php?p=609354#p609354

Take your 17 literal pipe-long examples from earlier when I meant figurative, which refers to any entities that move fluids. The logic is so flawed that they show a complete disconnection from how I design a megabase.

There are many other numbers of entities that can move fluids (fluid wagons, barrels, underground pipes, fluid storage tanks, etc.). Do you expect me to honestly believe that I would be willing to accept inefficiencies by using nothing but pipes in my logistics network for a 5k SPM megabase?

The actual length of a pump-to-pump using 17 entities to move fluid (primarily underground pipe sections) would have been 176 tiles. If I add wagons to the mix, it will be even longer.

Your counter-point about my example is invalid because I have already explained it several times. I want to prioritize the first row, and I built three rows to demonstrate that the vertical left side gets prioritized, which is not what I expected or wanted. The disparity between water input and water demand doesn't matter here. Since the point is to demonstrate that pipe junctions are black boxes that the players have no discrete control over beyond picking up and placing pipes without knowing what they would do afterward.

Even increasing the number of pumps and fluid throughput continues to demonstrate that I cannot control where the fluid goes in the same way a splitter can control where items go with priorities and filters.

It seem some players were literally incapable of using pumps to overcome the inpredictability of fluid. Even if it was indeed possible to learn about the distances from the wiki, the logic was "so flawed" according to them that it needed to be changed. I can only imagine how the new system is much better for them now.

I understand you wished the change was just adding valves but to me that would not have made sense, since it was already possible to use pumps and circuits to replicate their behavior.

I hope it gives better understanding, i may be wrong though, your point about train is not clear for me now, and was not clear earlier either so i may be missing part of the point you are trying to make here.

[XT-248]

I think you underestimating the difficulty some players had when attempting to use the old system, here is an example :

*snipped*

It seem some players were literally incapable of using pumps to overcome the inpredictability of fluid. Even if it was indeed possible to learn about the distances from the wiki, the logic was "so flawed" according to them that it needed to be changed. I can only imagine how the new system is much better for them now.

Showing how the fluid moves through the pipes in the tooltip, an in-game Wikipedia (aka Factoriopedia), or even a whole tutorial chapter dedicated to learning about fluid simulation to help newcomers. Veterans don't need as much 'hand-holding.'

Factoriopedia Blog: https://www.factorio.com/blog/post/fff-397

I understand you wished the change was just adding valves but to me that would not have made sense, since it was already possible to use pumps and circuits to replicate their behavior.

Please don't quote month-old posts; then take them out of context compared to what I just posted a few hours ago.


In my recent post, I specifically mentioned pump entities' new functionality and moving in that direction as an alternative solution overall.

The modified valve from various mods is an example of an alternative solution with a reduced capacity (only can handle three modes instead of infinite different conditions with circuits) and a positive trade-off (no-power required to run).

I hope it gives better understanding, i may be wrong though, your point about train is not clear for me now, and was not clear earlier either so i may be missing part of the point you are trying to make here.

Seriously? It is not a difficult concept to understand.


If I have an oil outpost 30 chunks away from my main base and I have a pipe network running all the way out there. The oil is immediately available at my oil refineries without any time delay.

I have no need for train wagons as I am no longer throughput-limited by loading/unloading fluid wagons and train travel time.

What is the point of using train wagons when I can place a long-distance pipe network that immediately teleports the fluid to where I need it?


Therefore there HAS to be a drawback, to encouraging either wagon or barrelling as an alternative, to use a pipe-only network, and I can't think of one at the moment.

[mmmPI]

*snipped*

Sorry didn't read, i was just trying to answer your previous question, not willing to enter a discussion about that with you

[robot256]

I for one am not concerned that the new pipes might change the meta for perfectly optimized bases. Long distance pipelines are used in reality precisely because they are higher capacity and cheaper than tank trains. Fluid wagons will be plenty useful for places where pipes are too annoying to lay, going over bridges, and in mods with too many fluids to easily bus them all. Barrels are already accused by some of being useless, but they have plenty of niches. One of the charms of Factorio is how it lets you do things creatively.

Having 20 offshore pumps feed a single pipe for your entire base is no more silly than blueprinting landfill in a lake because your nuclear reactor is impossible to feed otherwise. And the former gives far more opportunities for creativity in my opinion.

[XT-248]

Sorry didn't read, i was just trying to answer your previous question, not willing to enter a discussion about that with you

That is a weird way to answer my questions by starting with an old quotation by me. The info posted by Raiguard 5 days ago is new to me, and I am moving the conversation in a new direction based on that new info.


I am OK with dialogue with others when everyone is willing to participate.

I think your earlier post invited a response, or was I mistaken? I am just trying to understand why someone would post something with an open question that invites a response. Then, end up not wanting to continue with the dialogue while others have covered some of the same ground.

I for one am not concerned that the new pipes might change the meta for perfectly optimized bases. Long distance pipelines are used in reality precisely because they are higher capacity and cheaper than tank trains. Fluid wagons will be plenty useful for places where pipes are too annoying to lay, going over bridges, and in mods with too many fluids to easily bus them all. Barrels are already accused by some of being useless, but they have plenty of niches. One of the charms of Factorio is how it lets you do things creatively.

Having 20 offshore pumps feed a single pipe for your entire base is no more silly than blueprinting landfill in a lake because your nuclear reactor is impossible to feed otherwise. And the former gives far more opportunities for creativity in my opinion.

I am not worried about the meta changing from what we have now.

I am worried that we will end up with a new meta where pipe-everywhere is the only possible answer or some variant on the same theme.


Take your nuclear power example. Why not create a ditch-digging machine that digs a small channel of water to solve the water/pipe/distance dilemma, creating a glutton of stone that players have to deal with as a trade-off?

Example: https://mods.factorio.com/mod/canal-excavator

Combined with a long-distance mechanic for fluid simulation-less 2.0, people have different choices on how to deal with nuclear energy's colossal water demand (dig-canal vs. pipe-everywhere-unlimitless-flow-rate).

[mmmPI]

I think your earlier post invited a response, or was I mistaken? I am just trying to understand why someone would post something with an open question that invites a response. Then, end up not wanting to continue with the dialogue while others have covered some of the same ground.

You were mistaken. I stated your point about train didn't seem clear the first time i read it, it doesn't mean i am willing to enter a discussion about it.
It was just a feedback after attempting to answer the thing you said you needed help to understand to explain why i couldn't adress all the points.

Other player may also point at the difficulty using the previous system they encountered, similar to the post i quoted, which would adress your previous point that you stated you wanted help understanding.

Or be interested to have a dialogue with you about trains, since you are "covering again the same ground", i feel this is not new to me.

[Sirad]

Fun thing, that happens in most likely all Games...

The minority of Players that is here (i think its somewhat 0.01% of all sales) is split about removing a Broken Gamemechanic inside this wonderful game.
Dont forget, the majority of players (99.99%) will never bother to study some obscure freemason-like broken gamemechanic or read forum and beg for infos here.

[sarcasm] The feel of superiority while telling a newb how this illogigal mess works will be gone. whan a letdown

I most likely prefer Companies creating their game for the remaining 99.99% of Players, because they would get bankrupt trying to please the 0.01% here.