Version 0.17.32

[Hannu]

But currently I'm talking not about perfection, but about two instances of the same blueprint to behave identically.

In my opinion it is not only correct assumption that they should behave identically. They should behave predictably. Practically all machines are individuals. Manufacturers give certain acceptable range for performance and other properties. Of course most virtual worlds behave more perfect way, but it is weakness of them and not strength.

Then Factorio will lose half of its audience.

Yes, unfortunately this is true. But I still hope that at some day someone (maybe artificial intelligence if humans are too greedy for it) will make interesting game for engineers which do not try to be easy to begin or have beautiful graphics, but instead have complex and interesting mechanics and room for planning. Factorio would be very good starting point for such a game. I mean something like Orbiter is in space games.

[leadraven]

In my opinion it is not only correct assumption that they should behave identically. They should behave predictably. Practically all machines are individuals. Manufacturers give certain acceptable range for performance and other properties. Of course most virtual worlds behave more perfect way, but it is weakness of them and not strength.

I have nothing against mathematically predictable defects, faults, breakdowns etc. But fluid flow has systematic defect. It is not a defect of in-game entity, it is bug of game engine.
And yes, most people like when their creations work at 100% efficiency, not 99.99%. This 0.01% will drive them crazy. Pursuit for perfection is the main reason to play Factorio again and again. If 90% is enough for you, then why would you play Factorio again?

[Hannu]

And yes, most people like when their creations work at 100% efficiency, not 99.99%. This 0.01% will drive them crazy. Pursuit for perfection is the main reason to play Factorio again and again. If 90% is enough for you, then why would you play Factorio again?

I use different mods and personal rule sets. I also do not use blueprints between games (expect belt balancers or such trivial things). I build little bit different production setups every time.

[BlueTemplar]

In my opinion rotation sensitivity of inserters is much more annoying problem (however, I would not say major). It mixes lanes of belts and leads to complete malfunctions if you just rotate blueprints without taking inconsistent behavior into account. Oddities in fluid mechanics lead to differences in practically non-significant decimals but fluid goes always eventually where the pipes lead it.

Wait, I thought that inserters were rotation-invariant ? And that it was the mirror-antisymmetry that caused issues if not planned for ?

[BlueTemplar]

The fluids are on the program but I have only had little time to do experiments between all the bugs. Right now the fluids seem to be pretty much bug free so I should get to the fluids again - along with the character gui.
Yes, the more accurate model is slower, not faster. Right now it is as fast as it gets as the model is oversimplified.

People are requesting I re-add the multiple pipe diameters (larger/smaller fluid boxes) mechanic in my logistics mod. is this something that's going to break again in the near future?
Is the ability to set different fluid viscosities on the table?

The FFF said that the two parameters (corresponding to wave speed and viscosity?) would be added back, and even set for different values in vanilla this time.
This post seems to be not so sure about that :
viewtopic.php?p=409524#p409524

[Bilka]

People are requesting I re-add the multiple pipe diameters (larger/smaller fluid boxes) mechanic in my logistics mod. is this something that's going to break again in the near future?
Is the ability to set different fluid viscosities on the table?

The FFF said that the two parameters (corresponding to wave speed and viscosity?) would be added back, and even set for different values in vanilla this time.
This post seems to be not so sure about that :
viewtopic.php?p=409524#p409524

Here is a thread asking for the parameters to be added back, if you want them back it would be great if you could show your support there: viewtopic.php?f=28&t=69479

[BlueTemplar]

Why it is major problem? Did you find some configuration which do not work?

How could you play Factorio without perfectionism?
And yes, I have throughput bugs in nuclear plants and fluid stations. I can't even measure throughput because it changes unpredictably.
It is one of core game mechanics. Any bug related to it is critical.

Again, concrete (blueprint/save) examples please !

I have nothing against mathematically predictable defects, faults, breakdowns etc. But fluid flow has systematic defect. It is not a defect of in-game entity, it is bug of game engine.
And yes, most people like when their creations work at 100% efficiency, not 99.99%. This 0.01% will drive them crazy. Pursuit for perfection is the main reason to play Factorio again and again. If 90% is enough for you, then why would you play Factorio again?

Efficiency of what ? Generally trying to raise efficiency to 100% for one metric is going to drop it for another. You'll have to decide on some balance.
Different games will have different goals : (usually) minimize pollution for Death Worlds, minimize footprint for (early) Sea Block, minimize resource consumption if playing with low resources, maximize UPS in megabases...
But there will still usually be a tradeoff, and at the most fundamental level, since it's a game, you want to maximize fun - and doing the same thing over and over might sometimes be the most efficient way to go about it, but rarely the most fun !

