Friday Facts #408 - Statistics improvements, Linux adventures

[Kenco]

Stats request: I want to know which recipe is consuming a particular ingredient.

E.g. I notice my economy has run out of green circuits, but I can't tell why. I go to the stats window, consumption tab, then click on the green circuits row, and maybe perform some UI action to drill down. Then I see a sub graph showing the green circuit consumption breakdown per recipe. I quickly find out it was... My new blue circuit factory, probably.

This would be particularly helpful with mods that have a lot more recipes.

[jodokus31]

I would wish, the stats would remember the all last settings.

[TheRaph]

Could you please try to get a solution to swuches off network parts in history graph?

Why? Because of Vulcan... And generally.
An example:

I have some coal driven generators staying around for backup just in case the accumulators haven't enough capacity.

Because I can not set priority of generators I've some circuitry to check battery level. If it's below some certain point a switch will be closed and the coal driven generators start working.

Just in that moment I can check in power stats and see the producing coal generators.

Next morning, half filled battery and working solar panels I can not see the helping hand of coal power in my charts, because the coal generators are not more part of the current electrical network due to disconnecting the switch.

So I'm not able to see an ongoing problem if I'm not looking during night time.
This would come up even more while managing multiple planets.

Got it?

[mikehendi]

Great job on the progress, I'm reading every week with great joy


2 hour, 5 hour and 20 hour graphs would be nice, the current step from 1h to 10h is just too large.

Or better yet, add a "custom" button instead, where you can manually input the timescale for the X-axis



I also agree with previous posts about remembering the last timescale selected when opening power/production screens (global value, not seperate imo)

[m44v]

Thanks raiguard for all your work on the linux version of factorio!

Are there any other statistics improvements you can think about for 2.0?

I have some:

• Reduce the item jitter, it's difficult to select/deselect stuff with the mouse, in particular science packs.
• A graph combinator, for visualizing custom signals. There's a mod (time series) but doesn't work very well.
• I'll echo the sentiment that the stats window should remember the last used time scale.

[FasterJump]

Could we please have the precision remain at 3 digits when production is over 1k, as mentikned in a reddit comment?

Currently, 851 reads as 851, but 1051 reads as 1.1k.

I suggest to make 1051 read as 1.05k.

13579 can read as 13.6k, ans 123579 can read as 124k.

Or even better, allow us to set how many decimals we want to see at all times, so observing a 1kSPM. production graph doesn't flicker between 998 and 1.0k.

[Lizzy]

This is all really nice work and I'm increasingly frustrated with being stuck with 1.1 hahahaha
(Still playing it though )

Windows also has mechanisms of shared memory combined with copy-on-write, however it's very Windows specific and definitely not as easy to use as a simple fork() with a little bit of process synchronization. So I guess it's not feasible to get this background saving to Windows as well. However, it would be a really great QoL feature if implemented nonetheless.

I use WSL a lot on my day job, and while I knew about the Windows lack of a good fork(), after reading today's FFF this morning I started wondering how WSL does accomplish what clearly is the correct semantics for it. I ended up finding this article that does a short but informative dive into the subject. So my conclusion is "cool, all we need to do is write a kernel-level driver, that's not gonna be a nightmare at all!"

[Kadet123]

On the production graphs, it would be nice if there was an easy way to see the aggregate of production+consumption, so you can quickly tell if something is trending downward (negative numbers) or upward (positive numbers). For example in the platform picture, the bullets being in different positions on each graph may hide the fact that bullet production isn't keeping up with bullet consumption, unless you mentally cross-reference each item in the graph yourself.

[yogsosoth]

I would really appreciate a Sum button that will simply make sum of all values present in the graph. This would be helpful for energy consomption for example.

[Neutronium]

I would really like if there was some way to quickly switch through the various surfaces when in the production menu, the name of the surface/platform on the top left can be replaced by a dropdown in the same location. There can be a target sort of symbol next to it that immediately switches it back to the surface you're currently viewing.

[jamaicancastle]

