I wondered myself when I was reading the in-game descriptions, whether Death World is the same as Dangerous + Marathon or not. Whether it added a little more difficulty to one of those two aspects. Good to know that it does not. Perhaps it would be a good idea to add an extra line to the Death World...

Icons are smaller on blueprints with one icon, than they are on blueprints with multiple icons. Notice that the splitter on the left is smaller than the one on the right (roughly 86%). It was probably supposed to be the other way, where a lone icon is larger than 2 or more. http://i.imgur.com/hzLiWf...

I am really excited about the increased resolution, it's going to be great, and I think it will draw in yet more customers, probably more than most would guess. It will certainly look better on youtube and in screenshots, which will attract more people and turn off fewer candidates at the outset who...

I think I'm the only one really complaining here. I just really like this game, and I think this aspect can be better. I don't like the fact that placement order influences results, and that the moment someone actually pays attention to how the fluid moves, they notice artifacts scattered all over. ...

... Now if we have a machine that consumes 10u of fluid per tick connected on the 3rd pipe, the machine will have an efficiency of 50% since there's lesser fluid on the pipe per tick than what the machine requires. If we attach a machine on 1st pipe consuming 10u per tick, the other machine on pipe...

The cost of simulating pipes is going over and touching each pipe - cache misses as each pipe tries to flow to adjacent pipes all scattered randomly in memory. So, iterating them all twice would make it twice as expensive. How about going through the pipes randomly? Then any fluctuations should eve...

... Considering the large scale of some gamemaps and the amount of processing these games already handle, I'm all for relaxing the behavior of liquids. You say it shouldn't add overhead to the processing, but I'm not going to believe you until I see it tested in code. ... Well doing it as described...

A more thought-out version of the suggestion, including the one-pipe delay as mentioned by Yoyobuae in the post above, so that the vast majority of the calculations are done in one pass, as they are currently (parallelization would still be much faster, though): One vector (edit: for non-programmer ...

I do appreciate the responses, was just a suggestion.

The cost of simulating pipes is going over and touching each pipe - cache misses as each pipe tries to flow to adjacent pipes all scattered randomly in memory. So, iterating them all twice would make it twice as expensive. Even if the second iteration is immediately after the first, and it all fits...

Personally I did not have had any problems with fluids or the throughput of pipes so far, so it isn't really an issue for me, though fixing implementation artifacts is always a good idea. This is exactly why I included the numbers that I did in my original post, to show that the change in throughpu...

We also sort the technologies by the highest science pack needed Ooooh, this is going to make such a nice difference. About 90% of my clicking on research projects is just to see which science pack tier it is! This will cut way down on this clicking, and let me see all of them at once, instead of j...

I am extremely interested in the mechanics, how else can I properly simulate them and derive useful formulas as you just did? Thank you for figuring this out. How on Earth did you figure out that the momentum component alone is capped to [-1,1], and only for containers other than storage tanks? In c...

No it wouldn't. Touching every pipe twice would be twice as expensive. At least, the arithmetic would be the same. The change is calculated once, and applied once, just the same. Except, each calculation is made using the unchanged values, then the levels are each updated. Then all of the strangene...

Why this is then in "not a bug"? Or was this mistake? I think when they decide they don't want to fix a clear bug or oversight, then they call it "not a bug". But it looks like they're finally fixing it anyway. Abusing this "not a bug" phrase seems to be counter-produc...

obuw, my thoughts exactly. I thought through implementation details in my post, to make it as easy for them as I can without being able to change the code myself. It does not have to be complicated at all, just the very small, simple change. The real question is, why this is still not in the game? T...

Well, after examining the formulas behind it, I think it already is pretty right. Honestly, I was rather impressed by the system. It's pretty cheap, and seems like it should produce very good results. Yet, the results are sometimes quite bad, and have a lot of quirks. The only difference is in the i...

Oops, well I tried to search it up, but I could not find it suggested elsewhere. Also, all of that in the link looks somewhat complicated and involved. While I love having the option of lots of fine control customization, I think simply ctrl+clicking to add something to the front of the queue is a r...

Hello. I'm ashamed to say, that despite wanting very much to understand fluid physics in Factorio for a long time, I only just now discovered (or perhaps re-discovered, my memory is bad) these posts, which have informed me that "flow_to_energy_ratio" is about momentum, not conversion to el...

Wow, thank you so much for figuring this out. I looked all over the forums and couldn't find this information either, then I was trying to figure out the formula myself. I was about to start searching for a way to advance the game one tick at a time so I could measure the fluid levels in all the pip...