Agreed.ledow wrote: ↑Fri Jun 21, 2024 11:45 am That's the first FFF about the new Factorio that I have just read and thought... hold on... so... you just did that? And this wasn't a build up to a series of trial and errors that eventually came out with something that worked similarly to the old system and was still workable?
It's disappointing to be honest. I can pump oil from 10,000 miles away and it will instantly appear at the other end? It's more a teleporter than a pipe.
I'd far prefer the old system, by a LONG way. The quirks are what makes it, not a watered-down perfect, zero-maintenance solution. It's just ripe for exploits that destroy the immersion in the game.
I realise that it's hard work, but the old system needs to be kept if this is the alternative. It adds nothing and takes away a huge aspect of the game, and makes fluids become "just connect this wire and it all works" which removes huge tracts of the fun. Completely destroys barrelling as well - what's the point when you can instantaneously transport all fluids everywhere? I can even see someone make a single long pipeline to a remote station and "schedule" the pipes with circuits to transfer every fluid product into a storage tank, switching using circuits as to what the current fluid is to pump, and what tank it's put into at the end. One pipe, eliminates the entire fluid, barrelling and train transport of fluids in one hit.
I don't "pipe up" (sorry!) often, but no... let's go back to the old way.
Friday Facts #416 - Fluids 2.0
-
- Smart Inserter
- Posts: 2768
- Joined: Tue Apr 25, 2017 2:01 pm
- Contact:
Re: Friday Facts #416 - Fluids 2.0
Well, this was a really sad FFF....
My Mods: Classic Factorio Basic Oil Processing | Sulfur Production from Oils | Wood to Oil Processing | Infinite Resources - Normal Yield | Tree Saplings (Redux) | Alien Biomes Tweaked | Restrictions on Artificial Tiles | New Gear Girl & HR Graphics
Re: Friday Facts #416 - Fluids 2.0
This sounds good, fluids where a pain the ass.
I am a bit worried about the priorisation of chem plants, As all mashines drag input fluids equally. I imagine the case, where you have a sulfer plant that you want to work full time and then a lot of plastic to consume the remaining petrolium. You notice you are building up petrolium and double plastics. Now as a side effect, you may hurt the sulfur production as you overbuild plastics. This side effect of hurting another production does not seem natural. Preventing this seems hard. addign a pump wont help, as this will drag equally as well. So the only way to prio the sulfur plant now woudl be to add a tank and add a pump to the tank and then connect sulfur to it. This seems painful and unnatural. I wish there was a easy way to prio one chem plant over the others in the network.
I see the following solutions:
- Make pumps always drag with prio (as possibly reduce their size to 1x1)
- Add an asm setting with a fluid drag weight
- Add an asm setting with a "priority" field
I am a bit worried about the priorisation of chem plants, As all mashines drag input fluids equally. I imagine the case, where you have a sulfer plant that you want to work full time and then a lot of plastic to consume the remaining petrolium. You notice you are building up petrolium and double plastics. Now as a side effect, you may hurt the sulfur production as you overbuild plastics. This side effect of hurting another production does not seem natural. Preventing this seems hard. addign a pump wont help, as this will drag equally as well. So the only way to prio the sulfur plant now woudl be to add a tank and add a pump to the tank and then connect sulfur to it. This seems painful and unnatural. I wish there was a easy way to prio one chem plant over the others in the network.
I see the following solutions:
- Make pumps always drag with prio (as possibly reduce their size to 1x1)
- Add an asm setting with a fluid drag weight
- Add an asm setting with a "priority" field
Re: Friday Facts #416 - Fluids 2.0
Excellent news indeed, the fluid system's quirkiness was really detrimental to the gameplay experience once starting to build big. I'm very glad something was finally done, and realism can get lost, if it allows better predictability. Very good job.
[Edit] : Typo
[Edit] : Typo
Koub - Please consider English is not my native language.
Re: Friday Facts #416 - Fluids 2.0
You can also cram unlimited amounts of fluid down a single string of pipes. So while your nuclear power still needs a bunch of off shore pumps it only needs one pipe connecting them to the reactor.morse wrote: ↑Fri Jun 21, 2024 11:27 am The only "realism" trade-off is that you don't need additional pumps for "really long" pipes. Well, "really long" pipe is a cornercase which can be processed separately. For example, you could limit the size of the segment, starting from the nearest source of fluid, and when a pipe becomes "too long" just don't use it anymore, and show a warning, so that a player knew what he has to do in order to fix his setup.
Re: Friday Facts #416 - Fluids 2.0
Barrelling was dead since its introduction, and all the "fun" in long distance pipelines was simply plopping down 2 undergroud pipes and a pump until you reach whatever you need to reach, with horrible bends and wiring.
Nothing changes for the long pipelines, what changes is the strupid junction on small/very small setups.
Equally stupid in the current version is the irreversibility of landfill and waterpumps, making nuclear builds require three blueprints iterations "just because".
Also, a hot take, the blueprint book everyone and their mother uses for mire than 2 belts worth of balancing - that's also unneeded tedium, which should get cut, while the devs are at it. Make multiline splitters a thing
Pony/Furfag avatar? Opinion discarded.
- GregoriusT
- Filter Inserter
- Posts: 339
- Joined: Wed Apr 10, 2019 6:42 pm
- Contact:
Re: Friday Facts #416 - Fluids 2.0
Only the very initial first minute or so of the Fluid Network will seem teleporty (if people even look at that), after that the Pipes are full and you would never notice a difference. Sure there is ways to exploit the System but they are so unintuitive that only people who know the backend in the first place would even try to do it, and even then only for fun.
Even if the Fluid Network was teleporty right now, i would still not use that for long distance Fluid Transport because Biters can target the Pipes.
From a Gameplay standpoint having the Fluids move instantly and without horrendous amounts of Lag is a good option because most people would not even notice how instantaneous it is, and more importantly, the Drums and Tank Wagons are often a more convenient option than long Pipes, so people wont stop using those.
Yes I DO use Barrels for their CONVENIENCE, I am serious. They do have a good use!
^ VERY MUCH THIS ^Excellent nexs indeed, the fluid system's quirkiness was really detrimental to the gameplay experience once starting to build big. I'm very glad something was finally done, and realism can get lost, if it allows better predictability. Very good job.
Don't underestimate Landmines!
Biters bite, Spitters spit, Spawners spawn and Worms... worm? - No, they throw their vomit! They even wind up to directly hurl it at you! friggin Hurlers...
Biters bite, Spitters spit, Spawners spawn and Worms... worm? - No, they throw their vomit! They even wind up to directly hurl it at you! friggin Hurlers...
-
- Fast Inserter
- Posts: 132
- Joined: Mon May 15, 2017 7:49 pm
- Contact:
Re: Friday Facts #416 - Fluids 2.0
Barreling had it's uses in logistics before the introduction of fluid wagons, but since then I agree, it's pretty dead, in vanilla anyway.aka13 wrote: ↑Fri Jun 21, 2024 11:56 amBarrelling was dead since its introduction, and all the "fun" in long distance pipelines was simply plopping down 2 undergroud pipes and a pump until you reach whatever you need to reach, with horrible bends and wiring.
Nothing changes for the long pipelines, what changes is the strupid junction on small/very small setups.
Equally stupid in the current version is the irreversibility of landfill and waterpumps, making nuclear builds require three blueprints iterations "just because".
Also, a hot take, the blueprint book everyone and their mother uses for mire than 2 belts worth of balancing - that's also unneeded tedium, which should get cut, while the devs are at it. Make multiline splitters a thing
Last time I needed it was for Space Exploration, so it could have a revival in Space Age as well. I would prefer if it did not, but it could.
Re: Friday Facts #416 - Fluids 2.0
Barelling is not dead. If you want to have all trains be of one kind you have to barrel. And i like it this wayaka13 wrote: ↑Fri Jun 21, 2024 11:56 amBarrelling was dead since its introduction, and all the "fun" in long distance pipelines was simply plopping down 2 undergroud pipes and a pump until you reach whatever you need to reach, with horrible bends and wiring.
Nothing changes for the long pipelines, what changes is the strupid junction on small/very small setups.
Equally stupid in the current version is the irreversibility of landfill and waterpumps, making nuclear builds require three blueprints iterations "just because".
Also, a hot take, the blueprint book everyone and their mother uses for mire than 2 belts worth of balancing - that's also unneeded tedium, which should get cut, while the devs are at it. Make multiline splitters a thing
About the Change itself: Appreciate it. I like the idea to not have to worry about certain aspects anymore. But it feels a little bit too easy to have fluids instantly appear miles way. What i might like is a reduced version of pump-usage. You have to add a pump every x tiles. This way the througput is limited and in a minor degree the fluids needs some time to come through the pipe (even if it is only a few ticks). Anyway i like this more than the old system, so go for it
- imTheSupremeOne
- Long Handed Inserter
- Posts: 65
- Joined: Wed Aug 30, 2017 4:13 pm
- Contact:
Re: Friday Facts #416 - Fluids 2.0
Pog; though I wished you'd take inspiration from GregTech power system because Thermal Expansion approach completely nullifies caring about throughput in a system as a whole...
-
- Fast Inserter
- Posts: 219
- Joined: Fri Aug 12, 2016 10:22 pm
- Contact:
Re: Friday Facts #416 - Fluids 2.0
I wondered about that too. The FFF didn't talk about limits, but instead about solving the quirky behaviors. Can you get an "Output Full" by trying to shove too much fluid into a pipe?
As for nuclear, 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 seems like you'll need to buffer the water in tanks first, and then have a shorter segment so it can keep up with the machines demands.
Re: Friday Facts #416 - Fluids 2.0
Sure, but you won't be having any meaningful throughput with that. Unless you play something modded, with a very expensive and low-throughput fluidd, of course.FunMaker wrote: ↑Fri Jun 21, 2024 12:08 pmBarelling is not dead. If you want to have all trains be of one kind you have to barrel. And i like it this wayaka13 wrote: ↑Fri Jun 21, 2024 11:56 amBarrelling was dead since its introduction, and all the "fun" in long distance pipelines was simply plopping down 2 undergroud pipes and a pump until you reach whatever you need to reach, with horrible bends and wiring.
Nothing changes for the long pipelines, what changes is the strupid junction on small/very small setups.
Equally stupid in the current version is the irreversibility of landfill and waterpumps, making nuclear builds require three blueprints iterations "just because".
Also, a hot take, the blueprint book everyone and their mother uses for mire than 2 belts worth of balancing - that's also unneeded tedium, which should get cut, while the devs are at it. Make multiline splitters a thing
About the Change itself: Appreciate it. I like the idea to not have to worry about certain aspects anymore. But it feels a little bit too easy to have fluids instantly appear miles way. What i might like is a reduced version of pump-usage. You have to add a pump every x tiles. This way the througput is limited and in a minor degree the fluids needs some time to come through the pipe (even if it is only a few ticks). Anyway i like this more than the old system, so go for it
But in vanilla, at least in my opinion, it is deader than dead.
Pony/Furfag avatar? Opinion discarded.
- GregoriusT
- Filter Inserter
- Posts: 339
- Joined: Wed Apr 10, 2019 6:42 pm
- Contact:
Re: Friday Facts #416 - Fluids 2.0
Completely ignoring the fact i stole the power system from IC2 basically, and then reimplemented it badly. Not a good Idea to run with my System at all whatsoever for a Factory Builder, it's much better suited for a Workshop Builder like in Modded Minecraft.imTheSupremeOne wrote: ↑Fri Jun 21, 2024 12:09 pmPog; though I wished you'd take inspiration from GregTech power system because Thermal Expansion approach completely nullifies caring about throughput in a system as a whole...
Don't underestimate Landmines!
Biters bite, Spitters spit, Spawners spawn and Worms... worm? - No, they throw their vomit! They even wind up to directly hurl it at you! friggin Hurlers...
Biters bite, Spitters spit, Spawners spawn and Worms... worm? - No, they throw their vomit! They even wind up to directly hurl it at you! friggin Hurlers...
Re: Friday Facts #416 - Fluids 2.0
Greg had some great ideas, but having power come in packets, and these packets getting voltage deduced on a by-tile-basis is not intuitive for most people. But I do like the transformers and all related bgameplay, like you can loose efficiency for the sake of easier mass-production.imTheSupremeOne wrote: ↑Fri Jun 21, 2024 12:09 pm Pog; though I wished you'd take inspiration from GregTech power system because Thermal Expansion approach completely nullifies caring about throughput in a system as a whole...
Don't play coy, credit where credit is due. You definitely had the best and most performant take on "as close to dc and ohm law on one wire" idea.GregoriusT wrote: ↑Fri Jun 21, 2024 12:12 pmCompletely ignoring the fact i stole the power system from IC2 basically, and then reimplemented it badly. Not a good Idea to run with my System at all whatsoever for a Factory Builder, it's much better suited for a Workshop Builder like in Modded Minecraft.imTheSupremeOne wrote: ↑Fri Jun 21, 2024 12:09 pmPog; though I wished you'd take inspiration from GregTech power system because Thermal Expansion approach completely nullifies caring about throughput in a system as a whole...
I'd go as far as to say, that your system to this day keeps the best balance between a challenge and tedium. Factorios power leans heavier on the "don't worry too much" side for my taste.
Pony/Furfag avatar? Opinion discarded.
Re: Friday Facts #416 - Fluids 2.0
The idea of simplifying the problem into segments in order to save compute is a great one not only works great on fluids but maybe this can be implemented into the pollution computation, for the odd people making megabases on death world and now with improved bots that can place way more concrete on O(logn).
Im proposing to implement the same thing to improve the compute of pollution spread by implementing a maximum amount of pollution on a chunk once its reached and its neighbors are they are joined together into a big segment, in a large factory with lots of beacons and lots of space Usually all the pollution is at the center takes the most of the computation per tick while not being really useful and the edges of the pollution cloud are the places where calculating the pollution spread of all chunck neightbours shows most realism in the pollution cloud shape, because in the center with large megabases the difference between trees and grass against plain concrete or water wont affect much the resulting pollution cloud shape and with a high enough chuck pollution maximum threshold where this optimization kicks in on megabase stages getting the best of both worlds a realistic pollution cloud on small factories and a compute efficient calculation on large megabases where the loss of realism is minimal.
The policy for adding or segregating chunks from a big segment are the threshold where the chunk goes above and gets added to the neighbor segment or create a new segment if none of the neighbors are. And another threshold where the chuck falls bellow and pulls (splits) the pollution from one neighbor chunk of the segment doing the pollution absorption.
The problem of calculating the pollution spread per chunk per tick in a square is O(N^2) what Im proposing is keeping the same calculations for the perimeter of the large segment are O(N) since the center has all the chunks merged into one or a few groups of constant cost (a single arithmetic operation of the entities that add pollution minus the constant abortion of the terrain with trees added to it) that no longer needs tho compute the spread because its over a high threshold we can reduce the cost from O(N^2) to O(N).
One small problem would be the spread of large bodies of water where given that no pollution is absorbed the segment increases through all the body of water since an assembly machine on the other side of the map will instantly move the pollution to the other side of the segment but this would apply on very late game stages depending on the threshold limit where this starts kicking in.
Im proposing to implement the same thing to improve the compute of pollution spread by implementing a maximum amount of pollution on a chunk once its reached and its neighbors are they are joined together into a big segment, in a large factory with lots of beacons and lots of space Usually all the pollution is at the center takes the most of the computation per tick while not being really useful and the edges of the pollution cloud are the places where calculating the pollution spread of all chunck neightbours shows most realism in the pollution cloud shape, because in the center with large megabases the difference between trees and grass against plain concrete or water wont affect much the resulting pollution cloud shape and with a high enough chuck pollution maximum threshold where this optimization kicks in on megabase stages getting the best of both worlds a realistic pollution cloud on small factories and a compute efficient calculation on large megabases where the loss of realism is minimal.
The policy for adding or segregating chunks from a big segment are the threshold where the chunk goes above and gets added to the neighbor segment or create a new segment if none of the neighbors are. And another threshold where the chuck falls bellow and pulls (splits) the pollution from one neighbor chunk of the segment doing the pollution absorption.
The problem of calculating the pollution spread per chunk per tick in a square is O(N^2) what Im proposing is keeping the same calculations for the perimeter of the large segment are O(N) since the center has all the chunks merged into one or a few groups of constant cost (a single arithmetic operation of the entities that add pollution minus the constant abortion of the terrain with trees added to it) that no longer needs tho compute the spread because its over a high threshold we can reduce the cost from O(N^2) to O(N).
One small problem would be the spread of large bodies of water where given that no pollution is absorbed the segment increases through all the body of water since an assembly machine on the other side of the map will instantly move the pollution to the other side of the segment but this would apply on very late game stages depending on the threshold limit where this starts kicking in.
Re: Friday Facts #416 - Fluids 2.0
I 100% agree. The current "temperature" is completely useless, and nuclear heat exchangers might as well create a different liquid with no difference in gameplay whatsoever. I haven't seen mods do anything interesting with temperature either, and I've played a lot of them.JackTheSpades wrote: ↑Fri Jun 21, 2024 11:27 am Now that fluids are being updated, what about the temperature gimmick?
I call it a gimmick because only steam makes use of it and is being produced and processed by completely different machines. It might as well be a different fluid altogether.
I think it would be interesting if, for example, we had tier 4 assembly machines that required cooling liquid and instead of having one input like normal recipes they have a throughput through (e.g. from left to right) it like steam engines currently do so they can still be chained together.
You pump in 20°C cooling liquid and each machine increases the temperature by 1° per craft, on the other side you pump out the too hot liquid and somehow cool it down again.
The "cooling fluid that increases by 1°C per crafting machine" idea is very cool. Maybe instead of a hard requirement (like temperature must be bellow °C for example), the machine could work faster the lower the temperature is. You could also make it that cooling the liquid further would take increasing amount of energy, so there would be a real tradeof to be considered in how cool you want to make it or how many machines to chain before re-cooling.
That would crate a fun and dynamic mechanic that would be interesting to used, instead of the current "it's basically a different fluid" situation with steam.
Re: Friday Facts #416 - Fluids 2.0
This is a great change. I hate having to put pumps everywhere to transfer any non-trivial amounts of fluids.
The realism "lost" isn't really a lost, since the fluid would get there eventually, so what difference does it make if it will appear there a minute or so earlier when the factory will run on hours on end?
Also, it will improve performance as well, which is a great bonus.
The realism "lost" isn't really a lost, since the fluid would get there eventually, so what difference does it make if it will appear there a minute or so earlier when the factory will run on hours on end?
Also, it will improve performance as well, which is a great bonus.
- imTheSupremeOne
- Long Handed Inserter
- Posts: 65
- Joined: Wed Aug 30, 2017 4:13 pm
- Contact:
Re: Friday Facts #416 - Fluids 2.0
Idk, even in building automated passive factories in Minecraft I still prefer GT-IC2 system more it's not just a single cable that goes over all machines in the entire factory...GregoriusT wrote: ↑Fri Jun 21, 2024 12:12 pmCompletely ignoring the fact i stole the power system from IC2 basically, and then reimplemented it badly. Not a good Idea to run with my System at all whatsoever for a Factory Builder, it's much better suited for a Workshop Builder like in Modded Minecraft.imTheSupremeOne wrote: ↑Fri Jun 21, 2024 12:09 pmPog; though I wished you'd take inspiration from GregTech power system because Thermal Expansion approach completely nullifies caring about throughput in a system as a whole...
Re: Friday Facts #416 - Fluids 2.0
Well not sure I like the old system to finally be gone, but to see some of the very strange ways it worked (or better you need to do to get it working) to go is worth it.
-
- Burner Inserter
- Posts: 7
- Joined: Tue Jun 11, 2024 7:02 pm
- Contact:
Re: Friday Facts #416 - Fluids 2.0
As much as I love granularity, considering the cost to doing fluids more realistically, and the fact the current system is so squirrely and unintuitive, this is definitely for the best.
The only thing I'd consider is the curve for pulling from a segment to also considers the capacity of that segment. I'd have a curve that at lower pipe capacities has the same behavior as detailed in the article, but as the capacity go up and up the efficiency goes downward at an exponential rate, requiring an either enormous amount of input, or simply other transportation solutions e.g. Trains, pump stacks, some modded higher through put pipe.
For me, that would add in just enough fuzziness that I appreciate in Factorio, not sticking to cleanly divisible ratios all the time. Plus, I think having this sort of curve being moddable would also be neat, as it would mean different fluids have different sort of transportation efficiencies, representing viscosity.
I have no idea how realistic this is from a UPS perspective, or if it has some hidden downsides that I'm not seeing that basically looses all the gains from this rewrite, but that's what has been brought to mind by this FFF.
The only thing I'd consider is the curve for pulling from a segment to also considers the capacity of that segment. I'd have a curve that at lower pipe capacities has the same behavior as detailed in the article, but as the capacity go up and up the efficiency goes downward at an exponential rate, requiring an either enormous amount of input, or simply other transportation solutions e.g. Trains, pump stacks, some modded higher through put pipe.
For me, that would add in just enough fuzziness that I appreciate in Factorio, not sticking to cleanly divisible ratios all the time. Plus, I think having this sort of curve being moddable would also be neat, as it would mean different fluids have different sort of transportation efficiencies, representing viscosity.
I have no idea how realistic this is from a UPS perspective, or if it has some hidden downsides that I'm not seeing that basically looses all the gains from this rewrite, but that's what has been brought to mind by this FFF.
-
- Burner Inserter
- Posts: 18
- Joined: Tue Mar 10, 2020 5:57 pm
- Contact:
Re: Friday Facts #416 - Fluids 2.0
I'l probably miss the old realism of the simulation for a couple of weeks and never think about it again. So all in all a very welcomed change.
Any chance while this is being work for being able to blacklist/whitleist fluids from pipes for mods that wan't that kind of features, like liquid only vs gas only pipes, cold fluids vs molten metal.
Any chance while this is being work for being able to blacklist/whitleist fluids from pipes for mods that wan't that kind of features, like liquid only vs gas only pipes, cold fluids vs molten metal.