I feel like, if science is important enough to be its own (meta) item in the production graph, then there should just be a button to show it without having to type.

I like the idea of more pride of place for "science progress made". In a sandboxy kind of game like Factorio it's easy to get lost and not know what you're supposed to be doing when you're new, and a prominent "this is how much science you've produced" display helps emphasize that you should be making science! (Which, even if it's not actually a new player's goal, at least gives them new toys to play with.)

I go to the stats window, consumption tab, then click on the green circuits row, and maybe perform some UI action to drill down. Then I see a sub graph showing the green circuit consumption breakdown per recipe. I quickly find out it was... My new blue circuit factory, probably.

I think the natural place for it would be in the tooltip that currently just shows "green circuits: 540/m" or whatever. It could be rearranged to show:
"Green circuits: 540/m
- for blue circuits: 240/m
- for red circuits: 120/m
- for solar panels: 60/m
[and so on]"

You could do the same for production in Space Age since there are more products with multiple sources, e.g., how many of my green circuits are new-builds vs. recycling? How many of my gears are assembled and how many smelted? How much of my heavy oil comes from oil processing vs. coal liquefaction? Stuff like that.

Back and forth links with the factoripedia would also be very useful. If I'm manufacturing dozens of items in large quantities for building space platforms, it'd be nice to start with production statistics, see that (for instance) green belts are low, click through to factoripedia see what the recipe is, click through to production statistics with those items highlighted so I can see where the bottleneck might be. Of course, you can do that by hand if you've memorized all the recipes, but that kind of defeats the point of having an in-game reference!

[purdueme91]

What I would like to see is that when I filter results in the statistics, I like to look at the numerical numbers below the graphs. When I come back into the screen, the graph is still filtered but the numerical numbers below are not. Be nice to have a pull down with recent views. Also might be nice to have saved views so I can check on critical components that I work on fairly constantly.

[mrmelon54]

I sent an email in a while ago asking about RGB and Discord rich presence support for Linux. Would be great to see some improvements in those areas.

[koliw_br]

I love such technical descriptions and am a fan and daily Linux user myself. I have been using non-blocking asynchronous game saves for a long time. On a server in particular, this is useful. The only problem is that the syscall fork uses a lot of ram and in case OOM Killer kills the game saving process the main thread does not know about it / is not notified and after three failed saves the game disconnects all players being three saves behind.

On the subject of statistics: An option to export to CSV would be useful for a large number of players. This could be implemented via a GUI button or a CLI argument

[herrkocur]

Thank you raiguard and Wube for all that non-flashy (not you, Sway) work that really brings joy to users. Much appreciated.

Also, FWIW I second that the rarity tier names as seen in screenshots could be revised.

[CommunistCatgirl]

Hello Factorio team. I would first like to say, thank you for this phenomenal game and for continuing to support it and improve it after all these years. I'm also really happy to see you supporting all the major platforms well, including Linux. I really appreciate the amount of detail and attention you give this game. I would like to comment on a couple things about this blog post.

I really like the idea of asynchronous saving, even though my computer is fast enough that saves don't take that much time I will enable it to see if I can find any issues to report back. You mention that it requires a significant amount of RAM to work which makes sense, but I wonder if there's a way to optimise it. As far as I know, the linux kernel will actually use a CoW policy to a process' memory tables after a fork. Basically both processes' virtual memory pages will point to the same physical memory and contents of a page will only be copied to a new private one when a process actually writes to it. If you could maybe minimize or hold off some writes from the playing process until the save is done, it could need way less RAM, but all this depends on the data structures the game uses internally to store world state and the rate at which they will need to be updated. I would also suggest you take a look at the newer clone() and clone3() syscalls, they might give you some more control over how the memory is shared though I haven't dug that deep myself.

