Friday Facts #206 - Workflow optimisation

[indjev99]

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.

This.

[ZombieMooose]

Idk if this has been mentioned yet but I found a potential flaw.

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.

Anyway really excited for this and good work Dev team

Cheers

[Jon8RFC]

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.

The data for the optimizations and information about current hardware are very interesting to read.

[IronCartographer]

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.

+1

[eradicator]

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.

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.

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 ;)

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)

beltreplace.jpg (79.7 KiB) Viewed 7431 times

[ske]

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)

[Rseding91]

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.

[V453000]

Non joining pipes confirmed

Things like that happen when the composition is created in the graphics editor, and not in the game.

Easter eggs on purpose

[Chaia]

Non joining pipes confirmed

Things like that happen when the composition is created in the graphics editor, and not in the game.

Easter eggs on purpose

Easter eggs confirmed

[Lappro]

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.

[torham]

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.

[ili]

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.

Suggestion
You already have 90% of the infrastructure to make an "Upgrade planner"!
Just add another tub to the new deconstruction planner.

[Serenity]

Yes! Finally be able to place splitters right over belts. That always annoyed me

Now if only we can get a way to upgrade belts in vanilla

[bobucles]

So turn the deconstruction planner into a reconstruction planner? It's true that one solution won't work for everyone, since every idea will have an exception.

[hoho]

So Jai Programming Language? You mean this?

https://en.wikipedia.org/wiki/Jonathan_ ... I_language

Yes.

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 :\

[gan_]

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.

[posila]

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.

https://www.factorio.com/blog/post/fff-118 (at the bottom)

[gan_]

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.

https://www.factorio.com/blog/post/fff-118 (at the bottom)

Holy crap... I should really find time to read all of the FFF, these are fantastic!

[kovarex]

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.

https://www.factorio.com/blog/post/fff-118 (at the bottom)

Holy crap... I should really find time to read all of the FFF, these are fantastic!

100 Proved to be the right amount. Have more, and there are too many duplications and things to link. Use less, and the threads are not used fully as the granularity is not good enough.

[ThorsDragon]

Nice work guys!!!!!