Factorio Forums

Oh jesus, finally, replace function, I love you guys !!!

I see a lot of people worried that "you can replace yellow splitters with yellow belts" means "you can't blanket replace yellow belts with red belts, because they'll also replace the yellow splitters."

I don't see why this has to be the case at all. Why can't they allow you to replace all 3 yellow belt types with the other belt types of the same color, but only allow you to cross colors, not types?

So, a yellow belt will be replacable by a yellow splitter, a yellow underground, a red belt, or a blue belt. Only.

This would give us the new functionality but not remove the functionality we have now.

Since I work with servers all day here are a few suggestions.

1) stop buying consumer grade hardware!
2) go and buy a datacentre grade SSD. They tend to come rated for a number of drive writes per day - 3 dwpd is the full capacity of the drive written 3 times a day every day for several years. Generally several petabytes of data
3) look at nvme (Intel make some lovely pci ssds, 1gigabyte/s read speeds etc)
4) if your build process could use more than one core rather than the insanely expensive i9 you could have had a 14 core xeon for a similar amount of cash

genericname1 wrote:4) if your build process could use more than one core rather than the insanely expensive i9 you could have had a 14 core xeon for a similar amount of cash

Half of the build time (or maybe even more now) is due to linking which is just single thread.

I say instead of placing the belts on the underground belt just be able to place a belt on one side of the underground and it automatically replaces the full length with the belt. Some QOL researches like Inventory Size, Crafting Speed In Inventory, Etc...

5thHorseman wrote:I see a lot of people worried that "you can replace yellow splitters with yellow belts" means "you can't blanket replace yellow belts with red belts, because they'll also replace the yellow splitters."

I don't see why this has to be the case at all. Why can't they allow you to replace all 3 yellow belt types with the other belt types of the same color, but only allow you to cross colors, not types?

So, a yellow belt will be replacable by a yellow splitter, a yellow underground, a red belt, or a blue belt. Only.

This would give us the new functionality but not remove the functionality we have now.

This sound like a solid idea. It will help avoiding switching splitters while upgrading by accident without making the planned replace-feature less intuitive.

kovarex wrote:

Ratzap wrote:Now all stock needs is the functionality from 'Upgrade planner'. Manually replacing yellow transport then red later in my sotck save is soooo tedious and error prone.

It is not on our to do list, but I like the idea of Upgrade planner, so it might become vanilla future some day.

Sadly the only thing that came up into my mind was "Wow, It will be a real nuisance without Klonan's upgrade planner...", thing is, First I do upgrade all the splitters, then the undergrounds, then I just run around up and down placing belts going through whatever is there, now, with the new feature it means I have to be careful to not destroy all the balancers and stuff replacing splitters and whatnots with regular belts...
Please, we beg you, the Upgrade Planner should go vanilla.

Not so related question, what happens to the stuff on belts/splitters/undergrounds when quick replaced? Just go to the inventory?

Thanks for the great game, community and for all of you devs being what you are. Great game, great team!

kovarex wrote:https://www.factorio.com/blog/post/fff-206

Hey there
I've written a slightly longer response regarding compilation time over at the Steams. Copying the post might just clutter this thread so I'll just link it here:
http://steamcommunity.com/app/427520/di ... 195431745/

posila wrote:

genericname1 wrote:4) if your build process could use more than one core rather than the insanely expensive i9 you could have had a 14 core xeon for a similar amount of cash

Half of the build time (or maybe even more now) is due to linking which is just single thread.

Would splitting the executable to several dlls/so's help?

Of course, it wouldn't help with full rebuild and if you alter some piece of code that affects everything but I would imagine if one works on something that effects a small piece of code, linking should be faster than linking one big executable.

Lappro wrote:I'm curious about the reasoning why you've chosen to upgrade your dev machines to i9s. Is there a reason threadripper didn't make it or was it never considered? At a quick glance it looks like you could've gotten 6 cores/12 threads more for the same price.

Either way great FFF again, nice combination of news for the average player as well as some nice in-depth behind the scenes stuff.

Lower IPC on Ryzen, and Factorio performance is more reliant on single threaded performance.

genericname1 wrote:Since I work with servers all day here are a few suggestions.

1) stop buying consumer grade hardware!
2) go and buy a datacentre grade SSD. They tend to come rated for a number of drive writes per day - 3 dwpd is the full capacity of the drive written 3 times a day every day for several years. Generally several petabytes of data
3) look at nvme (Intel make some lovely pci ssds, 1gigabyte/s read speeds etc)
4) if your build process could use more than one core rather than the insanely expensive i9 you could have had a 14 core xeon for a similar amount of cash

