Factorio Forums

darkfrei wrote: Sat Dec 22, 2018 3:35 pm

Sander_Bouwhuis wrote: Sat Dec 22, 2018 3:12 pm I presume this has been asked many times, but why do pipes auto-connect to each other? It's the nr 1 reason for me to hate Hate HATE pipes.

Why can't I just put 2 pipes next to each other? To connect them we could either have a popup menu to set it, or simply have T-junction pipes and cross-junction pipes (not sure about the correct names/terms for those forms/types).

But you have mod for it https://mods.factorio.com/mod/PickerPipeTools

What if you place empty pipes, must they connect together or not?

There is also Flow Control. Something like this should really make it into 0.17 as it is really useful. Arguably we can all load the mods for 0.17 (if updated), but it would be nice to have it in vanilla.

It would also be nice to have assemblers where we can set the location of the input pipe for each type of liquid. That way we can say set 3 pipes to one side, add a different liquid to each pipe and then the assembler will unlock the recipes use any of the 3 types of liquids and figure out which pipe to input from based on the selected recipe. It will make it nice if you want to be able to quickly change what is produced and would really help if you control production with Crafting Combinators.

Nightinggale wrote: Sat Dec 22, 2018 8:12 pm

darkfrei wrote: Sat Dec 22, 2018 3:35 pm

Sander_Bouwhuis wrote: Sat Dec 22, 2018 3:12 pm I presume this has been asked many times, but why do pipes auto-connect to each other? It's the nr 1 reason for me to hate Hate HATE pipes.

Why can't I just put 2 pipes next to each other? To connect them we could either have a popup menu to set it, or simply have T-junction pipes and cross-junction pipes (not sure about the correct names/terms for those forms/types).

But you have mod for it https://mods.factorio.com/mod/PickerPipeTools

What if you place empty pipes, must they connect together or not?

There is also Flow Control. Something like this should really make it into 0.17 as it is really useful. Arguably we can all load the mods for 0.17 (if updated), but it would be nice to have it in vanilla.

It would also be nice to have assemblers where we can set the location of the input pipe for each type of liquid. That way we can say set 3 pipes to one side, add a different liquid to each pipe and then the assembler will unlock the recipes use any of the 3 types of liquids and figure out which pipe to input from based on the selected recipe. It will make it nice if you want to be able to quickly change what is produced and would really help if you control production with Crafting Combinators.

