Page 2 of 5

Re: Friday Facts #206 - Workflow optimisation

Posted: Fri Sep 01, 2017 9:19 pm
by kovarex
Tomik wrote:So Jai Programming Language? You mean this?

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

Re: Friday Facts #206 - Workflow optimisation

Posted: Fri Sep 01, 2017 9:20 pm
by Niko_Dreamer
This will probably never happen, but it would be cool if underground transport belts could go under other underground transport belts without interfering with the other line.

Re: Friday Facts #206 - Workflow optimisation

Posted: Fri Sep 01, 2017 9:20 pm
by TwoD
meelock wrote:The storage tank interior background really needs to be dark, otherwise, the fact that the interior isn't 3d is really glaring.
On a tank like this it would be very unlikely you'd have a window into the tank itself. You'd probably be using a by pass level indicator as you could easily replace them without emptying the entire tank (just close a valve at the bottom). Often these are tubular and put somewhere on the outside of the tank where you'd be able to easily see it, and only cover the height the fluid would be when it's around normal so you can quickly glance at it to make sure it's good.
If you think of the tank "windows" as giant flat by pass indicators, it actually makes sense to have the tank outside show through as you're not actually seeing into the tank itself.

Don't ask me about the indicators on pipes though. them physics be nuts...

Re: Friday Facts #206 - Workflow optimisation

Posted: Fri Sep 01, 2017 9:21 pm
by ohmusama
Niko_Dreamer wrote:This will probably never happen, but it would be cool if underground transport belts could go under other underground transport belts without interfering with the other line.
different kinds can. So you can weave yellow, red, and blue

Re: Friday Facts #206 - Workflow optimisation

Posted: Fri Sep 01, 2017 9:27 pm
by Fuegas
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.

Re: Friday Facts #206 - Workflow optimisation

Posted: Fri Sep 01, 2017 9:39 pm
by 125m125
What would happen if you replaced the iron belt in the attached image with underground belt? Would it trace the belt, replace part of the copper belt, replace nothing or something completely different?
Also: What happens with items on the replaced belt? are they moved to your inventory or placed on the underground belt?

Re: Friday Facts #206 - Workflow optimisation

Posted: Fri Sep 01, 2017 9:55 pm
by Eluvatar
125m125 wrote:What would happen if you replaced the iron belt in the attached image with underground belt? Would it trace the belt, replace part of the copper belt, replace nothing or something completely different?
Also: What happens with items on the replaced belt? are they moved to your inventory or placed on the underground belt?
You sir should be in QA, lol.

Re: Friday Facts #206 - Workflow optimisation

Posted: Fri Sep 01, 2017 10:00 pm
by kovarex
125m125 wrote:What would happen if you replaced the iron belt in the attached image with underground belt? Would it trace the belt, replace part of the copper belt, replace nothing or something completely different?
Also: What happens with items on the replaced belt? are they moved to your inventory or placed on the underground belt?
Replace nothing. It only replaces it if there is straight belt from start to finish to avoid being "too smart and annoying".

Re: Friday Facts #206 - Workflow optimisation

Posted: Fri Sep 01, 2017 10:12 pm
by MrGrim
kovarex wrote:
125m125 wrote:What would happen if you replaced the iron belt in the attached image with underground belt? Would it trace the belt, replace part of the copper belt, replace nothing or something completely different?
Also: What happens with items on the replaced belt? are they moved to your inventory or placed on the underground belt?
Replace nothing. It only replaces it if there is straight belt from start to finish to avoid being "too smart and annoying".
Coders that recognize the folly of software that tries to be too smart for its own good are so hot!

Re: Friday Facts #206 - Workflow optimisation

Posted: Fri Sep 01, 2017 10:13 pm
by Ratzap
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.

Re: Friday Facts #206 - Workflow optimisation

Posted: Fri Sep 01, 2017 10:25 pm
by kovarex
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.

Re: Friday Facts #206 - Workflow optimisation

Posted: Fri Sep 01, 2017 10:34 pm
by GeniusIsme
With boost being sometimes absurdly abstract I can somewhat agree, especially with graph and geometry libraries. But do they not care about compilation times? Absolutely not. Believe it or not, they went long ways to deliver compilation performance for their abstract code. It just happens that boost::mpl library was build for C++98, and can't do some cool things. Today we have alternatives which have both better performance and are easier to use.

Re: Friday Facts #206 - Workflow optimisation