As for server-side decorations the situation is a bit more complicated than this post and a lot of people make it out to be and I'm a bit disappointed to see GNOME dragged through the mud for something that isn't really their's or anyone particular party's fault directly. Wayland was designed with modularity and extensibility in mind and not only desktop use. This kind of modularity means that only the core wayland spec is mandatory to implement by anyone while everything else is essentially optional and depends on what kind of usecase the compositor is targeting. Unfortunately this does lead to some feature fragmentation (one of the side effects of trying to make one thing that is generic that works for everything) but it does mean that if factorio or any application wants to run on any compositor they would have to work within the core spec + xdg_shell as much as possible. In other words, if it wasn't GNOME today it would be another compositor tomorrow that didn't support CSD for a variety of reasons that would then require the use of libdecor anyway. In fact the reference wayland compositor Weston (though not really meant for desktop use directly) and Valve's Gamescope do not support the protocol. The xdg-decoration spec even states "If compositor and client do not negotiate the use of a server-side decoration using this protocol, clients continue to self-decorate as they see fit."

And there are benefits to CSD as well. For example, visual consistency of different applications is basically impossible unless they are using the same toolkit and were made with the same design language. With SSD the only thing that is achieved is the window decoration looking out of place compared to the window itself. In fact I really like how the black decoration looks in the screenshot of the user from the CSD bug report, it matches the black vignette of the factorio main screen way better than a bright white decoration from a user using light theme on their desktop ever could. CSD has also generally been the standard on other platforms. From electron apps on MacOS embedding macos-like window action buttons inside the app itself to web browser themselves to Steam, it is very commonly used all over the place.

I just wish less energy was spent complaining about having to draw a flat-color rectangle with 3 buttons on it using a ready-to-use library.

[Sneak555]

All of these updates are pretty cool; and I understand their intended for "factorio 2" (or rather, a DLC it seems)

the base game is more then sufficiently developed in my book to warrant you guys moving on....but do you guys have *any* kind of ETA on when all of this will be available to play?

I wanna become addicted to gambling on the rarity slot-machine game already!

[spikespaz]

About Wayland+Linux, I have another bug to report. This is reproduced on Hyprland and GNOME (wl).

When game is launched with `SDL_VIDEODRIVER=true`, copying a blueprint string is impossible. Neither the "Copy" button, nor highlighting all base64 and then ^C.

I know one person able to reproduce (GNOME).

After typing the above:
I tried just now and could not reproduce, has it been fixed or is it an intermittent issue?

[ESI85]

I don’t know if it is possible. But I’m sure you guys will find a way.
The graphs should tell me if production is going down because the output is full or because it’s lacking materials

[Apeiron]

Every FFF that comes out is making me have to (im)patiently await the 2.0 release even more.

Bit of a rant below, though, not.. directly related to the game.

The issues with GNOME and client-side decorations are a great example of what my biggest issue with Wayland is.

Many great ideas are going to get ignored because GNOME/KDE/whoever else decides to simply go "nah we don't feel like implementing that, so nak" to the proposals. Have the same problem with web standards.. anything Google doesn't want to add to Chrom(e|ium) goes nowhere, or is actively sabotaged by Google because it's a direct competitor to one of their own proposals (*cough* JPEG-XL vs AVIF *cough*). Few, if any, applications are going to put in the work to support a feature that only XFCE's (as an example - they don't have a custom Wayland) compositor supports. Or they'll have to put in extra, otherwise unneeded work to support an added feature because GNOME refuses to be standard. It's a complete mess.

Have a look at the discussions going on in proposals for the most simple, basic features. Pages and pages long, 4 major draft reworks, over several months to multiple years, and no closer to getting anything done. Such as the very real controversy and bickering going on behind the simple idea of letting an application supply different window icons to child windows directly, rather than defaulting (or only being able) to use the main application's icon. An example being if Discord wanted to pop out their settings into a child window. If the devs wanted to make that window's icon a cog wheel instead of the Discord logo.. they can't under Wayland. Some DE devs are demanding they implement it via each window having its own .desktop file somewhere pointing to the icon on disk. Others want the more reasonable approach of attaching an icon in-memory. Others think the feature is stupid/useless and don't want it to even exist. It's maddening.

Thank you for coming to my Ted Talk.