1. The consumer grade hardware has higher clocks / fewer cores, which benefits Factorio run speed. Compiles may take a few more seconds with fewer cores, but the game needs to run quickly.
2. Datacenter SSDs are not tuned for client workloads. Compiles are not really a datacenter class workload and even though they are heavy on writes, a modern client SSD will likely perform better overall.
3. Intel PCIe SSDs, while great for random writes, actually have relatively poor random read performance, which is critical for compile times.
4. Agreed on that point. I would have recommended 7700k's as they can easily achieve 5GHz overclocks and would likely build Factorio faster than a stock i9, not to mention the 7700k is likely the best performing CPU for Factorio overall as it has the much lower latency to the DRAM compared to i9's, so cache misses have less of a penalty. 14 core Xeon's might be better for build times but would not perform as well in the game.

I'm sure I will love the new features!
Regarding to transport belts, is this suggestion on the todo list?
Conveyor Belt Auto-Direction
(Auto rotate transport belts as long as mouse button is pressed)

The result is, that changing boost::mpl::vector66 to std::variant can improve the compile time from 1:44 to 1:20 and getting rid of templates completely by using unions can decrease the compile time to 0:53.

Ho did you realize that it was boost which adds that much time to the compilation?

in a project with 3390 files, 410k lines of code and 15Mb of source code

I guess in such a big project its hard to put fingers on 2 files easily.....also because of from what you said i think you are using boost in much more places...

ToASter wrote:Ho did you realize that it was boost which adds that much time to the compilation?

I tested replacing boost::variant with std::variant when trying new C++17 features because every time I look into the internals of a boost class implementation it makes me sad at how poorly written it is.

Great fff, as always, so interesting and appealing ! Realy, it's like reading a book, and you wait for next chapter every friday !

But can i give a suggestion about replacement belts ?

An upgrade key could be helpfull, when you press this key, under cursor (work by dragging too) :
- yellow belt is replaced by red belt
- red belt by blue belt
- yellow inserter by blue inserter
- grey factory by blue factory
- etc

(and until the key is not released, all upgraded items should be kept in memory to avoid upgrading them twice, like underground belt)

Rseding91 wrote: I tested replacing boost::variant with std::variant when trying new C++17 features because every time I look into the internals of a boost class implementation it makes me sad at how poorly written it is.

Wow. So it was just by chance.

Rseding91 wrote:I can answer that one: Rust sounds interesting at first but places *way* too many restrictions on what you can do such that I would venture to say it's impossible to write any reasonably sane program with it without having to use the "just let me do it" "unsafe" option all over the place defeating the so-called advantages it's meant to give.

Regarding segfaults/off-by-one errors: no. Those are C problems and we write modern C++ - memory leaks/off-by-one errors are a symptom of someone using C++ as C - and a sign that they aren't a good developer. Those problems were solved long ago around when the C++ 11 standard was finished in 2011.

Thanks for that answer. I've not used Rust first-hand but have some experience in C++11 and rarely encountered the problems people usually complain about. Sure, it's ugly in so many ways but on the other hand it seems to be the only game in town when digging down to the bare metal. Rust might change that but we'll see. It might be time to get some real Rust experience on microcontrollers.

Rseding91 wrote:

ToASter wrote:Ho did you realize that it was boost which adds that much time to the compilation?

I tested replacing boost::variant with std::variant when trying new C++17 features because every time I look into the internals of a boost class implementation it makes me sad at how poorly written it is.

Is it "poor" or "sophisticated beyond human comprehension"?

hoho wrote:

posila wrote:

genericname1 wrote:4) if your build process could use more than one core rather than the insanely expensive i9 you could have had a 14 core xeon for a similar amount of cash

Half of the build time (or maybe even more now) is due to linking which is just single thread.

Would splitting the executable to several dlls/so's help?

Of course, it wouldn't help with full rebuild and if you alter some piece of code that affects everything but I would imagine if one works on something that effects a small piece of code, linking should be faster than linking one big executable.

I don't know if it's feasible for production (I don't do big projects in C++) build, I guess they would have did it long ago if it would help. Compilation times are huge for many C++ projects, not only in video game industry.
Anyway for development you may try to use preloading:
https://stackoverflow.com/questions/341 ... ss-methods
So for example when working on stack optimisation you:
1. Compile the basic game once.
2. Create a separate file with new versions of replaced methods.
3. Compile this file.
4. Run the game with this file preloaded.

Then every next compilation is just steps 3 and 4. Then you don't have to make commits like "now I can split stacks" because all you do during development is "hacking" into the code by preloading some methods.

will oil derricks actually have chirality?

2 derricks in that pick are different from the other 2 derricks, or did you guys just edit that?

also, please do the non joining pipes.... it would make the world easier