Posted: Fri Sep 01, 2017 11:05 pm
by Durabys
kovarex wrote:
Tomik wrote: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?

Re: Friday Facts #206 - Workflow optimisation

Posted: Fri Sep 01, 2017 11:21 pm
by DreadIron
Tomik wrote:
kovarex wrote:
Tomik wrote: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?
Also I'm curious if there will be other language for modding in future, mainly strongly typed? Preferably Java, C# or even C++. I simply don't like dynamically typed languages :D meh . I know that for example Cities Skylines have C# for modding. I would like to dive into modding but lua is unpleasant for me :D :idea:

Re: Friday Facts #206 - Workflow optimisation

Posted: Sat Sep 02, 2017 12:35 am
by kovarex
Tomik wrote:
kovarex wrote:
Tomik wrote: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)
DreadIron wrote:
Tomik wrote:
kovarex wrote:
Tomik wrote: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?
Also I'm curious if there will be other language for modding in future, mainly strongly typed? Preferably Java, C# or even C++. I simply don't like dynamically typed languages :D meh . I know that for example Cities Skylines have C# for modding. I would like to dive into modding but lua is unpleasant for me :D :idea:
I completely agree with you. As the previous answer, if Factorio 2 was about to happen, we would use something else than lua.

Re: Friday Facts #206 - Workflow optimisation

Posted: Sat Sep 02, 2017 1:00 am
by malventano
kovarex wrote:
peet1993 wrote:I don't know where you got the 1TB value from, but i guess you got the lifetime of a single cell. This is enhanced by so-called wear leveling. But you can reach the TBW cap pretty fast aswell if you recompile often :D

Nice article, and say thanks to your new guy for this awesome QoL change!
Sorry, I meant 1000TB (I updated the post).
Frequent 5GB compiles will definitely expend typical NAND SSD endurance quickly. Even the new Intel Optane Memory (persistent but performance closer to RAM) does not have the endurance rating to handle that rate of writing for the full warranty period of the drives. RAM disks are a better solution there, especially if the size is only 5GB. Be sure you are using a RAMDisk that only optionally saves a mirrored copy to the disk (or does not at all). SoftPerfect RAM Disk is among the fastest and most compatible that I have found in my own testing (I test PC storage related things for a living). It is a paid version starting with 4.x, but 3.4.8 was the last officially free build and can be found with a bit of googling.

All of that said, SSDs won't really 'slow down' near their end of life. Not from wear anyway. They will slow down due to heavy fragmentation (repeated random writes, which fragment the flash itself even if the partition does not appear to be), but that slow down will occur within only a few hours/days of repeated 5GB compiles taking place. Drives with SLC caching like the Samsung 850 EVO will hide that effect because writes are almost always going to an empty cache area.

Re: Friday Facts #206 - Workflow optimisation

Posted: Sat Sep 02, 2017 1:40 am
by Fishling
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.


If there were a way where you could click on a yellow belt with a red in hand and it would update all reachable and connected yellows up to a splitter or underground boundary, then that would be okay.

Re: Friday Facts #206 - Workflow optimisation

Posted: Sat Sep 02, 2017 2:27 am
by KatherineOfSky
In addition to what Fishling mentioned, I am wary of belts replacing splitters because of quickly dragging lines over already placed splitters to extend the line, as well as create the 4-4 balancers, etc. It would be extremely annoying if your carefully-placed splitters were turned into belts by a simple movement too close.

I do like the ideas of splitters replacing belts, and the underground functionality -- those are great additions to the game.

I'm delighted to read the above and hear that Upgrade Builder & Planner functionality may come to the game -- IMO, it is my #1 QoL mod. The functionality is superb. After upgrading dozens of factories to higher-level belts in pure vanilla, I treasure Klonan's mod to make those changes.

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.

Thank you, devs, for working tirelessly on Factorio and making the game continually better <3

Re: Friday Facts #206 - Workflow optimisation

Posted: Sat Sep 02, 2017 3:00 am
by nthexwn
I'm a little behind the C++ times, but wasn't Boost included in the standard libraries in C++11/14/17? Does Factorio use an older C++ version, or were the Boost classes mentioned in this article not a part of that standards merge?

EDIT: Nevermind, I forgot this is C++ and you actually have full control of which classes get linked. Too much working on corporate Java with endless classpaths for me! :(

Re: Friday Facts #206 - Workflow optimisation

Posted: Sat Sep 02, 2017 3:07 am
by JCav
It seems like the fast-replace option may be a problem when trying to upgrade main bus lines....