Fuegas wrote:When you upgrade your belts from yellow to red (for example) and a splitter is halfway, would that splitter be replaced with a single red belt? Currently you can upgrade just the belts and replace the splitters later without the need to be cautious around splitters.

When running down a stretch of belt that has splitters and undergrounds trying to upgrade you could potentially mess up your build accidentally with auto replace.

This could be fixed by changing the hot key from left-click to Ctrl+left-click instead but that may be awkward. You could also have splitter replacing regular belt be left click and belt replacing splitter be Ctrl+click which would be better but would require an extra button config in options.

Also I hope this is indicative of fast replacing power poles from small to medium; perhaps even following the auto-place rules you already have in that fast replace works as you're running and not placing them immediately next to each other.

The fast replacing really looks neat :D. I'm suprised nobody so far mentioned the possibility of half-underground belts left over so far tho. For example if the player runs out of belt during the replacing.

Jon8RFC wrote:Instead of extra hotkeys, I would think a more elegant solution would be to only allow the fast-replace of a splitter if the player is standing still.

It would be even more elegant if it only worked for single-click-placing and ignored drag-replace. Just because the player is standing doesn't mean he's not dragging lines of belt upgrades.

KatherineOfSky wrote:I'd like to suggest another bit of simple functionality to add to 0.16 -- the ability for assemblers/other machines to auto-set their recipe when placed over a BP ghost. This mod was recently made to do just that, and I find it invaluable: https://mods.factorio.com/mods/distantcam/ghost-copier.

That would be a nice base feature indeed. Also btw speaking of "generalization" i posted a generalized version of that mods functionality in one of the discussions (near the end) of that mod - it works for any building type. I doubt the original author is going to add it tho, so you'd have to wrap it up yourself ;)

kovarex wrote:Replace nothing. It only replaces it if there is straight belt from start to finish to avoid being "too smart and annoying".

Does it handle "straigth" belt that is bent outside correctly? (i.e. this should not be replaced)

When you mention JAI, I'd like to hear your opinion about Rust (which is actually released and used and has similar goals to C++).

And regarding the strong focus of Rust on memory safety. Did you have a lot of problems with segfaults and off-by-one-errors while programming the game in C++? How big of a share of development time did debugging such errors consume? (subjectively)

ske wrote:When you mention JAI, I'd like to hear your opinion about Rust (which is actually released and used and has similar goals to C++).

And regarding the strong focus of Rust on memory safety. Did you have a lot of problems with segfaults and off-by-one-errors while programming the game in C++? How big of a share of development time did debugging such errors consume? (subjectively)

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.

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.

Fishling wrote:It seems like the belt replacing splitters and underground will make it hard to upgrade a belt. Previously, you could just run along and upgrade the belts which would skip the other entities and then go and upgrade the rest later.

I would still rather have the new functionality over some hassle with upgrading belts. Upgrading belts is at max two times event, and not for the whole factory. But inserting splitters is something I do quite often, from the beginning all the way for the duration of the entire game.

So any distant future plans on recompiling Factorio into Jai and getting rid of .lua permanently?

Seems like possible option for Factorio 2 (If it is ready and proves to be actually as good as it promises to be)

Having watched all the videos on the youtube channel of the guy, only way I can currently see Jai failing to deliver would be if Jonathan either dies or gets severe brain damage.

Though one possibility that could make the language to not be as nice to use would be that there are infinite amount of ways to do the same thing, even more than in C, and thus the learning curve would be closer to a cliff. Of course, if one finally manages to figure things out it should be awesome to write code in.

I have to write stuff in C# at the moment and not even being able to dump plain arrays of doubles to binary file without copying them to char arrays causes physical pain :\

While experimenting with very heavily templated C++ code, i noticed that using an "Unity build" (creating a single cpp file that includes everything and building it in a single CU) reduce the compilation time by a lot.
I got a 10x improvement for my 15kloc project without touching the code.

gan_ wrote:While experimenting with very heavily templated C++ code, i noticed that using an "Unity build" (creating a single cpp file that includes everything and building it in a single CU) reduce the compilation time by a lot.
I got a 10x improvement for my 15kloc project without touching the code.

gan_ wrote:While experimenting with very heavily templated C++ code, i noticed that using an "Unity build" (creating a single cpp file that includes everything and building it in a single CU) reduce the compilation time by a lot.
I got a 10x improvement for my 15kloc project without touching the code.

gan_ wrote:While experimenting with very heavily templated C++ code, i noticed that using an "Unity build" (creating a single cpp file that includes everything and building it in a single CU) reduce the compilation time by a lot.
I got a 10x improvement for my 15kloc project without touching the code.