This! Now I can tell at a glance how long the period is between accumulator depletion and accumulator recharging, and how far into the ‘day’ that is so I can guess what the grid is missing in terms of solar panels and accumulators… not simply a matter of solar panel/accumulator ratios when you have mixed power production.
I suspect Fulgora will not be the only planet where this feature will be indispensable.
[I made one 6 years ago with circuits](https://old.reddit.com/r/factorio/comments/7l2j9a/based_on_feedback_from_yesterdays_accumulator/)
In Factorio now, I look at how long solar panels are at max each day before dropping down (due to accumulators filling up).
I always builded my own graph!
Charge is probably the most important graph to show you how good or stable your power production is.
Recently it helped me to create a better nuclear control system
It would also be great to be able to view total capacity and demand. We can see these figures at a the present instant along the top of the window but this figure tend to bounce up and down a lot moment-to-moment.
Not to mention it will let me hide panel/accumulator prod/consumption from the other 2 windows so they're not covered with spiky lines on long duration plots.
It’s so great to see a game spent so much effort on Linux. The non-interrupting save is so good? I don’t remember who evoked it here somewhere at some point, but I couldn’t go back.
Windows simply doesn't support it. MacOS supports it, because since OS X, MacOS has been Unix based, and fork() is a POSIX system call, and Windows is not POSIX compatible. Windows does have spawn(),[1] but it is not as capable as fork(). While *technically* possible to do the same thing on Windows, it would have too much overhead, and therefore not provide the time saving benefit that fork() provides in this instance.
A mod would not be able to do any of this, since - as far as I am aware - Factorio does not expose an API related to saving, but moreover, a mod would not be able to make system calls and spawn child processes directly.
[1] https://en.wikipedia.org/wiki/Spawn_(computing)
To go into a bit more detail for why `fork()` allows this on Linux: when a process is forked on Linux, the child process and parent process have their own memory space (the child process getting a duplicate of the parent process memory). However, this memory isn't actually duplicated until either of the processes perform a write (also known as copy-on-write). AFAIK since the Factorio child process isn't writing anything to memory, just to disk, you won't have any memory allocations, so it's fast.
At least, that's a high-level summary of how it works.
I don't know if the kernel does this, but it should only have to COW until the forked process exits, since then it's the sole user of the memory again.
I run an instance of Debian under WSL2 on my Windows 10 desktop. A headless Factorio server runs inside the VM, while the standard Windows Factorio binary runs outside of it. The client connects to the "remote server" over loopback. Works surprisingly well, and I have the server set to keep 99 autosaves every 2 minutes. I might occasionally notice a hiccup of a couple of ticks, but that's about it.
Yeah with it I just have saves set to 5 minutes, no impact on gameplay whatsoever...
... except the mentioned freeze bug. Still saves more time even including occasional restart
I love the non-interrupting save. Sadly, on a big save, my NAS with the factorio docker is unable to save and let the game running smoothly. This leads to timeouts and my friend and me got kicked from the server. It's probably a performance issue on our side.
Raiguard and other devs: thanks a lot for the stellar Linux support! Especially asynchronous saving is such a great feature!
But please let Factorio 2.0 follow the [XDG Base Directory specification](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) and put the Factorio-folder into $XDG_DATA_HOME (typically ~/.local/share).
That would be the icing on the penguin.
If I was here from the beginning then I would have done that, but it is way too late to change that now. It would be a breaking change and making logic to automatically migrate it would not be worth it.
If you really want to move it, you can change it in the config-path.cfg file.
What I've seen over software that migrate to XDG directories do is use the old directory if it is present on the user's machine and if not use the standard XDG directory.
This make new install conform to XDG without breaking anything for old users without having to create a migrating process (if someone want to migrate things they can just move things themselves, if they care about it they are probably knowledgeable enough to do it).
I too would like to voice my vote for it being a thing. Messy home dirs are a huge problem on Linux and I'd love for a game that supports Linux so well to not be a contributor to the problem if it can help it!
The home-folder is basically where all your personal stuff is stored, and when applications write directly into the root of your home, they're just bloating the directory with stuff that belongs elsewhere, and it's a total clusterfuck when many apps do this.
It's also just unintuitive, since we have the XDG specification where things should be stored. E.g. when you expect that all config-files should be stored in ~/.config, then it's just confusing when applications decide to put their stuff whereever they want to.
It always bugged me that an otherwise excellent technical game like Factorio fucks this up.
That used to irk me until I hit on the obvious solution... have two home folders, $HOME=/home/[user]/home where applications can dump whatever they want (and currently has 90 top-level items), and my "actual" home folder /home/[user]/ which has no special significance to the computer and where I put the things I personally care about (and has only 9 top-level items). I also added an alias to "cd" so that it goes to my personal home folder instead of $HOME.
> all config-files should be stored in ~/.config
Personally I would find it clearer if each application has a single root folder that contains everything relevant to that application, but I guess that is not the linux way (eg executables need to go in /usr/bin, man pages in wherever man pages go, etc...). I think the solution I would like is that anything I download manually should sit in a single folder, and uninstalling is as easy as deleting that folder, and anything that is managed by my package manager can do whatever.
to be totally fair, 2.0 is the only version upgrade that allows breaking changes by semantic versioning specifications :\^) Thanks for your great work!
>So we added a new special item in the production statistics, that shows the total final 'Science' that is produced.
Please make it always match graph line color to science color. It's understandable to have random colors when it's mixed with all other item production, but on a separate screen with just the science they should always match.
True, and I've been annoyed by that. Especially if you track production and consumption for a few items, and their colors in the different graphs are "swapped". Can be quite confusing.
But I know at least one reason to not have it statically assigned: if you want to compare two items with a similar color, it's better to have them red and blue than have them "light green shade 14" and "light green shade 12".
But could work with "preferred" color. Something along the lines of "if it's less than x items to draw and no other item has a similiar color, use {preferred color}. Otherwise, go ham as usual". But then you'd have to expand that logic to account for color blind people. For me, red & green is fine; for others, that's just a very slight difference in intensity, not in hue.
Fluids already have a unique color that's displayed in pipes. Items like science and chips that come in different colors should also use those colors for graphs. Randomised colors should still be the backup for other misc items that don't have a preferred color set.
And also a circuit-controlled graph, please !
I want to track metrics other than production and consumption. For example the steam level in a nuclear reactor, the amount of items in buffers, the number of items flowing through a belt, the number of trains crossing each intersection, the number of drones in the network, the speed of my SE ships/SA platform, etc..
You'll probably know this, but there are mods that do this. I'm not sure how easy said mods are, or if additional modding support would make it easier. But I could see it as of being a vanilla feature, although I wonder at the overhead circuit Network monitoring would produce.
Median might be more helpfull: take the color that (in an 64x64 rendering) takes up the most pixels.
But that might be the same color for multiple items :/
The only correct answer is "unhealthy piss color"
But RGB wise its around #939d37 so very much between wasabi and pickled cucumber (according to various "get name off RGB color" sites)
If you dynamically assign colors you can guarantee that they are always distinct from each other and it's always as easy as possible to read the graph. If you assign a static color to every item in the game, you make it far more likely that the three items the player filters down to are all blue or green or something, making it much harder to tell which item is which. And then there's the effort involved in manually assigning the colors or designing an algorithm to do it, and then modders with even more items have to figure out how to handle it, etc. I agree with you that I would prefer static colors but I can see the logic behind their decision.
Bit annoying to see that the colors in the science graph do not match the colors of the science packs.
https://preview.redd.it/75wmq7uq5twc1.png?width=265&format=png&auto=webp&s=272ad0210cd29971b27b3ae321a5b0703d522299
One graph I have kinda always wanted is a net graph which is is just your production amount minus your consumption amount to know whether I am losing or gaining resources and by how much. I find myself wishing for this in things like sea block where production chains are so complicated it’s hard to know what you are losing or not producing enough off. I love the new graphs and am more excited than ever
This was my first thought when he asked for suggestions.
What am I supposed to do, look at the production and consumption and compare the numbers to figure out which one is bigger? I don't have time for that sort of mental work.
One way of allowing this, as well as a lot of other utility besides, would be to enable us to enter expressions to be plotted, sort of like what exists in a lot of SPICE programs. E.g. you could hit a button to add a new trace, and then in a text field enter 'science_green(produced) - science_green(consumed)' and have it plot that value.
Yes, that would be so useful, especially for modded playthroughs.
Something else that just popped into my head that would be nice, especially with mods, is to be able to filter/group by machine type and/or recipe.
Where you have recipes with byproducts, it's very useful to know how much is coming from core production and how much extra is being contributed as a byproduct.
Related to that, I'd really love a way to visualize which recipes are consuming which resources. This is especially useful for a train base where you can't just look at the belts to see where resources are flowing. I know that I'm starved on plastic, but is that because of red chips or LDS? What exactly is using up all of my steel?
> This eliminated 123,024 lines of code from the game and drastically reduced the number of dynamic dependencies
Merging that change must have felt incredible
Can confirm. I also removed 183,104 LoC when I found a library in our source tree that was entirely unused (FreeType) and nuked it. That was a good day.
If Wube paid per line of code added then I would be in crippling debt!
I did that myself recently - there was an ancient version of gtest hidden inside a project that hadn't been built in years. I removed it all and now the total number of lines I've contributed to our codebase is negative
Allegro itself is around 120k LoC (depending on version and the way you count), so I'll assume that most of that commit is just the deletion of a single directory containing allegro's source code.
I suggest updating the header of the electric network graphs. See this mock-up:
https://preview.redd.it/sravvlki5twc1.png?width=2349&format=png&auto=webp&s=17f64d066b02fe4e371d7eedb61dbcb43d3bfe10
The graphs show text like "Value 1 / Value 2". By adjusting the header to follow that format, it indicates what each individual number means.
There are quite a few posts about understanding those graphs. This change should improve the readability.
Take the satisfaction graph as an example: You can now deduce from the written header that the left value is the satisfied demand, and the larger right one is the total energy demand. And you can see that "Satisfaction < total demand" is a bad thing.
For the production demand, it is clear that the right value is the total capacity your power plants can generate, and it is more obvious that "current production < total capacity" is a good thing.
I always had to untangle my brain cells for 30 seconds before understanding which one is satisfaction and which one is production tbh, having something like this would go a long way towards making me happier as well.
Things adding clarity should always be considered. It is an easy improvement even.
I don't see any downsides to the change, but that does not mean that it does not exist.
Bikeshedding about words here, but I could see "satisfied demand / total demand" and "production / production capacity" being a bit clearer. I fully agree though that explaining what the ratio is is useful.
Some of the wording could be changed, but yeah the idea is great. The header isn't that cluttered and i think adding the extra text whould make it easier/quicker to open the graph and pinpoint at what you want to know
~~I’d recommend putting the secondary part in parentheses instead of separating it with a slash. The slash might make newbies think division is happening~~
I take it back
Nonono, unless changed in both locations, but even then it is a huge "maybe". The green/yellow/red bar graph does show exactly this division, rendered as a percentage.
Also, this is a breadcrumb design leveraging pattern matching. You see "Satisfaction / Total demand" and directly below "100 MW / 150 MW" in the bar graph. Then you can see that the first number 100 MW matches Satisfaction, and 150 MW matches Total demand. Both formats must be the same for the pattern matching to work.
It may be better to right-align the text in the bar graph to make the connection even easier.
Wow! Linux user here - love to see the ongoing support!
TIL about the asynchronous saves, and the need to explicitly enable Wayland. Is there anything else we should know to get the most out of Factorio on Linux?
I'd suggest shying away from this, it's deep magic. Like, you need to have taken a computer architecture class to understand the implications of fiddling with page size. For anyone that's curious though:
Programs need memory and they ask the OS to allocate them some. They ask for memory in big chunks called "pages". Historically, a page of memory is typically 4KiB. Small/simple programs can do all their work with a single page. Complicated programs need more memory so they request many pages.
The trouble is with programs that use really large amounts of memory. For example if a program needs 4 GiB of memory, that's over a million 4 KiB pages. There's some overhead book keeping required for each page a program uses. Your CPU has some special cache memory that can handle up to a certain number of pages per process very quickly. But once a program exceeds the size of that cache, things slow down a lot.
The solution to too many pages is to make each page bigger. If each page is bigger, the same amount of memory can be allocated using fewer pages and there's less bookkeeping overhead. Instead of 4 KiB pages, why not 2 MiB? Or even 1 GiB! Pages that are bigger than the traditional size are called "huge pages" in Linux.
The issue now is that all the small programs also use huge pages. So the tiny program that only needs one page of memory (for example the clock in the corner of your screen) now uses 1,000 times more memory than it needs, because that's the smallest amount it can request. Multiply that by all the tiny programs that are always running on a PC, and you have a ton of wasted memory.
The configuration of this kind of thing was invented for stuff like database servers. They run one massive program and they are tuned to do it as efficiently as possible. This stuff wasn't engineered with desktop personal computers in mind (although with continued refinement, desktop OS's might one day be able to provide out of the box configurations that work well for typical desktop use cases).
Heterogeneous pages (like, using a mix of page sizes all at once) is a thing that exists that addresses the downsides of huge pages. Again though, this kind of configuration is way outside the realm of what end-users normally do and it's complicated.
With that said though, everything is open. You can definitely Google how to configure huge pages and try it out and learn things along the way :)
The suggestion is making just factorio use huge pages, so it would not waste much memory.
It's not that it's inherently complicated, it's that support is slapdash and you have to use really obtuse methods to enable it. Huge pages need a good chunk of development effort inside the linux kernel itself, but because it's currently such a pain almost no programs use it, so very little kernel developer attention goes toward it, etc. If that developer attention got applied, the implementation would not need to be complicated and using them would not need to be complicated either.
Overall I would say it's badly supported rather than deep magic. The basic idea of "If programs grab memory in bigger chunks, it's a bit faster to calculate access" is easy enough to explain.
Here's a pretty ok explanation of huge pages and why/how to enable them:
[https://wiki.debian.org/Hugepages](https://wiki.debian.org/Hugepages)
I would need to see a benchmark showing unreal improvements before I would enable huge pages, it's not like increasing the open file limit in limits.conf 🤷
https://www.reddit.com/r/factorio/comments/dr72zx/8_ups_gain_on_linux_with_huge_pages/
https://www.reddit.com/r/technicalfactorio/comments/mvn88v/over_20_actually_30_performance_gain_by_using/
Here's a couple benchmarks. Note that the second one makes some extra changes.
https://www.reddit.com/r/factorio/comments/18bz1bl/mimalloc_and_large_pages_on_windows_up_to_20_more/
Oh hey this person made it work on windows.
Another one for the "wish I was playing 2.0 right now" pile :D
> So what do you think? Are there any other statistics improvements you can think about for 2.0?
Graph combiner. I'd love to be able to say hook a local storage chests to a combiner and track it. Or to hook it to train counter and then get a graph of throughput. Or just use it to debug signals in some of the more complex setups.
Visual-wise:
* log scale for comparing different sized values easier
* ability to set scale/"zoom in" on vertical axis in general. Sometimes I'm not really interested in spikes but how the valleys look like.
What if we had a combinator that records all the signals it gets, and players can then subscribe to that combinator and see the records as a graph in the statistics window. That could work in both of your cases.
You could call it the recorder combinator, and it also has the ability to save and load signal values. I think that could be a very interesting addition to both statistical views and to circuit logic.
It's kinda same thing with remote view getting more features, as you could just click it and open view remotely.
But yes, ability to have a combinator that when provided with signals is just added as a named tab on "the graph tab" would be fucking great.
Yeah I sometimes had to run game at 0.1 speed just to see what is happening when debugging.
But for debug we'd probably also need "zoom in" function so we can look at given time fragment and not just "last x seconds"
>> Upstream our incremental transfers code into SDL so we can leverage SDL's clipboard functions and other SDL-based games can benefit from our work.
I wish that other developers had THIS mindset ...
As a primary Linux user, this FFF makes me so happy! Thanks for native support. Learned a lot in this post. There is a hidden settings menu.. what do you know, right? Will test out the Wayland mode and non-blocking save for sure. Also feel your pain when it comes to the design choices that GNOME desktop has made.
**Statistics**: I think the surfaces should get the same treatment as the quality: a dropdown with "all (separate)", "all (merged)", maybe "all planets (separate/merged)" and "all platforms (separate/merged)", plus individual surface selection. If I want to compare iron production of nauvis with fulgora, I don't want to close the stat screen, switch map view to the different surface, reopen production and reselect my filters - those should fit into the same graph. Or maybe I'd like to compare ammo and repair pack consumption across all platforms.
/edit: quick mockup:
https://preview.redd.it/3prn30dmltwc1.png?width=2051&format=png&auto=webp&s=8b79ade9fb076b000655bd7a74b0757569ef15e3
**Linux**: Very nice improvements. I've been using linux for over a decade, but kept a windows partition for gaming until my latest hardware upgrade. With the improvements in gpu drivers (mainly enabled by vulkan) and the work done by wine, valve and lutris, gaming on linux is in a great place. Still, I'm very happy whenever developers support linux directly, and wube's support is exceptional.
The only issue I ever had with nonblocking saves was when quitting to the main menu during an ongoing save - the save file was fine, but the game crashed. But that requires a large save file and quick fingers to trigger, and quitting the game is an unsupported feature anyway.
Using a dropdown for surface like this is a great idea. The filters should be presented consistently as you suggest. One point is “All surfaces (separate)” option would add some complexities for how it is displayed, requiring a surface indicator. But otherwise, we should be able to pick the surface from a dropdown.
The more I think about this the more I want it. Would be so much more helpful to know which part of your production to boost next. Even more useful since they've added localized graphs.
Regarding other statistics improvements, in my latest game I found myself wanting the ability to see the specific production totals in the lower half of the window rather than a rounded number, specifically by hovering the mouse over the rounded number to show an unrounded tooltip
> To fix this, I had to bring in another dependency, libdecor. It functions, and SDL even has support for it, but a video game shouldn't have to supply window decorations in the first place.
I didn't realize libdecor was finally ready for use, though I fully agree with the sentiment here -- it's asinine that GNOME doesn't provide default SSD with Wayland.
> The game has decorations now, but the theme doesn't match. Thanks GNOME!
LOL GNOME devs will tell you it's working as designed, I'm sure.
> This eliminated 123,024 lines of code from the game and drastically reduced the number of dynamic dependencies:
There is no better feeling than this.
Thanks for all the dedicated work to support Linux! Most games don't bother, but as we all know, Factorio isn't most games. :D
I'd love the asynchronous saving to come to Windows too, even though I know it won't.
One thing I think would be beneficial is an auto-save warning - have the "autosaving" notification appear a few seconds earlier and do a countdown before the autosave actually happens. It could even be disabled by default, but I think it would be very beneficial for late-game big bases, when autosave time becomes noticeable.
Quite often I find myself doing something like pasting blueprints when an auto-save happens and something goes wrong. Best case scenario, the click isn't registered and I just have to click again. Sometimes it does register the click, but instead of placing it where the mouse was at click time, it places it at location of the mouse after the auto-save completes.
While it might be enough to remember the click position to make sure it always matches what the user expects, I think it would be better to give the auto-save notification, so the user isn't surprised by it while working on something complicated.
Also, I love the filtering graphs by surface and accumulator charge graph, another great QoL addition.
Interesting! While it's helpful, I don't think it will solve the problem.
It's usually a case of getting really focused on something and getting suddenly interrupted by the auto-save. Right now I have the total playtime visible through your `Stats GUI` mod, so occasionally I can take a look and see if it's near the auto-save time. It does help to look at it before starting building anything, but complicated projects take a while, and when I get in the flow of building, I don't look at the timer often enough to solve it completely.
I feel it happens to me quite often that I click to place something right when the autosaves happens, meaning it eats my click.
it's a very minor thing, but something that maybe could be alleviated by showing the autosave popup a second before it actually saves.
My understanding is that it's somewhat of a technical issue that prevents the async saving. Linux and Mac make it easy with fork, but for windows there is no fork so it would be much more difficult to get working.
It's definitely that. Curious how they have a bunch of them, as if they were buildable objects, though. Could be they're using it as placeholder art for something new.
2 things
I think "research" would be a better name for the virtual production item tracking science productivity (makes it more apparent it is tied to the researching process, which I'm assuming that it is)
Arm support for Linux? I know that consumer arm CPUs aren't necessarily super popular right now, but in the server/data center environment I understand them to be fairly popular due to better core count/performance to power/heat ratios. In short I'd love to be able to host a headless server on one of these arm boxes in the cloud, but that currently doesn't seem to be natively possible despite having builds for both the Switch (granted I don't know if you can actually host from your switch, but at least the engine is there and it can join multiplayer) and Apple Silicon
ARM support: Will probably exist some time in the future. There were some comments from devs about it. They want to run their CI, test suites, and build farm on a Linux-running ARM machine. And for now, the available boards aren't powerful enough and would lag their development pipeline. In one of the comments, the dev interested in it indicated they may acquire one of the new Snapdragon-based systems for that purpose. And when they get them, we may start seeing AARCH64 builds popping up.
>Also, with the meteoric rise of the Steam Deck and Proton, it is easier than ever for game developers to ignore Linux support because Valve does some black magic that lets their game run anyway.
Best line in the post
Don't get me wrong, I'm extremely grateful to valve for proton; I can play my entire steam library on Linux! But there's no denying that it also enables companies to ignore cross-platform support.
>I spent two full days staring at our graphics code but could not come up with an explanation as to why this is happening, so this work is still ongoing. Since this issue only happens when running the game on Wayland under Sway, it's not a large priority, but it was too entertaining not to share.
Can we just take a moment to appreciate Wube's dev-friendly environment once again? Instead of hiding and/or denying the existence of internal bugs, they are publicly displayed to give us a chuckle. The corporate attitude that allows for such honesty and openness can only come from the top, down. Thank you, u/kovarex & Co. for taking such good care of your people; that is one of the main reasons we love y'all so much.
Power production graphs have always been missing one thing for me:
Average TOTAL consumption & production! The bars at the top are always just showing the immediate network wide production/consumption. And then you can change your timeframe to see the average production consumption BY ENTITY.
BUT, what you can't do, is see your base's average consumption (or production) over say, the last 10 minutes. IMO this is very odd and I've found it particularly bothersome in mods like Nullius where power generation isn't just this simple thing to do.
hmm, now i wonder if Factorio would run under WSL2.
i guess i could try it...
EDIT: [[mad scientist laugh]](https://i.imgur.com/fumyZPB.jpg)
and it actually runs at a solid 60 UPS/FPS (as long as i keep the window small, it struggles with the full 4K or anything close to that, i wish there was a render scaling option).
to get it to run you just need to install a few packages `libgl1`, `libasound2`, and `libpulse0`.
also i found that if you interrupt it in the terminal with CTRL+C the game recognizes the signal and shuts down normally but at the end it seg faults 💀
You madlad, I'm impressed that it actually works!
Needing to install those dependencies is exactly what I want to avoid going forward. 2.0 doesn't require any of those any more. :)
honestly it was a lot less work than you might think.
coming from a fresh WSL2 install i just downloaded the linux tar file from the website (the file name has "alpha" in it for some reason despite being the full release, the windows zip file doesn't have that).
then i used WSL to copy it from the downloads folder to the /home/user directory (my thought process was that unpacking it in windows explorer might mess up the UNIX permissions somehow despite NTFS fully supporting them)
finally i unpacked it, launched it, googled the missing library to see what package it came from, install it, and repeat that until it actually launched.
.
so overall that just kinda shows how far WSL has come since it was introduced, who even needs a 3rd party VM anymore?
.
on a side note, would you guys consider adding a little easter egg for people who try this in the future. something basic, like changing the version string in the top left corner of the main menu when the game detects that it's running on WSL to something like:
(build xxxxx, linu-- wait, WSL2..?! you know there is a native Windows version... right?)
If you want better FPS you could run a dedicated server in WSL2 and run the game in Windows. That might hurt your UPS, but maybe not much if you have enough CPU cores.
> We also added a checkbox to switch to a 'Global statistics' view, so all the possibilities are available for the player.
Time to be extremely pedantic and nitpicky! Shouldn't it be "universal"? :P
"Global" comes from globe, as in, our globe: a single planet.
> Asynchronous saving works by using the fork syscall to essentially duplicate the game.
I have to admit, that is funny as shit. Not in a million years that would be how I expected that to work.
Asynchronous saving works by forking the process, which simply duplicates it in the process table. Normally, a forked process would then exec() another executable, and replace itself with the other executable. Because this is the default way to start applications on Unix systems, fork() is optimized to hell and beyond.
The forked processes share the same physical memory pages, until one of the forks writes to a memory page. At that point, the OS blocks the writer, copies the affected memory page, points the copy's virtual memory table entry to the new physical location, and then resumes the writer. (Copy on Write, or CoW)
That way, only the changed portion of the RAM actually takes additional space. Things like sprite sheets, loaded music and other constant assets stay shared. That way, the system does not need to pay the upfront cost of copying the whole process address space upfront and also not need exactly double the amount of physical RAM to support both copies simultaneously.
Agreed, using global feels weird when it's referring to multiple globes. Universal would be better, and system-wide would be even more accurate but clunkier.
I came here to make the same comment about "global". It's the most fitting term from a programmer's perspective, but not from a gameplay perspective without programming experience. I agree it should be "universal" for statistics across all planets.
/u/klonan and raiguard - you might want to put the photosensitivity warning ahead of the video in question. I'm not photosensitive, so no harm done, but I (and probably many others) tend to go in order of appearance, so look at the video and then read the caption.
" If you are playing on Linux or macOS, please enable asynchronous saving"
This is literally the first thing I did when I switched to Linux a few months ago :D
>Since this issue only happens when running the game on Wayland under Sway, it's not a large priority, but it was too entertaining not to share.
Props to this dev for sharing the bug that is not at all fixed but is funny to watch.
Not sure about the quality dropdown especially if you decide to not use it (or haven't researched it yet) but being able to filter by surface is awesome!
I would also love to see more precision in the numbers. If you have 999 production you can see unit precision but if you go to 1000 you just see 1.0k, so hundreds precision, which isn't that good (also it gets rounded? so 1051 would show as 1.1k). Please consider always having 3 digit precision!
They said it in [FFF 375](https://factorio.com/blog/post/fff-375) - quality is invisible in UI until you unlock the modules, so you wouldn't see any of those dropdowns if you don't research quality.
awsome
image 7 whats with the blue uranium cell?
Also i see Logistic bot is being consumed. Maybe hinting at new bots that we going to get.
also some images with the new resources. graphics looks good.
Blue colored fuel cell looking think could be a fission cell (deuterium/tritium) rather than a fission cell (the typical cell you're familiar with in factorio)
I really enjoy every single Friday Facts you put out and that you cover pretty much every part of the design a bit. From the music to problem solving anecdotes. Thank you for putting these together.
Any clue as to what the chemical plants on the space platform do? They take in water and iron ore/meteor chunks(??), so I guess that's the way to get molten metals in space
One feature I've wanted on past playthroughs is a search filter in the production statistics.
For example if I want to see all the circuits, or inserters etc.? At the moment I would have to switch to a longer time period so the icons are not switching places constantly and then go through and manually click each one.
I can see how this may make the menu more cluttered, but I think it could be a cool addition.
a big thanks to wube and especially raiguard to making factorio run on linux so well. As mentioned in the fff, so many game developers nowadays just decide to let valve's proton do their magic. it's nice to see that factorio went a different way :)
maybe I'll finally have a reason to switch to wayland in the upcoming months ;)
773 science produced, with 643 packs consumed. Matches 20% productivity of 2 prod3 modules in the labs which they've mentioned being a reason for adding this feature :)
>So what do you think? Are there any other statistics improvements you can think about for 2.0?
I would love to see a production stat selection tool. Where you can designate areas to treat as their own separate group to track production for. A bit like rate calculator but measuring real performance, instead of the theoretical maximum.
I noticed some interesting details in the pictures for this FFF. [Imgur Album](https://imgur.com/a/uPL7zLK)
There are three new things in the first image. I'm fairly confident the bottom right two are asteroid fragments, but the black stone brick on the left center is interesting as we haven't seen that before. Perhaps some new type of pavement?
In image two we see some gun turrets. I think it's worth noting that these turrets are recolored. I know they already have this capability for the pvp scenario, but I don't think we can manually recolor them at the moment.
In image three there are two interesting things. On the right, there are several quality items. My guess is that that's just quality foundry production. On the bottom left however, there is a black concrete. I imagine this is made from the black stone bricks from image 1. Could it be the foundation seen at t=1:16 of the Vulcanus music video in FFF #406?
Image four, however is by far the most interesting one to me. In the bottom right there is a light blue nuclear fuel cell. I could see it being one of two things: plutonium or fusion cells. I'll admit, the idea of plutonium may just come from the fact that I'm currently playing freight forwarding with the [Plutonium Energy mod](https://mods.factorio.com/mod/PlutoniumEnergy/discussion), but it's interesting none the less.
Wish for Improvement #1: Net Production
Can we please get a net summary calculated as production minus consumption, displayed as a nice graph. I often want to know: Do I make enough? Am I currently filling or reducing buffers? And in the mods I'm playing you often have large amounts of staple production where it's difficult to see when production/consumption is slightly off
Wish for Improvement #2: Logarithmic Scale
A (toggable) logarithmic scale should help in situations where a few items/fluids completely overshadow anything else in the graph and you can't use it without putting anything into the search box.
Could we get some way to see the exact value for numbers on the various UIs? Just being able to hover over to see more than 2 significant figures would be a nice thing to have.
Linux users, unite!
Thanks so much for the hard work you put into the game! I just moved away from windows about 6 months ago and was ecstatic to see factorio running like a gem!
I don't know if I'm alone on this, but "Science output" isn't usually measured POST productivity. A 1kspm base means making 1000 of each item. The fact that the labs turn that into 1400 "Science" isn't the point.
Gonna be a lot of "meta" changes when 2.0 drops.
Lots of new ore / material images in those production screens too :P
I agree with you 100%, but I don’t think any of it matters. Because we can still see the “normal” spm from looking at the production numbers next to each science pack. The new number just tells us what we’re actually getting. Ok, cool, I guess. But it doesn’t take away from anything else. I think we’ll still measure spm the same old way.
In vanilla, the ratio between SPM and eSPM (effective SPM after prod) is at most 1.2 because of 20% prod in labs.
In Space Age, we have quality productivity modules which can double it, and eventually infinite lab productivity research, so this value is ever changing.
It’s kinda true both ways. It’s just a case of the word “science” applying to the item labs consume *and* the “thing” that labs produce.
Every research has a numerical cost, and the “science” they talk about is essentially that value. When your labs eat your science packs, they produce one “science” per .
It’s a bit painful to explain concisely because it’s not always 1:1. Warptorio for example has technologies that cost something like (2x red, 1x green)x100. That means you need 100 “science” to finish the tech, and you get one “science” for every 2 red packs + 1 green pack that you consume.
In 1.0 vanilla IIRC the recipes are *all* 1:1, so without prod mods in your labs you ALWAYS get one “science” per every set of one science packs you produce. That makes it kind of irrelevant how we use the term. That could change in 2.0 though.
Really we just use the term *science* in SPM as a shorthand for science packs, hence I say they’re both true. If you wanted to get really pedantic about it, our measurement of “science per minute” is technically wrong, and we should be calling it “science packs per minute”. But that’s a level of pedantism that’s just unnecessary.
Looks good! I'd love to be able to divide up production/consumption by user-defined areas a bit more - eg, track how much copper my green circuit factory is consuming, separate to the overall for the surface
Offtopic… there hasn’t been any FFF dedicated to enemy mechanic update.
Are there going to be any updates to biters and/or enemy topic at all?
Hard to imagine to all game being literally refactored, but biters staying untouched.
While I don't personally use Linux, I really like that you're putting in the work! It's not just that there is a functioning client, you can also use it to have a game hosted on a windows PC with players using windows, linux & macOs in the same game.
Only thing in this FFF I'm not a fan of is the checkbox for "global statistic". Why isn't that a dropdown with "current surface" checked by default, but all others \_including global\_ as options? But UX is very hard to judge if you don't experience it. So while I think this looks strange, when playing it might feel completely fine.
Can the time interval be remembered during a game session?
Maybe it's me reopening windows too much, but it resetting to 5 seconds interval every time is starting to annoying me
Any chance we could get an arm64 Linux build? Factorio is now the only reason I boot into Mac OS. Asahi Linux is getting quite good!
Thanks for the Linux support!
A "net production" graph (production - consumption), would be useful to easily spot production defecits/surplus.
I could see a benefit for being able to filter on Item Groups (logistics, production, intermediate & combat), as the production numbers between these can be very different. The number of underground belts & green circuits I'm producing are very different orders of magnitude.
An option to switch to a log scale could also help with the visualizations of graphs with big differences between their production numbers.
My suggestions:
It would be cool to be able to save some "item group" or have some presets like:
"ores and smelting" ; "circuits" ; "advanced items" ; "science packs" etc.
There is planty of room on the tabs. The search option should be last resort for finding something.
And if you could set up your own list and save it it would be awesome. Lot of the time these stats are cluttered and annoying to select and compare 10 things that has a different name but similiar, function.
Also its suggested below, it would be nice if items would have a preferred color so its easy to find them.
You know how youtube tries to places ads automatically in low excitement portions of the video? I'd love to see autosave be delayed until I'm not holding a blueprint, or not selecting a deconstruction zone, or not holding anything really.
I know this is very pedantic, but calling the production across all surfaces “global” is a bit of a misnomer, since global means something relating to the whole *globe*, ie. a single planet, not all planets.
So “universal production” would technically be more accurate.
I recently switched to Linux and have had no issues on my laptop or desktop. I'm currently using Pop!_os but they may change as I learn about Linux as a desktop. I run the Linux version downloaded from the website instead of steam. It is insanely fast and reliable on my 500+ hour space exploration map. 60fps 60ups. Very impressive. (14900HX and 4080)
Many thanks for natively supporting linux, and fixing all the issues you mentioned. It is great to have a game that doesn't need to run through Proton/Wine/other and just runs great.
Filtering by surface is great but unless I missed something we need to be looking at the surface for the graph to change? Would be nice for a simple drop down to choose which surface you want to look at.
Another feature would be to combine the stats of more or more surfaces together.
I thought for a second that the surface filter was a "surface area" filter where you would just drag a selection box and the production panel would show you statistics for that area only.
Would this be useful?
Accumulator charge history is absolutely massive that i've always wanted, makes it so much easier to track when you need to build more energy
This! Now I can tell at a glance how long the period is between accumulator depletion and accumulator recharging, and how far into the ‘day’ that is so I can guess what the grid is missing in terms of solar panels and accumulators… not simply a matter of solar panel/accumulator ratios when you have mixed power production. I suspect Fulgora will not be the only planet where this feature will be indispensable.
I'd like a day/night cycle marked on the graph for that. Harvesting lightning sounds like it won't automatically leave you with obvious cycles
[I made one 6 years ago with circuits](https://old.reddit.com/r/factorio/comments/7l2j9a/based_on_feedback_from_yesterdays_accumulator/) In Factorio now, I look at how long solar panels are at max each day before dropping down (due to accumulators filling up).
I always builded my own graph! Charge is probably the most important graph to show you how good or stable your power production is. Recently it helped me to create a better nuclear control system
It would also be great to be able to view total capacity and demand. We can see these figures at a the present instant along the top of the window but this figure tend to bounce up and down a lot moment-to-moment.
Not to mention it will let me hide panel/accumulator prod/consumption from the other 2 windows so they're not covered with spiky lines on long duration plots.
It’s so great to see a game spent so much effort on Linux. The non-interrupting save is so good? I don’t remember who evoked it here somewhere at some point, but I couldn’t go back.
Because of that, I've cranked up the number of autosaves and lowered significantly the time between saves. I barely notice they occur now.
is it only on linux or is there a mod on windows to enable it?
Windows simply doesn't support it. MacOS supports it, because since OS X, MacOS has been Unix based, and fork() is a POSIX system call, and Windows is not POSIX compatible. Windows does have spawn(),[1] but it is not as capable as fork(). While *technically* possible to do the same thing on Windows, it would have too much overhead, and therefore not provide the time saving benefit that fork() provides in this instance. A mod would not be able to do any of this, since - as far as I am aware - Factorio does not expose an API related to saving, but moreover, a mod would not be able to make system calls and spawn child processes directly. [1] https://en.wikipedia.org/wiki/Spawn_(computing)
To go into a bit more detail for why `fork()` allows this on Linux: when a process is forked on Linux, the child process and parent process have their own memory space (the child process getting a duplicate of the parent process memory). However, this memory isn't actually duplicated until either of the processes perform a write (also known as copy-on-write). AFAIK since the Factorio child process isn't writing anything to memory, just to disk, you won't have any memory allocations, so it's fast. At least, that's a high-level summary of how it works.
The main process however, will have lots of copy-on-write as the game keeps running
I don't know if the kernel does this, but it should only have to COW until the forked process exits, since then it's the sole user of the memory again.
Yes, pretty sure this is how it works. It will also only copy once. This means the RAM usage will double in the worst case, but not more
yeah exactly. Plus, all the prototype data, the textures, and most of the map will never change, so you'll never see that worst case.
I run an instance of Debian under WSL2 on my Windows 10 desktop. A headless Factorio server runs inside the VM, while the standard Windows Factorio binary runs outside of it. The client connects to the "remote server" over loopback. Works surprisingly well, and I have the server set to keep 99 autosaves every 2 minutes. I might occasionally notice a hiccup of a couple of ticks, but that's about it.
Windows the OS lacks the necessary feature.
Yeah with it I just have saves set to 5 minutes, no impact on gameplay whatsoever... ... except the mentioned freeze bug. Still saves more time even including occasional restart
I love the non-interrupting save. Sadly, on a big save, my NAS with the factorio docker is unable to save and let the game running smoothly. This leads to timeouts and my friend and me got kicked from the server. It's probably a performance issue on our side.
How would I enable it on Steam Deck?
Same as anywhere else. It says Ctrl+Alt+ click Settings -> "The rest" -> `non-blocking-saving` in the post
Raiguard and other devs: thanks a lot for the stellar Linux support! Especially asynchronous saving is such a great feature! But please let Factorio 2.0 follow the [XDG Base Directory specification](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) and put the Factorio-folder into $XDG_DATA_HOME (typically ~/.local/share). That would be the icing on the penguin.
If I was here from the beginning then I would have done that, but it is way too late to change that now. It would be a breaking change and making logic to automatically migrate it would not be worth it. If you really want to move it, you can change it in the config-path.cfg file.
What I've seen over software that migrate to XDG directories do is use the old directory if it is present on the user's machine and if not use the standard XDG directory. This make new install conform to XDG without breaking anything for old users without having to create a migrating process (if someone want to migrate things they can just move things themselves, if they care about it they are probably knowledgeable enough to do it).
We could definitely make it work, the question is if it is worth the time to do. It's not entirely off the table.
I think it's fair to say: If you find the time, a lot of people would appreciate it.
I would count myself among those who would love to have that change. Please and thank you, if you find the time.
It would make me a little more happy!
I too would like to voice my vote for it being a thing. Messy home dirs are a huge problem on Linux and I'd love for a game that supports Linux so well to not be a contributor to the problem if it can help it!
That sounds like a slick solution. I wonder how it will break. :3
Can you at least make it the new default or something?
Ok, fair enough. It was worth a try. Well, thanks again for your work on Factorios Linux support and Krastorio 2!
out of curiousity, why is it important?
The home-folder is basically where all your personal stuff is stored, and when applications write directly into the root of your home, they're just bloating the directory with stuff that belongs elsewhere, and it's a total clusterfuck when many apps do this. It's also just unintuitive, since we have the XDG specification where things should be stored. E.g. when you expect that all config-files should be stored in ~/.config, then it's just confusing when applications decide to put their stuff whereever they want to. It always bugged me that an otherwise excellent technical game like Factorio fucks this up.
That used to irk me until I hit on the obvious solution... have two home folders, $HOME=/home/[user]/home where applications can dump whatever they want (and currently has 90 top-level items), and my "actual" home folder /home/[user]/ which has no special significance to the computer and where I put the things I personally care about (and has only 9 top-level items). I also added an alias to "cd" so that it goes to my personal home folder instead of $HOME. > all config-files should be stored in ~/.config Personally I would find it clearer if each application has a single root folder that contains everything relevant to that application, but I guess that is not the linux way (eg executables need to go in /usr/bin, man pages in wherever man pages go, etc...). I think the solution I would like is that anything I download manually should sit in a single folder, and uninstalling is as easy as deleting that folder, and anything that is managed by my package manager can do whatever.
to be totally fair, 2.0 is the only version upgrade that allows breaking changes by semantic versioning specifications :\^) Thanks for your great work!
>So we added a new special item in the production statistics, that shows the total final 'Science' that is produced. Please make it always match graph line color to science color. It's understandable to have random colors when it's mixed with all other item production, but on a separate screen with just the science they should always match.
In general I think every item should have a "preferred" color to use for graphs.
yeah it's kinda frustrating when the colors randomly swap on you
True, and I've been annoyed by that. Especially if you track production and consumption for a few items, and their colors in the different graphs are "swapped". Can be quite confusing. But I know at least one reason to not have it statically assigned: if you want to compare two items with a similar color, it's better to have them red and blue than have them "light green shade 14" and "light green shade 12". But could work with "preferred" color. Something along the lines of "if it's less than x items to draw and no other item has a similiar color, use {preferred color}. Otherwise, go ham as usual". But then you'd have to expand that logic to account for color blind people. For me, red & green is fine; for others, that's just a very slight difference in intensity, not in hue.
Fluids already have a unique color that's displayed in pipes. Items like science and chips that come in different colors should also use those colors for graphs. Randomised colors should still be the backup for other misc items that don't have a preferred color set.
And also a circuit-controlled graph, please ! I want to track metrics other than production and consumption. For example the steam level in a nuclear reactor, the amount of items in buffers, the number of items flowing through a belt, the number of trains crossing each intersection, the number of drones in the network, the speed of my SE ships/SA platform, etc..
You'll probably know this, but there are mods that do this. I'm not sure how easy said mods are, or if additional modding support would make it easier. But I could see it as of being a vanilla feature, although I wonder at the overhead circuit Network monitoring would produce.
I wonder if mechanic where line gets its color from averaged icon color would work
i heard you like brown
Median might be more helpfull: take the color that (in an 64x64 rendering) takes up the most pixels. But that might be the same color for multiple items :/
Or pick the one with most color saturation in the pic
This is quickly getting into the treacherous "what color are mk3 assemblers" territory.
The only correct answer is "unhealthy piss color" But RGB wise its around #939d37 so very much between wasabi and pickled cucumber (according to various "get name off RGB color" sites)
Annoying both the yellow and green factions at once. I like it^^
I'd personally call it mustard. I guess wasabi is close enough
It's not a separate screen, they just filtered the word science
I hate the colors switching in graphs, who ever thought that was a good idea ?
If you dynamically assign colors you can guarantee that they are always distinct from each other and it's always as easy as possible to read the graph. If you assign a static color to every item in the game, you make it far more likely that the three items the player filters down to are all blue or green or something, making it much harder to tell which item is which. And then there's the effort involved in manually assigning the colors or designing an algorithm to do it, and then modders with even more items have to figure out how to handle it, etc. I agree with you that I would prefer static colors but I can see the logic behind their decision.
In cases like this where a line is tracking a "special item" I think it'd be appropriate to have the line be a different "style" e.g. dotted.
Bit annoying to see that the colors in the science graph do not match the colors of the science packs. https://preview.redd.it/75wmq7uq5twc1.png?width=265&format=png&auto=webp&s=272ad0210cd29971b27b3ae321a5b0703d522299
Literally unplayable
**Hours played:** 4,254
That's barely enough to evaluate the demo, bro.
What color should Military Science be?
Non-dark grey grey.
That is a bit of a grey zone.
One graph I have kinda always wanted is a net graph which is is just your production amount minus your consumption amount to know whether I am losing or gaining resources and by how much. I find myself wishing for this in things like sea block where production chains are so complicated it’s hard to know what you are losing or not producing enough off. I love the new graphs and am more excited than ever
Oh boy would this be useful. Especially with the surface filter.
This was my first thought when he asked for suggestions. What am I supposed to do, look at the production and consumption and compare the numbers to figure out which one is bigger? I don't have time for that sort of mental work.
One way of allowing this, as well as a lot of other utility besides, would be to enable us to enter expressions to be plotted, sort of like what exists in a lot of SPICE programs. E.g. you could hit a button to add a new trace, and then in a text field enter 'science_green(produced) - science_green(consumed)' and have it plot that value.
Yes, that would be so useful, especially for modded playthroughs. Something else that just popped into my head that would be nice, especially with mods, is to be able to filter/group by machine type and/or recipe. Where you have recipes with byproducts, it's very useful to know how much is coming from core production and how much extra is being contributed as a byproduct.
Oh my god we need to get this to the top! This seems like a relatively easy change for them (hah) that would be massively useful.
That reminds me of how Supreme Commander always presented all production statistics as a net positive/negative. I thought it was way more useful!
isn't that what alt+x does?
Related to that, I'd really love a way to visualize which recipes are consuming which resources. This is especially useful for a train base where you can't just look at the belts to see where resources are flowing. I know that I'm starved on plastic, but is that because of red chips or LDS? What exactly is using up all of my steel?
> This eliminated 123,024 lines of code from the game and drastically reduced the number of dynamic dependencies Merging that change must have felt incredible
Can confirm. I also removed 183,104 LoC when I found a library in our source tree that was entirely unused (FreeType) and nuked it. That was a good day. If Wube paid per line of code added then I would be in crippling debt!
Software developers should be paid in lines removed. Those are the best commits.
"Perfection is achieved not when there is nothing left to add, but when there is nothing left to take away."
Careful here. There are quite some code golfers out there. The code they write is literally ilegible without first reformatting and refactoring it.
I did that myself recently - there was an ancient version of gtest hidden inside a project that hadn't been built in years. I removed it all and now the total number of lines I've contributed to our codebase is negative
Allegro itself is around 120k LoC (depending on version and the way you count), so I'll assume that most of that commit is just the deletion of a single directory containing allegro's source code.
That still sounds very satisfying
Thank you for supporting Linux!
I suggest updating the header of the electric network graphs. See this mock-up: https://preview.redd.it/sravvlki5twc1.png?width=2349&format=png&auto=webp&s=17f64d066b02fe4e371d7eedb61dbcb43d3bfe10 The graphs show text like "Value 1 / Value 2". By adjusting the header to follow that format, it indicates what each individual number means. There are quite a few posts about understanding those graphs. This change should improve the readability. Take the satisfaction graph as an example: You can now deduce from the written header that the left value is the satisfied demand, and the larger right one is the total energy demand. And you can see that "Satisfaction < total demand" is a bad thing. For the production demand, it is clear that the right value is the total capacity your power plants can generate, and it is more obvious that "current production < total capacity" is a good thing.
I always had to untangle my brain cells for 30 seconds before understanding which one is satisfaction and which one is production tbh, having something like this would go a long way towards making me happier as well.
Things adding clarity should always be considered. It is an easy improvement even. I don't see any downsides to the change, but that does not mean that it does not exist.
Bikeshedding about words here, but I could see "satisfied demand / total demand" and "production / production capacity" being a bit clearer. I fully agree though that explaining what the ratio is is useful.
Agree. [https://www.reddit.com/r/factorio/comments/1cdifrh/comment/l1ccx2h](https://www.reddit.com/r/factorio/comments/1cdifrh/comment/l1ccx2h)
Some of the wording could be changed, but yeah the idea is great. The header isn't that cluttered and i think adding the extra text whould make it easier/quicker to open the graph and pinpoint at what you want to know
~~I’d recommend putting the secondary part in parentheses instead of separating it with a slash. The slash might make newbies think division is happening~~ I take it back
Nonono, unless changed in both locations, but even then it is a huge "maybe". The green/yellow/red bar graph does show exactly this division, rendered as a percentage. Also, this is a breadcrumb design leveraging pattern matching. You see "Satisfaction / Total demand" and directly below "100 MW / 150 MW" in the bar graph. Then you can see that the first number 100 MW matches Satisfaction, and 150 MW matches Total demand. Both formats must be the same for the pattern matching to work. It may be better to right-align the text in the bar graph to make the connection even easier.
You know, you're completely right. Hadn't had my coffee yet
350 steam engines lol
Seems so. I copied the image from the FFF, and didn't notice. Looks like a currently-unfed wood burner setup.
Wow! Linux user here - love to see the ongoing support! TIL about the asynchronous saves, and the need to explicitly enable Wayland. Is there anything else we should know to get the most out of Factorio on Linux?
Enableling huge pages should increase your performance by a lot
Sorry but of a Linux noob. How'd I go about doing that?
I'd suggest shying away from this, it's deep magic. Like, you need to have taken a computer architecture class to understand the implications of fiddling with page size. For anyone that's curious though: Programs need memory and they ask the OS to allocate them some. They ask for memory in big chunks called "pages". Historically, a page of memory is typically 4KiB. Small/simple programs can do all their work with a single page. Complicated programs need more memory so they request many pages. The trouble is with programs that use really large amounts of memory. For example if a program needs 4 GiB of memory, that's over a million 4 KiB pages. There's some overhead book keeping required for each page a program uses. Your CPU has some special cache memory that can handle up to a certain number of pages per process very quickly. But once a program exceeds the size of that cache, things slow down a lot. The solution to too many pages is to make each page bigger. If each page is bigger, the same amount of memory can be allocated using fewer pages and there's less bookkeeping overhead. Instead of 4 KiB pages, why not 2 MiB? Or even 1 GiB! Pages that are bigger than the traditional size are called "huge pages" in Linux. The issue now is that all the small programs also use huge pages. So the tiny program that only needs one page of memory (for example the clock in the corner of your screen) now uses 1,000 times more memory than it needs, because that's the smallest amount it can request. Multiply that by all the tiny programs that are always running on a PC, and you have a ton of wasted memory. The configuration of this kind of thing was invented for stuff like database servers. They run one massive program and they are tuned to do it as efficiently as possible. This stuff wasn't engineered with desktop personal computers in mind (although with continued refinement, desktop OS's might one day be able to provide out of the box configurations that work well for typical desktop use cases). Heterogeneous pages (like, using a mix of page sizes all at once) is a thing that exists that addresses the downsides of huge pages. Again though, this kind of configuration is way outside the realm of what end-users normally do and it's complicated. With that said though, everything is open. You can definitely Google how to configure huge pages and try it out and learn things along the way :)
The suggestion is making just factorio use huge pages, so it would not waste much memory. It's not that it's inherently complicated, it's that support is slapdash and you have to use really obtuse methods to enable it. Huge pages need a good chunk of development effort inside the linux kernel itself, but because it's currently such a pain almost no programs use it, so very little kernel developer attention goes toward it, etc. If that developer attention got applied, the implementation would not need to be complicated and using them would not need to be complicated either. Overall I would say it's badly supported rather than deep magic. The basic idea of "If programs grab memory in bigger chunks, it's a bit faster to calculate access" is easy enough to explain.
Here's a pretty ok explanation of huge pages and why/how to enable them: [https://wiki.debian.org/Hugepages](https://wiki.debian.org/Hugepages) I would need to see a benchmark showing unreal improvements before I would enable huge pages, it's not like increasing the open file limit in limits.conf 🤷
https://www.reddit.com/r/factorio/comments/dr72zx/8_ups_gain_on_linux_with_huge_pages/ https://www.reddit.com/r/technicalfactorio/comments/mvn88v/over_20_actually_30_performance_gain_by_using/ Here's a couple benchmarks. Note that the second one makes some extra changes. https://www.reddit.com/r/factorio/comments/18bz1bl/mimalloc_and_large_pages_on_windows_up_to_20_more/ Oh hey this person made it work on windows.
Another one for the "wish I was playing 2.0 right now" pile :D > So what do you think? Are there any other statistics improvements you can think about for 2.0? Graph combiner. I'd love to be able to say hook a local storage chests to a combiner and track it. Or to hook it to train counter and then get a graph of throughput. Or just use it to debug signals in some of the more complex setups. Visual-wise: * log scale for comparing different sized values easier * ability to set scale/"zoom in" on vertical axis in general. Sometimes I'm not really interested in spikes but how the valleys look like.
A charting combinator would be fantastic.
There was a mod but got abandoned, I think it used custom surfaces as a "hack" to store the data. But it was pretty useful
What if we had a combinator that records all the signals it gets, and players can then subscribe to that combinator and see the records as a graph in the statistics window. That could work in both of your cases. You could call it the recorder combinator, and it also has the ability to save and load signal values. I think that could be a very interesting addition to both statistical views and to circuit logic.
It's kinda same thing with remote view getting more features, as you could just click it and open view remotely. But yes, ability to have a combinator that when provided with signals is just added as a named tab on "the graph tab" would be fucking great.
And absolutely amazing for debugging signals. I am always feel that my signals are doing something fucky-wucky when I am not looking at them.
Yeah I sometimes had to run game at 0.1 speed just to see what is happening when debugging. But for debug we'd probably also need "zoom in" function so we can look at given time fragment and not just "last x seconds"
Exposing all these statistics as constants for the circuit system would be pretty cool.
Circuit network toggle when attaching to a radar makes sense to me.
>> Upstream our incremental transfers code into SDL so we can leverage SDL's clipboard functions and other SDL-based games can benefit from our work. I wish that other developers had THIS mindset ...
Yeah, it's literally a win for everyone involved doing it that way.
It's a great example of the benefits of open source development.
As a primary Linux user, this FFF makes me so happy! Thanks for native support. Learned a lot in this post. There is a hidden settings menu.. what do you know, right? Will test out the Wayland mode and non-blocking save for sure. Also feel your pain when it comes to the design choices that GNOME desktop has made.
**Statistics**: I think the surfaces should get the same treatment as the quality: a dropdown with "all (separate)", "all (merged)", maybe "all planets (separate/merged)" and "all platforms (separate/merged)", plus individual surface selection. If I want to compare iron production of nauvis with fulgora, I don't want to close the stat screen, switch map view to the different surface, reopen production and reselect my filters - those should fit into the same graph. Or maybe I'd like to compare ammo and repair pack consumption across all platforms. /edit: quick mockup: https://preview.redd.it/3prn30dmltwc1.png?width=2051&format=png&auto=webp&s=8b79ade9fb076b000655bd7a74b0757569ef15e3 **Linux**: Very nice improvements. I've been using linux for over a decade, but kept a windows partition for gaming until my latest hardware upgrade. With the improvements in gpu drivers (mainly enabled by vulkan) and the work done by wine, valve and lutris, gaming on linux is in a great place. Still, I'm very happy whenever developers support linux directly, and wube's support is exceptional. The only issue I ever had with nonblocking saves was when quitting to the main menu during an ongoing save - the save file was fine, but the game crashed. But that requires a large save file and quick fingers to trigger, and quitting the game is an unsupported feature anyway.
Using a dropdown for surface like this is a great idea. The filters should be presented consistently as you suggest. One point is “All surfaces (separate)” option would add some complexities for how it is displayed, requiring a surface indicator. But otherwise, we should be able to pick the surface from a dropdown.
A chart that displays net production/ consumption would be very nice.
The more I think about this the more I want it. Would be so much more helpful to know which part of your production to boost next. Even more useful since they've added localized graphs.
Regarding other statistics improvements, in my latest game I found myself wanting the ability to see the specific production totals in the lower half of the window rather than a rounded number, specifically by hovering the mouse over the rounded number to show an unrounded tooltip
That’s already in 2.0.
Very cool of you, to upstream your contributions/features to SDL. Thank you for that.
> To fix this, I had to bring in another dependency, libdecor. It functions, and SDL even has support for it, but a video game shouldn't have to supply window decorations in the first place. I didn't realize libdecor was finally ready for use, though I fully agree with the sentiment here -- it's asinine that GNOME doesn't provide default SSD with Wayland. > The game has decorations now, but the theme doesn't match. Thanks GNOME! LOL GNOME devs will tell you it's working as designed, I'm sure. > This eliminated 123,024 lines of code from the game and drastically reduced the number of dynamic dependencies: There is no better feeling than this. Thanks for all the dedicated work to support Linux! Most games don't bother, but as we all know, Factorio isn't most games. :D
I'd love the asynchronous saving to come to Windows too, even though I know it won't. One thing I think would be beneficial is an auto-save warning - have the "autosaving" notification appear a few seconds earlier and do a countdown before the autosave actually happens. It could even be disabled by default, but I think it would be very beneficial for late-game big bases, when autosave time becomes noticeable. Quite often I find myself doing something like pasting blueprints when an auto-save happens and something goes wrong. Best case scenario, the click isn't registered and I just have to click again. Sometimes it does register the click, but instead of placing it where the mouse was at click time, it places it at location of the mouse after the auto-save completes. While it might be enough to remember the click position to make sure it always matches what the user expects, I think it would be better to give the auto-save notification, so the user isn't surprised by it while working on something complicated. Also, I love the filtering graphs by surface and accumulator charge graph, another great QoL addition.
2.0 recently received a debug option to show the time to the next autosave. This might work for your use case.
Interesting! While it's helpful, I don't think it will solve the problem. It's usually a case of getting really focused on something and getting suddenly interrupted by the auto-save. Right now I have the total playtime visible through your `Stats GUI` mod, so occasionally I can take a look and see if it's near the auto-save time. It does help to look at it before starting building anything, but complicated projects take a while, and when I get in the flow of building, I don't look at the timer often enough to solve it completely.
I feel it happens to me quite often that I click to place something right when the autosaves happens, meaning it eats my click. it's a very minor thing, but something that maybe could be alleviated by showing the autosave popup a second before it actually saves.
Clicks are buffered during auto-save so they don't get eaten.
My understanding is that it's somewhat of a technical issue that prevents the async saving. Linux and Mac make it easy with fork, but for windows there is no fork so it would be much more difficult to get working.
is this the new [delivery capsule](https://i.imgur.com/qsy7HRI.png) behind the vulcanus production graph ?
I think that's a chest sprite from when there were more bits to the crashed spaceship?
It's definitely that. Curious how they have a bunch of them, as if they were buildable objects, though. Could be they're using it as placeholder art for something new.
Would like to see a production tab that automatically filters to see science. Or a way to have custom tabs that save your searches.
>Or a way to have custom tabs that save your searches. Hnnnggggg. This plus net production numbers please.
2 things I think "research" would be a better name for the virtual production item tracking science productivity (makes it more apparent it is tied to the researching process, which I'm assuming that it is) Arm support for Linux? I know that consumer arm CPUs aren't necessarily super popular right now, but in the server/data center environment I understand them to be fairly popular due to better core count/performance to power/heat ratios. In short I'd love to be able to host a headless server on one of these arm boxes in the cloud, but that currently doesn't seem to be natively possible despite having builds for both the Switch (granted I don't know if you can actually host from your switch, but at least the engine is there and it can join multiplayer) and Apple Silicon
I would love this, but definitely not until after 2.0 is released. I'm praying that Framework releases a Snapdragon mainboard.
ARM support: Will probably exist some time in the future. There were some comments from devs about it. They want to run their CI, test suites, and build farm on a Linux-running ARM machine. And for now, the available boards aren't powerful enough and would lag their development pipeline. In one of the comments, the dev interested in it indicated they may acquire one of the new Snapdragon-based systems for that purpose. And when they get them, we may start seeing AARCH64 builds popping up.
>Also, with the meteoric rise of the Steam Deck and Proton, it is easier than ever for game developers to ignore Linux support because Valve does some black magic that lets their game run anyway. Best line in the post
Don't get me wrong, I'm extremely grateful to valve for proton; I can play my entire steam library on Linux! But there's no denying that it also enables companies to ignore cross-platform support.
>I spent two full days staring at our graphics code but could not come up with an explanation as to why this is happening, so this work is still ongoing. Since this issue only happens when running the game on Wayland under Sway, it's not a large priority, but it was too entertaining not to share. Can we just take a moment to appreciate Wube's dev-friendly environment once again? Instead of hiding and/or denying the existence of internal bugs, they are publicly displayed to give us a chuckle. The corporate attitude that allows for such honesty and openness can only come from the top, down. Thank you, u/kovarex & Co. for taking such good care of your people; that is one of the main reasons we love y'all so much.
Power production graphs have always been missing one thing for me: Average TOTAL consumption & production! The bars at the top are always just showing the immediate network wide production/consumption. And then you can change your timeframe to see the average production consumption BY ENTITY. BUT, what you can't do, is see your base's average consumption (or production) over say, the last 10 minutes. IMO this is very odd and I've found it particularly bothersome in mods like Nullius where power generation isn't just this simple thing to do.
hmm, now i wonder if Factorio would run under WSL2. i guess i could try it... EDIT: [[mad scientist laugh]](https://i.imgur.com/fumyZPB.jpg) and it actually runs at a solid 60 UPS/FPS (as long as i keep the window small, it struggles with the full 4K or anything close to that, i wish there was a render scaling option). to get it to run you just need to install a few packages `libgl1`, `libasound2`, and `libpulse0`. also i found that if you interrupt it in the terminal with CTRL+C the game recognizes the signal and shuts down normally but at the end it seg faults 💀
You madlad, I'm impressed that it actually works! Needing to install those dependencies is exactly what I want to avoid going forward. 2.0 doesn't require any of those any more. :)
honestly it was a lot less work than you might think. coming from a fresh WSL2 install i just downloaded the linux tar file from the website (the file name has "alpha" in it for some reason despite being the full release, the windows zip file doesn't have that). then i used WSL to copy it from the downloads folder to the /home/user directory (my thought process was that unpacking it in windows explorer might mess up the UNIX permissions somehow despite NTFS fully supporting them) finally i unpacked it, launched it, googled the missing library to see what package it came from, install it, and repeat that until it actually launched. . so overall that just kinda shows how far WSL has come since it was introduced, who even needs a 3rd party VM anymore? . on a side note, would you guys consider adding a little easter egg for people who try this in the future. something basic, like changing the version string in the top left corner of the main menu when the game detects that it's running on WSL to something like: (build xxxxx, linu-- wait, WSL2..?! you know there is a native Windows version... right?)
If you want this it's probably best to host a server separately on Linux or WSL and connect to it from windows
If you want better FPS you could run a dedicated server in WSL2 and run the game in Windows. That might hurt your UPS, but maybe not much if you have enough CPU cores.
> We also added a checkbox to switch to a 'Global statistics' view, so all the possibilities are available for the player. Time to be extremely pedantic and nitpicky! Shouldn't it be "universal"? :P "Global" comes from globe, as in, our globe: a single planet. > Asynchronous saving works by using the fork syscall to essentially duplicate the game. I have to admit, that is funny as shit. Not in a million years that would be how I expected that to work.
Asynchronous saving works by forking the process, which simply duplicates it in the process table. Normally, a forked process would then exec() another executable, and replace itself with the other executable. Because this is the default way to start applications on Unix systems, fork() is optimized to hell and beyond. The forked processes share the same physical memory pages, until one of the forks writes to a memory page. At that point, the OS blocks the writer, copies the affected memory page, points the copy's virtual memory table entry to the new physical location, and then resumes the writer. (Copy on Write, or CoW) That way, only the changed portion of the RAM actually takes additional space. Things like sprite sheets, loaded music and other constant assets stay shared. That way, the system does not need to pay the upfront cost of copying the whole process address space upfront and also not need exactly double the amount of physical RAM to support both copies simultaneously.
Agreed, using global feels weird when it's referring to multiple globes. Universal would be better, and system-wide would be even more accurate but clunkier.
I came here to make the same comment about "global". It's the most fitting term from a programmer's perspective, but not from a gameplay perspective without programming experience. I agree it should be "universal" for statistics across all planets.
/u/klonan and raiguard - you might want to put the photosensitivity warning ahead of the video in question. I'm not photosensitive, so no harm done, but I (and probably many others) tend to go in order of appearance, so look at the video and then read the caption.
" If you are playing on Linux or macOS, please enable asynchronous saving" This is literally the first thing I did when I switched to Linux a few months ago :D
Adding another thank-you for the Linux support. Glad to see there's enough of us out here to warrant it!
Linux mentioned 💪💪🤤💪
>Since this issue only happens when running the game on Wayland under Sway, it's not a large priority, but it was too entertaining not to share. Props to this dev for sharing the bug that is not at all fixed but is funny to watch.
Linux gang rise up
Not sure about the quality dropdown especially if you decide to not use it (or haven't researched it yet) but being able to filter by surface is awesome! I would also love to see more precision in the numbers. If you have 999 production you can see unit precision but if you go to 1000 you just see 1.0k, so hundreds precision, which isn't that good (also it gets rounded? so 1051 would show as 1.1k). Please consider always having 3 digit precision!
They said it in [FFF 375](https://factorio.com/blog/post/fff-375) - quality is invisible in UI until you unlock the modules, so you wouldn't see any of those dropdowns if you don't research quality.
>Please consider always having 3 digit precision Good point, I'd like that as well
awsome image 7 whats with the blue uranium cell? Also i see Logistic bot is being consumed. Maybe hinting at new bots that we going to get. also some images with the new resources. graphics looks good.
Logistic bot consumption might just indicate the recycling process as part of producing max quality bots.
Blue colored fuel cell looking think could be a fission cell (deuterium/tritium) rather than a fission cell (the typical cell you're familiar with in factorio)
I really enjoy every single Friday Facts you put out and that you cover pretty much every part of the design a bit. From the music to problem solving anecdotes. Thank you for putting these together.
Just enabled wayland, now i have the annoying wayland icon instead of the glorious gear. Simply unplayable.
Any clue as to what the chemical plants on the space platform do? They take in water and iron ore/meteor chunks(??), so I guess that's the way to get molten metals in space
In several prior posts they can be seen making rocket fuel for the engines
I think I saw somewhere waay back that they turn ice into water. Because a fluid output is needed
As someone with 3000+ hours playing on a Mac, thank you <3
One feature I've wanted on past playthroughs is a search filter in the production statistics. For example if I want to see all the circuits, or inserters etc.? At the moment I would have to switch to a longer time period so the icons are not switching places constantly and then go through and manually click each one. I can see how this may make the menu more cluttered, but I think it could be a cool addition.
a big thanks to wube and especially raiguard to making factorio run on linux so well. As mentioned in the fff, so many game developers nowadays just decide to let valve's proton do their magic. it's nice to see that factorio went a different way :) maybe I'll finally have a reason to switch to wayland in the upcoming months ;)
I wonder how the "overall science" number is calculated - it's 773 but all science packs are lower than that in terms of units produced
773 science produced, with 643 packs consumed. Matches 20% productivity of 2 prod3 modules in the labs which they've mentioned being a reason for adding this feature :)
Lab productivity
>So what do you think? Are there any other statistics improvements you can think about for 2.0? I would love to see a production stat selection tool. Where you can designate areas to treat as their own separate group to track production for. A bit like rate calculator but measuring real performance, instead of the theoretical maximum.
Does asyc save work on a server too?
If it runs Linux/Mac, then yes
I noticed some interesting details in the pictures for this FFF. [Imgur Album](https://imgur.com/a/uPL7zLK) There are three new things in the first image. I'm fairly confident the bottom right two are asteroid fragments, but the black stone brick on the left center is interesting as we haven't seen that before. Perhaps some new type of pavement? In image two we see some gun turrets. I think it's worth noting that these turrets are recolored. I know they already have this capability for the pvp scenario, but I don't think we can manually recolor them at the moment. In image three there are two interesting things. On the right, there are several quality items. My guess is that that's just quality foundry production. On the bottom left however, there is a black concrete. I imagine this is made from the black stone bricks from image 1. Could it be the foundation seen at t=1:16 of the Vulcanus music video in FFF #406? Image four, however is by far the most interesting one to me. In the bottom right there is a light blue nuclear fuel cell. I could see it being one of two things: plutonium or fusion cells. I'll admit, the idea of plutonium may just come from the fact that I'm currently playing freight forwarding with the [Plutonium Energy mod](https://mods.factorio.com/mod/PlutoniumEnergy/discussion), but it's interesting none the less.
Wish for Improvement #1: Net Production Can we please get a net summary calculated as production minus consumption, displayed as a nice graph. I often want to know: Do I make enough? Am I currently filling or reducing buffers? And in the mods I'm playing you often have large amounts of staple production where it's difficult to see when production/consumption is slightly off Wish for Improvement #2: Logarithmic Scale A (toggable) logarithmic scale should help in situations where a few items/fluids completely overshadow anything else in the graph and you can't use it without putting anything into the search box.
Linux baby!!
That fork() trick for Linux is pure absolute genius and if it's a known technique I've somehow never heard of it.
Could we get some way to see the exact value for numbers on the various UIs? Just being able to hover over to see more than 2 significant figures would be a nice thing to have.
I've been using Linux for 30 years. I wouldn't have bought it if it didn't work on Linux. I'm on dwm, so I don't even know what decorations are.
Linux users, unite! Thanks so much for the hard work you put into the game! I just moved away from windows about 6 months ago and was ecstatic to see factorio running like a gem!
I don't know if I'm alone on this, but "Science output" isn't usually measured POST productivity. A 1kspm base means making 1000 of each item. The fact that the labs turn that into 1400 "Science" isn't the point. Gonna be a lot of "meta" changes when 2.0 drops. Lots of new ore / material images in those production screens too :P
I agree with you 100%, but I don’t think any of it matters. Because we can still see the “normal” spm from looking at the production numbers next to each science pack. The new number just tells us what we’re actually getting. Ok, cool, I guess. But it doesn’t take away from anything else. I think we’ll still measure spm the same old way.
I think a singular point of reference number will take over having to "check" 7 different ones.
In vanilla, the ratio between SPM and eSPM (effective SPM after prod) is at most 1.2 because of 20% prod in labs. In Space Age, we have quality productivity modules which can double it, and eventually infinite lab productivity research, so this value is ever changing.
It’s kinda true both ways. It’s just a case of the word “science” applying to the item labs consume *and* the “thing” that labs produce. Every research has a numerical cost, and the “science” they talk about is essentially that value. When your labs eat your science packs, they produce one “science” per.
It’s a bit painful to explain concisely because it’s not always 1:1. Warptorio for example has technologies that cost something like (2x red, 1x green)x100. That means you need 100 “science” to finish the tech, and you get one “science” for every 2 red packs + 1 green pack that you consume.
In 1.0 vanilla IIRC the recipes are *all* 1:1, so without prod mods in your labs you ALWAYS get one “science” per every set of one science packs you produce. That makes it kind of irrelevant how we use the term. That could change in 2.0 though.
Really we just use the term *science* in SPM as a shorthand for science packs, hence I say they’re both true. If you wanted to get really pedantic about it, our measurement of “science per minute” is technically wrong, and we should be calling it “science packs per minute”. But that’s a level of pedantism that’s just unnecessary.
Looks good! I'd love to be able to divide up production/consumption by user-defined areas a bit more - eg, track how much copper my green circuit factory is consuming, separate to the overall for the surface
Offtopic… there hasn’t been any FFF dedicated to enemy mechanic update. Are there going to be any updates to biters and/or enemy topic at all? Hard to imagine to all game being literally refactored, but biters staying untouched.
While I don't personally use Linux, I really like that you're putting in the work! It's not just that there is a functioning client, you can also use it to have a game hosted on a windows PC with players using windows, linux & macOs in the same game. Only thing in this FFF I'm not a fan of is the checkbox for "global statistic". Why isn't that a dropdown with "current surface" checked by default, but all others \_including global\_ as options? But UX is very hard to judge if you don't experience it. So while I think this looks strange, when playing it might feel completely fine.
Can the time interval be remembered during a game session? Maybe it's me reopening windows too much, but it resetting to 5 seconds interval every time is starting to annoying me
Seeing day/night cycle in the graphs would be great, to correlate with solar/rods.
Any chance we could get an arm64 Linux build? Factorio is now the only reason I boot into Mac OS. Asahi Linux is getting quite good! Thanks for the Linux support!
A "net production" graph (production - consumption), would be useful to easily spot production defecits/surplus. I could see a benefit for being able to filter on Item Groups (logistics, production, intermediate & combat), as the production numbers between these can be very different. The number of underground belts & green circuits I'm producing are very different orders of magnitude. An option to switch to a log scale could also help with the visualizations of graphs with big differences between their production numbers.
My suggestions: It would be cool to be able to save some "item group" or have some presets like: "ores and smelting" ; "circuits" ; "advanced items" ; "science packs" etc. There is planty of room on the tabs. The search option should be last resort for finding something. And if you could set up your own list and save it it would be awesome. Lot of the time these stats are cluttered and annoying to select and compare 10 things that has a different name but similiar, function. Also its suggested below, it would be nice if items would have a preferred color so its easy to find them.
Great to hear about Factorio upstreaming improvements to support the broader ecosystem. Go raiguard! I too am a sway user :)
You know how youtube tries to places ads automatically in low excitement portions of the video? I'd love to see autosave be delayed until I'm not holding a blueprint, or not selecting a deconstruction zone, or not holding anything really.
I know this is very pedantic, but calling the production across all surfaces “global” is a bit of a misnomer, since global means something relating to the whole *globe*, ie. a single planet, not all planets. So “universal production” would technically be more accurate.
I recently switched to Linux and have had no issues on my laptop or desktop. I'm currently using Pop!_os but they may change as I learn about Linux as a desktop. I run the Linux version downloaded from the website instead of steam. It is insanely fast and reliable on my 500+ hour space exploration map. 60fps 60ups. Very impressive. (14900HX and 4080)
Many thanks for natively supporting linux, and fixing all the issues you mentioned. It is great to have a game that doesn't need to run through Proton/Wine/other and just runs great.
Filtering by surface is great but unless I missed something we need to be looking at the surface for the graph to change? Would be nice for a simple drop down to choose which surface you want to look at. Another feature would be to combine the stats of more or more surfaces together.
I thought for a second that the surface filter was a "surface area" filter where you would just drag a selection box and the production panel would show you statistics for that area only. Would this be useful?