What if it was explained as manufacturing tolerances of pipes and other entities? And maybe added even more random variables to make more variation?

Please don't.
One problem is variation hidden from the player : fluid in pipes being mostly hidden makes it much harder to understand than for instance belt throughput issues. (Trains and bots would be somewhere in-between?)

We already get enough randomness in the form of map layout and biters. But this is prominently displayed randomness -
1.) once you reveal the map - taming randomness by will is fun
2.) once you are attacked - being surprised and managing to triumph over the randomness is especially fun ! - being surprised and NOT managing to deal with the randomness is often a major turn-off, and only the expectation of being able to beat it the next time makes it fun again.

Humans have a much harder time to deal with hidden (pseudo)randomness that you cannot make any sense of : inconsistencies (which I guess that this discussion is ultimately about ?).

And these bugs/inconsistencies are here because it's not possible to make software 100% bug-free either.
Only the most critical industrial software is trying to - using mathematically-proven programming - and even they cannot achieve 100% bug-free (if I'm not mistaken, this is due to Turing's halting problem). Also not being able to completely isolate the computer : see cosmic rays.
So, Wube have limited resources, and are trying to optimize for maximum fun (which is in a way even harder, because it's so subjective), not 100% bug-free.

[Hannu]

Wait, I thought that inserters were rotation-invariant ? And that it was the mirror-antisymmetry that caused issues if not planned for ?

You are probably right and I remember wrong. Also, I am not sure how it works in current version. I faced that problem several version ago and have avoided it after that.

[Hannu]

Please don't.
One problem is variation hidden from the player : fluid in pipes being mostly hidden makes it much harder to understand than for instance belt throughput issues. (Trains and bots would be somewhere in-between?)

I agree that this kind of "lazy" programming is not good starting point for intended variations. Some kind of controllable algorithm based on noise functions would be certainly better.

But in real life all non-trivial machines are mostly closed systems. Users, even industrial development departments, can not understand exactly how they work. Such details are manufacturer's trade secrets and accurate reverse engineering is extremely difficult and expensive and use of such information may be risk of juridic problems. If products work in given ranges it is OK.

We already get enough randomness in the form of map layout and biters. But this is prominently displayed randomness -
1.) once you reveal the map - taming randomness by will is fun
2.) once you are attacked - being surprised and managing to triumph over the randomness is especially fun ! - being surprised and NOT managing to deal with the randomness is often a major turn-off, and only the expectation of being able to beat it the next time makes it fun again.

Humans have a much harder time to deal with hidden (pseudo)randomness that you cannot make any sense of : inconsistencies (which I guess that this discussion is ultimately about ?).

This is where your opinions may vary. Yes, I understand very well, that what you wrote is the most common opinion. Relatively simple game which do not need any special skills in engineering or calculations to play. But at least I would like to have environmental variations and use circuit combinators to adapt my factory. I could control loads to keep temperatures in allowed range etc. Combinators would fit very well in such adjusting, but currently there is no real need for them in the game. And if there were real biomes with different environment and pros and cons, I could make strategic decisions where to build.

It would certainly be a bad idea for vanilla game at default settings, but I hope there could be such variables for modding or hard mode in which such things would effect to entities. I believe that relatively interesting things could be made with reasonable work.

And these bugs/inconsistencies are here because it's not possible to make software 100% bug-free either.

It is one thing. However, I believe that in this case this is also tradeoff between speed and consistency. Current liquid model is extremely fast to compute and give possibility to operation of huge megabases and also is practically very consistent. Problem of 99.9 % efficiency in some specific situation is extremely marginal.