Ooooooooooooh! Picker pipe clamp (https://mods.factorio.com/mod/PickerPipeTools) is EXACTLY what should be in vanilla Factorio!
Devs, please, please, pretty please with sugar on top: consider this in vanilla Factorio. It makes 100x more sense!

F wrote:What intrigued me was the large variety of backgrounds they came from - differents kinds of engineers (mechanical, CS, electrical, ...), mathematicians, physicists, and even people with real pipes hands on experience.

I'm not surprised, but this quote made me start to wonder how the background affects the factories. Will a mechanical engineer make a different base than a physicists? What about mathematicians?

Personally I have a background in electrical engineering and it shows in my factories. They tend to be controlled by combinator logic. With modded combinators I have managed to build factories, which highly adapts to the situation, like assemblers, which change production depending on what is needed. Scale up and make all combinators do this and they happily supplies lots of red science if researching something requiring a red science every 5th second while with normal red science usage, a lot of the assembers switch to something else. Likewise smelters are combinator controlled, or rather the belts to smelters. Belts can select which ore to input depending on storage of the output metal. This means a balanced output for normal operation, but it can go as extreme as switching everything to iron if it detects a severe shortage.

I once set up a controller for AAI vehicles. It read vehicle data, had combinators to decide what to do with the vehicle and then used a vehicle controller to do as planned. The thing is the calculations were done in different branches in parallel and being the hard realtime as combinators are in ticks, I made each branch take precisely the same number of ticks to calculate. This allows pipelining and while it had a full 7 ticks from reading vehicle to new orders being assigned, it could handle a new vehicle each tick. This provided enough throughput to allow just one vehicle controller to maintain a significant fleet of vehicles. I have also made a low latency version to make vehicles follow arrows (zones) instead of using biter navigation.

I also have fun with more advanced combinator layouts, like memory banks, calculating recipe requirements and requirements for the requirements and so on.

Now I start to wonder what other factories look like. Most likely they are fairly different from mine.

Nightinggale wrote: Sat Dec 22, 2018 9:54 pm

F wrote:What intrigued me was the large variety of backgrounds they came from - differents kinds of engineers (mechanical, CS, electrical, ...), mathematicians, physicists, and even people with real pipes hands on experience.

I'm not surprised, but this quote made me start to wonder how the background affects the factories. Will a mechanical engineer make a different base than a physicists? What about mathematicians?

Personally I have a background in electrical engineering and it shows in my factories. They tend to be controlled by combinator logic. With modded combinators I have managed to build factories, which highly adapts to the situation, like assemblers, which change production depending on what is needed. Scale up and make all combinators do this and they happily supplies lots of red science if researching something requiring a red science every 5th second while with normal red science usage, a lot of the assembers switch to something else. Likewise smelters are combinator controlled, or rather the belts to smelters. Belts can select which ore to input depending on storage of the output metal. This means a balanced output for normal operation, but it can go as extreme as switching everything to iron if it detects a severe shortage.

I once set up a controller for AAI vehicles. It read vehicle data, had combinators to decide what to do with the vehicle and then used a vehicle controller to do as planned. The thing is the calculations were done in different branches in parallel and being the hard realtime as combinators are in ticks, I made each branch take precisely the same number of ticks to calculate. This allows pipelining and while it had a full 7 ticks from reading vehicle to new orders being assigned, it could handle a new vehicle each tick. This provided enough throughput to allow just one vehicle controller to maintain a significant fleet of vehicles. I have also made a low latency version to make vehicles follow arrows (zones) instead of using biter navigation.

I also have fun with more advanced combinator layouts, like memory banks, calculating recipe requirements and requirements for the requirements and so on.

Now I start to wonder what other factories look like. Most likely they are fairly different from mine.

Switching input on belts to smelters sounds incredibly interesting! I never thought about that. Can you share a map with us that has these things? I use combinators extremely sparingly (I'm a computer science engineer if that matters) to limit how much is made of certain items. For instance, only create silver ingots when there are less than 1000 in a chest.

Dominik wrote: Sat Dec 22, 2018 5:47 pm

Selvek wrote: Fri Dec 21, 2018 7:40 pm Can you give us a bit more info on how placing pipes will work with the new anti-mixing logic? Can you confirm or deny that this will allow running parallel pipes without them accidentally intersecting? I could see this being a problem potentially (esp in blueprints) if pipe connection order is dependent on placement order though...

No, you can't put the pipes next to each other. It simply does not allow any action that would allow fluid mixing.

The question is whether it's possible to modify further the pipe placing mechanics.

If there are two different systems being toched by a pipe being placed, the player could select which one to connect to (by pressing the rotate key) and it would not connect to the other system. (Edit: another option would be remember the last touched fluid system and stick to it in times of ambiguity.)

That's a very powerful feature in Factory Town and I believe Factorio could benefit from it, too.

Sir3n wrote: Sat Dec 22, 2018 12:23 pm
This would lose the wave-like behaviour of fluids in pipe though. But I think it's worth it because the wave like behaviour doesn't really matter in a long pipe; what we (as players) really care about is how much throughput we get out of it at the exit for what we put into the pipe.

Sorry, but not all of us are included in the collective 'we.'

I am thrilled about the new system, and the inclusion of waves.

Dominik wrote: Sat Dec 22, 2018 6:55 pm

Avezo wrote: Sat Dec 22, 2018 9:46 am How will this work with non-pipe fluidboxes, i.e. turbines or steam engines? For example, how will low temperature steam mix with high temperature one? Or they just won't? It's technically the same fluid and there were nuclear builds with adding additional steam engines at the end to utilize leftover steam, soooo.

This remains unchanged, temperature is an independent variable. Fact is I wanted to remove temperature as it is a lot of data for little gain but apparently some mods make a good use of it so it stays.

Never used such mods, but maybe it would be worth removing it anyway while providing the same functionality in a different way (if possible), similar to what was done with mining hardness? I.e. there would be technically multiple fluids at multiple 'temperatures' (i.e. fluidium@100degree, fluidium@101degree, fluidium@102degree, etc.), temperature mixing would be done via changing one fluid into another, but on the user-side it would look the same. Unless those mods require really high precision of temperature, dunno.

I'm suddenly more inclined to get a macbook to use instead of linux, not entirely sure why, though really I should get one anyway as I don't currently have anything for compiling on OSX myself...

At any rate; nice work on the fluid system, this sounds much more logical for fluid mechanics and solves both issues where oil may be "too easy" to distribute, and steam too silly (as someone that made multi-gigawatt reactors, having to work out weird piping) to work with...

If steam can run 100% without pumps as well, it makes logical sense in how steam turbines work in both push and pull pressure, whereas in the current systems the turbines/engines only run on pull pressure via cooling the steam down. Which of course still works IRL, but the majority of steam systems made have been push pressure primarily, with pull pressure only coming in on more modern closed-loop systems (steam passes through a condensator pool, with the water forcefully sucked through back to the reactor core, maintaining a high negative pressure).

That does however bring up an idea for a new condensator machine, which could be attached to the end of a line of turbines to boost their power output as well as provide a water feedback. Doing this however would remove the visible steam cloud output, and I guess it wouldn't make much sense for it to be an open turbine either, so instead either a new turbine would be needed, or the turbines would have a cap put on top of them when the condensator is attached...

Sir3n wrote: Sat Dec 22, 2018 12:23 pm The FFF says "pipes to ground won’t help you with throughput anymore"

Not pasting the whole thing. It will probably make a substantial difference to rendering performance with megabases built on productivity PCs with APUs, especially if they're laptops. These systems are seriously limited in graphics hardware to the point where Factorio is one of very few new games that will run on them with decent frame rates. Rendering is the reason: underground pipes don't have windows, while above ground pipes do, and that window does show the fluid level if it gets low enough, and it shows the flow rate and direction as an animation even in older versions. If that hasn't changed (and I see no reason why it would, wait, I can check in the post's animation - no it didn't), then the computer still needs to draw that. So, UGPs will still help with FPS, but not UPS. But I don't think they'll help with throughput 'cus I don't think they reduce the number of fluidboxes and total net size.

<NO_NAME> wrote: Sat Dec 22, 2018 4:01 pm

Loewchen wrote: Fri Dec 21, 2018 8:27 pm

5thHorseman wrote: Fri Dec 21, 2018 8:13 pm I don't know what you guys screwed up, but I'm noticing a distinct lack of complaints in the replies so it must be something HUGE.

Just wait until the I-want-fluids-to-be-as-simple-as-electricity proponents get here...

I want electricity to be as complex as fluids.

Please meet me in FFF#270 to see if we convince them to help us out. (TBH, I don't want electricity to be as complex as fluids, but I do want it to have some gameplay elements that it doesn't currently feature.)

Nightinggale wrote: Sat Dec 22, 2018 7:35 pm * The actual speed is the speed of light, which is 299.792.458 m/s. Depending on the metal, it can lose a little bit of speed, but it's still very close to that number. 300.000.000 is a common approximation as it's often close enough and it makes the calculations much easier, like allowing all calculations in this post to be done without a calculator. It doesn't really matter if the answer is 4k or 5k km/tick. Both are way too fast to justify Factorio not assuming the speed to be instant.

Actually, the travel speed depends on the dielectric constant of the volume around the wire and switching speeds depend on capacitance. This is why microchip manufacturers are trying to reduce the dielectric constant in the interconnect insulators, but increase it in MOSFET (generic gate-dielectric-channel type transistor however it's formed) gate insulator. It is usually a significant fraction of the speed of light, but is still significantly slower. Not so long ago, both insulators were made of simple SiO2, but now they are very different. The thing is, this matters far more when it comes to computing logic on tiny tiny scales (i.e. in a five-billionth of a second for a 5GHz processor, light can travel just 6cm, and electricity somewhere around half that ...not much compared to a PC motherboard), while on the scale of power grids, it doesn't really matter. 99% of the reason we have AC instead of DC on large scale power grids is because it allows us to use non-switching transformers to step the voltages up and down (and I can't remember what the other 1% of the reason was.) Wire resistance cares about current and not voltage, while the total power is the product of the two. This is why my local grid is going up from 4kV to 25kV. It's only down to household voltages from the pole transformer, and most houses can see three or four of those in good visibility ...and if the visibility isn't good enough to see the nearest one, go save all your files this instant!

Dominik wrote: Sat Dec 22, 2018 6:47 pm Flow rate - the issue is a part of the game. If one pipe is not enough, well, figure it out

I already answered that. If one pipe isn't enough then one "could" add another. But the machine itself still needs more than what that one pipe can push through.

"So add another machine then?"
That defeats the whole purpose of upgrading. If i went by that logic, i would be using slow everything and build wide.
Upgrading means you consolidate your big stuff into as small packages as possible to save space and thus headaches both in UPS and in managing the whole base.
Add biters and you know why building wide is not as easy as just adding another pipe.

Dominik wrote: Sat Dec 22, 2018 6:47 pm Fluid clearing is reasonably fast. Would be faster with higher threshold but I also don't want to make fluid disappear when it should not. Anyway, I can't imagine how you use one pipe for different fluids with the new system against mixing.

Exactly! I don't want fluids to disappear either. Hence the new system concerns me as i frequently empty whole sections of piping. If not because i want to use the same pipe for a different fluid in a different stage (may i remind you there's mods, mods add more fluids than vanilla) and even on the same machine. But then because i want to use the same train stop sometimes for different fluids as the need arises.

If Factorio was threedimensional (it's basically 2.1D with underground pipes and belts only) then these issues could be solved easier.

I've come up with ways to clear pipes automatically (essentially flushing them) by pushing one last batch through them before they change to a different recipe. This fixes any rounding errors that occurred during the last batch.

And even then, some batches frequently leaves pipes empty while running as the machines requesting fluids are faster than the ones providing them. Having fluids automagically disappear every cycle means there's going to be lost fluids.
100 pipes * 0.05 = 5 units of fluid magically gone every cycle. Cycles can be as slow as a couple of seconds or as fast as a few ticks. So there could theoretically be 150 units of fluid just magically *POOF* every second.

And finally, what happens with really really long pipes? The fluid level will equalize right? If you add 5 units of fluid to a 100 pipe long section that fluid will go POOF despite you expecting it to arrive at the other end.
Now imagine megabases (because you said it yourself, "figure it out") where you can have sections of pipe as long as 1000 tiles for the less hungry parts. You add 50 units on one end and that levels out over 1000 fluid boxes and it never ever arrives. You made yourself a VOID pipe by mistake now.

Dominik wrote: Sat Dec 22, 2018 6:47 pmThe other properties - unfortunately no. Any variable increases the memory footprint which is significant for performance. We eliminate all that does not make significant contribution to the game.

Which is exactly why, from a simulation standpoint, making every pipe entity simulate separately is a bad idea. For memory reasons.
Why do we have to "see" each pipe simulate flow when we can barely see what's happening anyways unless we use debug options?

I would very much prefer it if each connected section/lengths of pipes were a single fluid box and all the movement was done visually rather than simulated.
Consider the following image...



It doesn't show what's happening behind the scenes but it does show something is happening.
I suggest fluids would do the same. (And even belts to be honest)
Instead of simulating every single step along the way, say "this packet of fluid will move from A to B at speed X and thusly arrive at consumer B on tick Y" and visually represent this movement linearly through an animation. You save a WHOLE LOT of memory and CPU cycles this way. In fact, done right, animations live on the GPU. So the CPU basically goes on vacation compared to the old and now the new system.

EDIT: I am not proposing teleportation BTW. I am proposing you do the calculations ONCE per add/remove event and WAIT until the conditions are met for that packet (I.E, packet created at tick 123, has 50 units and will move from A to B through points C, D, E, ... (using path finding and visually following that path linearly on the GPU) at a speed of 0.2 tiles per tick and will arrive at B on tick 234 for the requester to process)
Graphics will deal with all the visual stuff.

Dominik wrote: Sat Dec 22, 2018 6:55 pm This remains unchanged, temperature is an independent variable. Fact is I wanted to remove temperature as it is a lot of data for little gain but apparently some mods make a good use of it so it stays.

Imagine if people thought that way back when... "Remove possibilities for innovation because we are fine with the way things are now"
We wouldn't have more than 640K RAM...

Point is, one needs to think ahead of the curve. "Is it needed now? No... Can it be used for interesting things later on? Yes!"
If Factorio was open source, it wouldn't be a problem. But Factorio isn't open source, hence modders are at the mercy of what you can provide.

Temperature exists currently and the game doesn't use it but interesting mods arose from the mere existence of it.
What other features could have been used by modders to make fluid aspects of the game more interesting? Actual pressure in kPa? Superheated flow? Vacuum? Water Hammer? Overheating? Flammables? Gas vs Liquid? Superfluids?
Without a backend to support future development, you are tied to your own imagination and time allowance.

Sure, they can make their own game when they want these cool things. But if we kept thinking like that, we would have 99.99999% unfinished games as everyone went and did their own things. Modding isn't about being able to change a few things. It's about being able to completely overhaul the game. The modding API should offer features to allow one to change everything at its core. IMHO.

I know LUA is bad for performance. Hence one needs to take that into account as well. Add core features that run really fast while still offering flexibility for when the need arises.

Cadde wrote: Sun Dec 23, 2018 7:44 am Point is, one needs to think ahead of the curve. "Is it needed now? No... Can it be used for interesting things later on? Yes!"

This was cool logic to have a few years back, but the devs have swapped from that mindset to "we gotta get off this wild ride NOW" mindset, which frankly I can't blame them. There's no "interesting things later on" with this game anymore. It's a rush to the finish line, trim the loose ends, ship it. Sucks if you want to see those loose ends delivered further, but again this game needs to come out already.

Besides, dominik's logic for keeping it was exactly so that modders could make use of it.

Dominik wrote: Sat Dec 22, 2018 6:55 pm

Avezo wrote: Sat Dec 22, 2018 9:46 am How will this work with non-pipe fluidboxes, i.e. turbines or steam engines? For example, how will low temperature steam mix with high temperature one? Or they just won't? It's technically the same fluid and there were nuclear builds with adding additional steam engines at the end to utilize leftover steam, soooo.

This remains unchanged, temperature is an independent variable. Fact is I wanted to remove temperature as it is a lot of data for little gain but apparently some mods make a good use of it so it stays.

Hello my i step in ......

I would find it very nice if the temperature will drop over time when not inside a special container (pipe, storage-tank, chest?) a small amount, defined in the spec of the item or calculated from properties....

Reason for me is i made some recipes for energystorage which uses a temperature storage-methode (producing higher temperature items using electricty), but for now the fluid stay at the given temperature infinite. that would be only a small step toward 'reality' if in such storages (say 600°C) the temperature will drop a little over time when not in isolated containers....
Isolation-material is already in the game as plastic-bar

Drury wrote: Sun Dec 23, 2018 8:03 am This was cool logic to have a few years back, but the devs have swapped from that mindset to "we gotta get off this wild ride NOW" mindset, which frankly I can't blame them. There's no "interesting things later on" with this game anymore. It's a rush to the finish line, trim the loose ends, ship it. Sucks if you want to see those loose ends delivered further, but again this game needs to come out already.

Besides, dominik's logic for keeping it was exactly so that modders could make use of it.

Yes, temperature stays in but i was talking about things besides temperature. Right now (can't speak for the new system until i've tried it) fluids are just a different kind of transport belt. With its own limitations and advantages.
But that's it, beyond that, fluids are just a different means of transport and there's no progression on pipes. Once you have pipes, you have pipes. Once you've added pumps, you have pipes with as high flow as you can get.

Belts on the other hand have so many different factors to consider. Speed, at what point do you add or remove items from them? You can run them parallel (without them connecting) and even mix items on them. You have a few ways of loading and unloading them (with mods that is) and you can manage each item separately.
Belts (items) will feed into machines from any direction. With custom inserters you can even expand this further.
Belts doesn't need power to maintain their flow rate, unlike pipes.

But pipes? Well, here's your bog standard pipe... It carries one type of liquid at a fixed rate. Adding and removing is easy but you can't filter it, you can't run pipes tightly parallel to each other (without mods) and you have to use 2x1 tile pumps to keep their speed up. Those 2x1 pumps need power even between the producer and consumer.
Machines only have so many ports to input and output fluids. Some machines have 5 different fluids and unlike belts, pipes tend to become horrible spaghetti at that point. Once you've reached the limit of a single pipes unaided throughput, you are basically doomed if you had a line of machines. You would have to separate them so much that you may as well build separate outposts for them.

Pipes are the forgotten orphan of Factorio and i was hoping they wouldn't be in this update. This by adding more to them while fixing the splitting fluids equally issue. And any UPS improvements shouldn't come at the cost of features or usability. Which is why i am concerned with the next implementation.

In essence, the next implementation fixes the splitting issues. But i fear it's going to be at the cost of features and usability at which point 0.16 was the better version still. Splitting was fixable with modding.
And again, the more UPS friendly version is still to reduce the number of calculations being done. The blog clearly states the new system is SLOWER but can be multithreaded. It's not solving anything really, it's just using more cores to do the calculations alongside everything else that will be using all cores to great effect.
Optimizations shouldn't be about merely splitting logic to more cores. They should be about doing it in a way where no more work is being done AS IS and just splitting the workload.
The new pipe system is a step backwards for the mere sake of "no teleportation" and "multithreading".

As i've already pointed out, you don't have to teleport fluids. But you can reduce every pipe to pipe interaction to a single calculation done once and thus saving you from the need to do multithreading in the first place. And the visuals can then be multithreaded all day long on the GPU.

Nightinggale wrote: Sat Dec 22, 2018 8:01 pm ...
This got me thinking. If a pipe is really just a link between two entities, how about adding some code to detect the stable condition and if it's stable, just teleport fluid between the entities and leave the pipes with a constant level and flow. If the level at the entities goes out of the stable level (read not the same as at the start of last tick), start to calculate each pipe again. At some point it will hopefully go back to a stable condition in which case it can go back to teleport mode.
...

This has been discussed before. In short, such conditions occur very rarely and imo it is not worth the complexity. See some previous discussions for details and other ideas.

Sander_Bouwhuis wrote: Sat Dec 22, 2018 8:55 pm Ooooooooooooh! Picker pipe clamp (https://mods.factorio.com/mod/PickerPipeTools) is EXACTLY what should be in vanilla Factorio!
Devs, please, please, pretty please with sugar on top: consider this in vanilla Factorio. It makes 100x more sense!

Yes, this is very nice and on the list. If it makes there in time I don't know.

Actually the coming new pipe management in 0.17 should make this mod obsolet

Cadde wrote: Sun Dec 23, 2018 7:28 am

Dominik wrote: Sat Dec 22, 2018 6:47 pm Flow rate - the issue is a part of the game. If one pipe is not enough, well, figure it out

I already answered that. If one pipe isn't enough then one "could" add another. But the machine itself still needs more than what that one pipe can push through.

"So add another machine then?"
That defeats the whole purpose of upgrading. If i went by that logic, i would be using slow everything and build wide.
Upgrading means you consolidate your big stuff into as small packages as possible to save space and thus headaches both in UPS and in managing the whole base.
Add biters and you know why building wide is not as easy as just adding another pipe.

That is not gonna happen in vanilla and if somebody mods such a machine, it is their problem. They can mod a bigger pipe size too.

Cadde wrote: Sun Dec 23, 2018 7:28 am
And even then, some batches frequently leaves pipes empty while running as the machines requesting fluids are faster than the ones providing them. Having fluids automagically disappear every cycle means there's going to be lost fluids.
100 pipes * 0.05 = 5 units of fluid magically gone every cycle. Cycles can be as slow as a couple of seconds or as fast as a few ticks. So there could theoretically be 150 units of fluid just magically *POOF* every second.

And finally, what happens with really really long pipes? The fluid level will equalize right? If you add 5 units of fluid to a 100 pipe long section that fluid will go POOF despite you expecting it to arrive at the other end.
Now imagine megabases (because you said it yourself, "figure it out") where you can have sections of pipe as long as 1000 tiles for the less hungry parts. You add 50 units on one end and that levels out over 1000 fluid boxes and it never ever arrives. You made yourself a VOID pipe by mistake now.

The current limit is 0.05 fluid, not volume or %. So 100x less than what you write.

Cadde wrote: Sun Dec 23, 2018 7:28 am

Dominik wrote: Sat Dec 22, 2018 6:47 pmThe other properties - unfortunately no. Any variable increases the memory footprint which is significant for performance. We eliminate all that does not make significant contribution to the game.

Which is exactly why, from a simulation standpoint, making every pipe entity simulate separately is a bad idea. For memory reasons.
Why do we have to "see" each pipe simulate flow when we can barely see what's happening anyways unless we use debug options?

I would very much prefer it if each connected section/lengths of pipes were a single fluid box and all the movement was done visually rather than simulated.
Consider the following image...



It doesn't show what's happening behind the scenes but it does show something is happening.
I suggest fluids would do the same. (And even belts to be honest)
Instead of simulating every single step along the way, say "this packet of fluid will move from A to B at speed X and thusly arrive at consumer B on tick Y" and visually represent this movement linearly through an animation. You save a WHOLE LOT of memory and CPU cycles this way. In fact, done right, animations live on the GPU. So the CPU basically goes on vacation compared to the old and now the new system.

EDIT: I am not proposing teleportation BTW. I am proposing you do the calculations ONCE per add/remove event and WAIT until the conditions are met for that packet (I.E, packet created at tick 123, has 50 units and will move from A to B through points C, D, E, ... (using path finding and visually following that path linearly on the GPU) at a speed of 0.2 tiles per tick and will arrive at B on tick 234 for the requester to process)
Graphics will deal with all the visual stuff.

I have seen the packet proposal before. It 1) ignores throughput limits (you can limit one packet, but not the total) 2) i like realism and seeing the fluid really flowing.

Cadde wrote: Sun Dec 23, 2018 8:55 am

Drury wrote: Sun Dec 23, 2018 8:03 am This was cool logic to have a few years back, but the devs have swapped from that mindset to "we gotta get off this wild ride NOW" mindset, which frankly I can't blame them. There's no "interesting things later on" with this game anymore. It's a rush to the finish line, trim the loose ends, ship it. Sucks if you want to see those loose ends delivered further, but again this game needs to come out already.

Besides, dominik's logic for keeping it was exactly so that modders could make use of it.

Yes, temperature stays in but i was talking about things besides temperature. Right now (can't speak for the new system until i've tried it) fluids are just a different kind of transport belt. With its own limitations and advantages.
But that's it, beyond that, fluids are just a different means of transport and there's no progression on pipes. Once you have pipes, you have pipes. Once you've added pumps, you have pipes with as high flow as you can get.

Belts on the other hand have so many different factors to consider. Speed, at what point do you add or remove items from them? You can run them parallel (without them connecting) and even mix items on them. You have a few ways of loading and unloading them (with mods that is) and you can manage each item separately.
Belts (items) will feed into machines from any direction. With custom inserters you can even expand this further.
Belts doesn't need power to maintain their flow rate, unlike pipes.

But pipes? Well, here's your bog standard pipe... It carries one type of liquid at a fixed rate. Adding and removing is easy but you can't filter it, you can't run pipes tightly parallel to each other (without mods) and you have to use 2x1 tile pumps to keep their speed up. Those 2x1 pumps need power even between the producer and consumer.
Machines only have so many ports to input and output fluids. Some machines have 5 different fluids and unlike belts, pipes tend to become horrible spaghetti at that point. Once you've reached the limit of a single pipes unaided throughput, you are basically doomed if you had a line of machines. You would have to separate them so much that you may as well build separate outposts for them.

Pipes are the forgotten orphan of Factorio and i was hoping they wouldn't be in this update. This by adding more to them while fixing the splitting fluids equally issue. And any UPS improvements shouldn't come at the cost of features or usability. Which is why i am concerned with the next implementation.

In essence, the next implementation fixes the splitting issues. But i fear it's going to be at the cost of features and usability at which point 0.16 was the better version still. Splitting was fixable with modding.
And again, the more UPS friendly version is still to reduce the number of calculations being done. The blog clearly states the new system is SLOWER but can be multithreaded. It's not solving anything really, it's just using more cores to do the calculations alongside everything else that will be using all cores to great effect.
Optimizations shouldn't be about merely splitting logic to more cores. They should be about doing it in a way where no more work is being done AS IS and just splitting the workload.
The new pipe system is a step backwards for the mere sake of "no teleportation" and "multithreading".

As i've already pointed out, you don't have to teleport fluids. But you can reduce every pipe to pipe interaction to a single calculation done once and thus saving you from the need to do multithreading in the first place. And the visuals can then be multithreaded all day long on the GPU.

Having lot of features is nice for one person and bad for another. Myself, I believe the philosophy that perfect is what you can't take anything out. Not when you can't add more. Adding new stuff and making the game more complicated is something long time players appreciate, but it hurts playability for new players who will just be confused and not like the game if it is too overwhelming. That is often forgotten - I think that the long time players should keep in mind that the game is not only for them.
Adding more moddable stuff is nice for modders and "mod" players, but makes the game slower for everybody. Which includes advanced "megabase" players. Some decisions are about what we can/want do, but some are simply about finding a balance for different players.
That being said, having more around pipes, both usability and features, would be nice. And who knows, perhaps in some later future. But right now we need to focus on finishing the game.
(edit) The optimisation is not just about multithreading, that is actually just an extra bonus. Most of the ~80+% speedup is not by multithreading.