Factorio Forums

The HD pipes and the new pump are stunning!

Watching the pumps work their animated magic will certainly be entertaining, compared to watching barrels go by on a conveyor... But even with the fluid tanker train car, we're still going to get universal fluid barreling, right? [(Friday Facts #151)]

It'd be a good trade-off question the player gets to ask themselves:
Do they want to ship barrels and theoretically spend a 2-tile minimum for offloading [a variety of fluids] onto belts with less quantity than a fluid tanker?
or
Do they want to use a fluid tanker and at least 3 tiles space to unload [a single kind of] fluid using pumps, pipes, and possibly local storage tanks?

@repler I just added a section on multiplayer chat to the wiki "Console" page a yesterday, as well as clearer details on how to use the console features But totally agree that it's somewhat "hidden", there should be some mention of how to chat when entering an MP game, possibly a brief message shown in the console "Press ~ to open chat, messages are filtered to your team" - what do you think?

New pump looks nice and all but it may be a bit of a problem it large games. It's not very distinctive and when a map is zoomed out a little it's going to be hard to tell, especially the vertical ones. This may be what you intended i.e. to make it harder but it may also make it a bit more frustrating when pieces are not obviously different.

Would be nice if everyone's monitors and eye site where the same. Would make development easier.

Second thing was a simple optimization of the internal structure. Signals in a circuit network were stored as a std::map<SignalID, int32_t>. I sometimes heard opinions about how C++'s std::map is ridiculously slow and unoptimized, but I never really believed it. In my specific case, boost::container::flat_map not only was significantly faster but it also used less than half the memory. Finally this simple change lead to UPS doubling in some circuit network-only save.

std::map is a red-black tree, a data structure that is almost never called for (in a decade of programming, I've needed it I think twice). C++11 adds a std::unordered_map, which is a hash table (I think it builds collision lists rather than reprobing), which is far more often what you want. boost::container::flat_map appears to be a sorted vector (so it's back to O(lg N) again, but it's at least cache-friendly unlike std::map's pointer-heavy structure). If the average number of signals is less than about 16-20, then any sort of data structure more complicated than a vector (you don't even need it to be sorted!) is overkill--big O is asymptotic, and the cache behavior of dense vectors is hard to beat in non-asymptotic scenarios.

yes! more control over pipe connections.

love how you guys work on optimizations. so many devs have gotten lazy/sloppy with code.

Will we get pipe direction control on 0.15? It sure looks like that unless that was the worst nightmare of teaser...

Oh my god that rickroll is AMAZING!

I'm pretty sure the non-connecting pipe is because the sprites were put together with an image editor instead of in game.

Most of the time I like the pipes we've got. I've been using a mod that adds non-automatic pipe junctions, and I generally only use them for super compact builds. Saying that though, if there was a default equivalent that didn't make pipe-laying more complicated I wouldn't mind, since the drawback of the mod I'm using is that the entities are actually tanks, so they give different feedback than the pipes.

Just wanted to say thank you for developing this game in a way that those of us who can't afford a top-end computer can still play the game. I will eventually be upgrading so I can build a 1 minute rocket factory, just cant do it yet. I LOVE PLAYING THIS GAME!!!!!! currently it's the only game I want to play. Again THANK YOU DEVS!

flat_map, huh? The circuit network might be sparse enough that a simple unordered associative array with linear searching might yet be faster.

new artwork looks F A N T A S T I C!
gonna stare at it all day when its available

Not that I have anything bad to say about the pump graphics, but... didn't 1x2 gun turrets cause no end of issues, leading to resizing all turrets to 2x2? I hope this isn't going to be a repeat of that.
Also... 1x2 pump means likely broken saves when migrating.

bobingabout wrote:Not that I have anything bad to say about the pump graphics, but... didn't 1x2 gun turrets cause no end of issues, leading to resizing all turrets to 2x2? I hope this isn't going to be a repeat of that.
Also... 1x2 pump means likely broken saves when migrating.

1X2 turret was a problem, as they couldn't be rotated. Not the case of the new pumps. The best solution with the pumps would probably be to just remove all the pumps in 0.15 transition and let people rebuild them.

kovarex wrote:

bobingabout wrote:The best solution with the pumps would probably be to just remove all the pumps in 0.15 transition and let people rebuild them.

I am sooooo glad I won't be migrating a save....

One of the reasons why std::map is slow is because it uses a simple red-black tree (on my msvc install at least) which means traversing a linked list log(n) levels down each time you query a circuit network's value. Not to mention each node is 3 pointers plus the key/value (2 ints in this case) which means 32 bytes on the heap per value.

if you replace it with a sorted std::vector (plus a little scratch pad for amortizing adding of new networks) you can binary search it with the same O(log n) time complexity but with much lower constant factors; mostly due to cache reasons. And much less memory used (only the 2 ints per value which lets more of them fit in a cache line). This is what boost's flat_map does though without the scratch pad.

However a hashmap could be faster although std::unordered_map is a bad one to use as it is required to be a externally chained hashmap (which means some pointer chasing of 16 byte nodes) due to how the interface is defined with its buckets.

Rolling your own with internal chaining will be much faster:

Optimization of logic network is cool, but what about optimization of data store? For example, current map I play on is 90mb, and it loads soooo long...

Will we get to see HD ores next?

Fluid Train: Is there a link to the explanation of "why"? In absence of that, would someone experienced explain it to me?
A cargo wagon holds 30 items, barrels stack to 10, and hold 25 units of oil. So a cargo wagon holds 7,500 oil. A single chest, at 48 stacks, is even better for holding that oil than storage tanks. A stack inserter, pulling even just 4 units at a time, is around 150-200 fluid moved a second. I admit to not understanding fluid flow, but this thread (viewtopic.php?f=5&t=6066) says 150 fluid/second is max length 4 pipes. At zero (storage tank next to pump next to wagon?), the same speed can be reached with multiple inserters or higher upgraded inserters.
Assuming we get barrelized everything: a cargo wagon can reserve slots for various fluids, and filter inserters can pull specifics. A fluid wagon is dedicated in-use and station-stop.

Is it just because the fluid wagon is cool? Because I could believe it.

Can we spectate these challenge scenarios? I'd really like to watch