So, Wube have limited resources, and are trying to optimize for maximum fun (which is in a way even harder, because it's so subjective), not 100% bug-free.

We all have strict opinions what would be the perfect Factorio in the perfect world, but I think we all can agree that Wube has been extremely successful in this optimization of fun taking real world limitations into account. It is sign of very high quality that we discuss is 99.9 % performance of rotated powerplant a major bug or acceptable speed optimization. I have bought "ready" AAA-games which have crashed many times in day or been impossible to play through before update.

[BlueTemplar]

Relatively simple game which do not need any special skills in engineering or calculations to play. But at least I would like to have environmental variations and use circuit combinators to adapt my factory. I could control loads to keep temperatures in allowed range etc. Combinators would fit very well in such adjusting, but currently there is no real need for them in the game. And if there were real biomes with different environment and pros and cons, I could make strategic decisions where to build.

It would certainly be a bad idea for vanilla game at default settings, but I hope there could be such variables for modding or hard mode in which such things would effect to entities. I believe that relatively interesting things could be made with reasonable work.

Weather (including weather sensors) affecting the factory would be very cool indeed but seems to be very far from what Wube can hope to achieve for 1.0.
(Consider that even "just" a more complex nuclear system with cooling towers and risk of catastrophic meltdown due to overheat had to be scrapped...)

In a way some mods are already doing some of what you're asking for :
- Rampant, with its "biter weather" (and biter factions).
(The map already gives you plenty strategic options on where to build, especially if you make biters hard enough. Special mention for Alien biomes and the way it slows down walking speed on some of them - this often has a tremendous impact on combat.)
- Angels, with its random recipe outputs (gardens, geodes, and especially puffers).
- More complex nuclear power mods.
- KS Power with it's variable wind power.
- Weather/Night cycle mods, mostly affecting solar and wind.

[Lubricus]

My main pet peeve with the fluid system currently is that fluids cannot be easily split. This is a modded example, but in my current seablock game I have plastic and resin, both which require 100 units of methanol gas, one liquifier supplies 100 units, in an ideal world both would get 50/50, but in reality the first one built gets 100, and the other 0 until the first is completely backed up.

In general balancing don't help resource shortage's so it's often useless as in your case. So it wont runt better if it would split 50/50 you need more methanol gas not better pipes.
In setups where you are close to the throughput limit the strange fluid is annoying but that is a niche megabase problem. I was f.ex. confused when trying to make a big nuclear setup where i had some loops in the pipe that f*d up the distribution.

[boran_blok]

seeing I only needed a smidgen of plastic and urea 50/50 of 100 would have been moooore than enough for my needs.

[BlueTemplar]

If you need fluid for one use in priority, use an overflow valve (or the equivalent vanilla contraption using a tank, a pump and a wire).
If you need fluid for both usages equally (or in any % split, really), then if the input is unequal, as you say, the one usage that gets more than planned is eventually going to back up anyway (it helps to reasonably size the output buffer).

[Nixix]

Replacing pipe junctions with tanks also works for smooth splitting. With pumps they also allow reliable prioritization for both input and output, no circuit network necessary. Not that the new fluid model wouldn't be nice...

[BlueTemplar]

Yeah, shouldn't we be able to equally split using a tank, two pumps, and a two-states timer ?

[leadraven]

Yeah, shouldn't we be able to equally split using a tank, two pumps, and a two-states timer ?

I'd say, two pumps connected to one segment must split 50/50, but you know, building order...

[Hannu]

Yeah, shouldn't we be able to equally split using a tank, two pumps, and a two-states timer ?

I'd say, two pumps connected to one segment must split 50/50, but you know, building order...

If you connect two pumps straight to a tank and set circuit conditions, for example fluid > 100, both wait until there is 100 fluid in the tank and push the same amount forward during the tick when level exceeds 100. I have never used it, because reasonable planned systems work as well without such tricks, but it seems to work perfectly in videos. The function is very clear in theory, too. Limit should be at least two times the amount one pump pumps in a tick.

[BlueTemplar]

Again, what building order ?

Yep, quickly checked, in 0.16.51, with 1 storage tank through 4 pumps to 4 storage tanks, quickly connecting/disconnecting power : all 4 tanks got exactly 945 fluid. And it indeed breaks down with less than 800 fluid in the starting tank (hence, the need for the condition).

[Hannu]

Again, what building order ?

As far as I know, Factorio use list structure to store data of pipes. New builds go to end of the list (or beginning). Flow between pairs of connected elements are calculated in order determined by the list and changes of fluid amounts are made immediately. Calculation of next pair is based on the state after current pair and not from global initial state of the tick. It saves significant amount of CPU time and also simplifies memory requirements, because there is no need for save the copy of the state of whole system (which again needs CPU cycles). But then order of the list affects more or less to results. In technical computing such situation is almost always detrimental, and such methods are commonly avoided, but for gaming purpose small errors (single percents or even fraction of a percent) are practically insignificant, behavior is relatively consistent with intuitive picture of fluid flow in tubings. Then speed may be considered more important factor.

As devs have mentioned in FFFs, accurate physical model which do not depend on order in list is very complicated and very difficult to program to be fast. Maybe they succeed to make something, but I am quite sure that after it there is whining about UPS issues and other inaccurate approximations the new system needs. It is impossible to get both in this case, speed and accuracy (or if devs know how to do it, they should offer their services to industry and get even more money and benefit industrial development). I suspect that current model is so well speed optimized that there is no room for significant improvements through programming optimizations.

[BlueTemplar]

I'm aware of the potential issues, what I'm asking for is for actual proof for dependency on build order (rather than orientation) in a recent (0.16.51+?) Factorio version. I certainly haven't noticed anything like it (but then I haven't looked too hard either).