fff-408

StatisticsKlonan

Do you love watching your production graphs grow as much as we do?

蓄電池 graph

It is a little bit tricky when you transition from 蒸気発電 to Solar panels and 蓄電池, to know if you have enough capacity in the system to survive the cold dark nights. Generally you might just wait until nighttime and see if your factory blacksout, if so, build more solar and accumulators.

It would be helpful and convenient to see the statistics of accumulator charge levels, so we added such information:

[

](https://cdn.factorio.com/assets/blog-sync/fff-408-accumulator-graph.png)

The main reason it was more critical, was that on フルゴラ the production from lightning at nighttime is much less predictable, so it is much more important to see the timeline of the accumulator charge.

[

](https://cdn.factorio.com/assets/blog-sync/fff-408-fulgora-graph.png)

サイエンス graph

You can track science pack consumption in the production GUI, but that does not account for things like productivity modules and the new research productivity technologies.

So we added a new special item in the production statistics, that shows the total final 'サイエンス' that is produced.

[

](https://cdn.factorio.com/assets/blog-sync/fff-408-science-graph.png)

Per surface production

It was tolerable in the first days of playtesting with planets and platforms that all the production statistics were global. However when you want to get more and more precise with your gameplay and trying optimize each part, it becomes quite necessary.

For instance on platforms, we need to know if we are producing enough fuel and ammo to keep the ride going:

[

](https://cdn.factorio.com/assets/blog-sync/fff-408-platform-graph.png)

And its super helpful when checking if a specific planet producing enough when some items are crafted in many places.

[

](https://cdn.factorio.com/assets/blog-sync/fff-408-vulcanus-graph.png)

We also added a checkbox to switch to a 'Global statistics' view, so all the possibilities are available for the player.

[

](https://cdn.factorio.com/assets/blog-sync/fff-408-global-graph.png)

品質 graph

Going deeper still, we want to dissect our production by what quality the produced items are.

[

](https://cdn.factorio.com/assets/blog-sync/fff-408-quality-graph.png)

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

Linux adventuresraiguard

I have appeared in a few FFFs by now but I have never formally introduced myself. My name is raiguard. I have been playing Factorio since June 2017, making mods for the game since the 0.17 release in March 2019, and I finally joined Wube in March 2023. My primary roles at the company are expansion programming and Linux support, as well as being an advocate for the modding community. I have been daily-driving Linux for multiple years and have fallen ever deeper into the black hole of customization and minimalism.

"Why don't most games support macOS and Linux?" is a sentiment I often see echoed across the internet. Supporting a new platform is a lot more than just changing some flags and hitting compile. Windows, macOS, Linux, and the Nintendo Switch all use different compilers, different implementations of the C++ standard library, and have different implementation quirks, bugs, and features. You need to set up CI for the new platform, expand your build system to support the new compiler(s) and architecture(s), and have at least one person on the team that cares enough about the platform to actively maintain it. If you are a video game, you will likely need to add support for another graphics backend (Vulkan or OpenGL) as well, since DirectX is Windows-exclusive.

Many developers will take one look at the Windows market share and decide that it is not worth the trouble to support other platforms. Also, with the meteoric rise of the 蒸気 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.

Factorio supports macOS and Linux so well because there has always been someone at Wube who actively uses these platforms and is willing to take on the burden of supporting it. Our native Apple Silicon support is a great example of this. Today, I will take you through some of the adventures I've had with maintaining Factorio's Linux support.

Wayland

My first self-appointed task after joining the team was to add Wayland support to the game. Wayland is a new display protocol that has been in development to replace the antiquated and insecure X11 system. Modern Linux distributions are beginning to switch to Wayland as default, so supporting it in Factorio is paramount.

We utilize the SDL library which neatly handles most low-level system interactions and abstracts them into a common interface. SDL has support for Wayland, so all that I theoretically needed to do was build SDL with Wayland enabled and it would "just work." However, it's not quite a simple plug-and-play. Wayland provides "protocols" in the form of XML files that you then use the wayland-scanner binary to convert into C program and header files.

Being relatively new to C++ at the time, my initial solution was convoluted and involved checking the generated Wayland protocols into our source tree, to be manually regenerated every time we updated SDL. A few months ago, armed with a years' worth of experience, I improved this workflow to automatically generate the files as a part of the build process, so they are always up-to-date with the protocol XML files that SDL ships with.

Factorio has supported Wayland since 1.1.77, but it needs to be explicitly enabled by setting SDL_VIDEODRIVER=wayland in your environment. For Factorio 2.0 I added a dropdown to select your preference in the GUI:

• X11 (left) vs. Wayland (right) with the desktop display scale set to 125%.

Notice how the game renders at the display's native resolution when running under Wayland. *

Client-side window decorations

Once Wayland support was implemented, I received a bug report that the window was missing a titlebar and close buttons (called "window decorations") when running on GNOME. Most desktop environments will allow windows to supply their own decorations if they wish but will provide a default implementation on the server side as an alternative. GNOME, in their infinite wisdom, have decided that all clients must provide their own decorations, and if a client does not, they will simply be missing. I disagree with this decision; Factorio does not need to provide decorations on any other platform, nay, on any other desktop environment, but GNOME can (ab)use its popularity to force programs to conform to its idiosyncrasies or be left behind.

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.

The game has decorations now, but the theme doesn't match. Thanks GNOME!

Window resizing seizures

A video is worth more than a thousand words:

Mp4 playback not supported on your device.

PHOTOSENSITIVITY WARNING: Rapid flashing images.

I use the Sway window manager, and a particularity of this window manager is that it will automatically resize floating windows to the size of their last submitted frame. This has unveiled an issue with our graphics stack: it takes the game three frames to properly respond to a window resize. The result is a rapid tug-of-war, with Sway sending a ton of resize events and Factorio responding with outdated framebuffer sizes, causing the chaos captured above.

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.

Dynamically linked libraries