Hello,
Another year has come to an end, from all of us here we wish you good fortune in the year to come.
Hey it's the end of 2023 and surprise surprise we're still counting mod downloads. While most of those downloads are via the built-in mod manager, some of you like to automate your Factorio installs with download scripts or Docker containers.
Some of them crash when updating their mods, then restart, download all the mods again, crash, restart and after a short while it's very likely that the Factorio auth server starts ignoring the download script. So maybe this festive season is the time you'll remember your poor mini-PC sitting in a forgotten closet, mindlessly downloading 'Power Armor MK3' over and over again.
In 2023 we had:
If you want to see a few stats about your personal mod portal usage you can visit your personal recap here.
Last year we looked at how many different mods people usually download. For this year I'd like to show you a bit about the diversity of mod uploads this year. The first chart shows the different categories of mods released in 2023.
The second chart shows all the 2023 player downloads grouped by mod category. It confirms the cliché that people are only here for the Content and I should've prepared these chart for mod tags instead.
This year we continued our quest of improving ✨ discoverability ✨. First we added the automagical Highlights page, every week it tries to be smart about picking an interesting selection of mods. It works okay but is still in a "experimental" stage where we haven't decided where to take it next.
A bit later we reworked the mod portal search and launched the Explore page. It provides a fast, search-as-you type experience with faceting.
We also did quite a bit of behind the scenes work, some of which I want to highlight here:
Modding is an integral part of Factorio and we have put tremendous effort into providing a good mod management experience. However, third-party mods have always been secondary to base game work, so while the experience is "good", it is not "great", and there are many points of friction that have remained unsolved. Starting with 2.0, we will ship the game with multiple built-in mods, so the mod manager and dependency management have now fallen under the "base game experience" umbrella. Due to my extensive modding experience, I have a personal interest in improving mod management for both users and modders, and I am intimately familiar with the pain points of the current system. I created a laundry list of my biggest wishes and frustrations and took it upon myself to begin solving them.
Picture this: You have just configured your mod list for a new playthrough of Krastorio 2, and you start a new game. Unbeknownst to you, you accidentally enabled the Power Armor MK3 mod, which Krastorio 2 has marked as incompatible. It takes until an hour into the playthrough for you to realize that the Krastorio 2 content is missing, and now you have to throw out the save and start over from scratch.
This is a situation that I have personally experienced numerous times both as a player and as a mod author. In 1.1, the game does not inform you when conflicts occur, but instead just silently loads the mods that it can and carries on. This has caused many mod authors to shy away from requiring dependencies altogether, and users to complain when a mod has a lot of dependencies. Issues surrounding this are so commonplace that Space Exploration implemented their own dependency errors system that informs users which mods are missing.
Factorio 2.0 will inform you when dependency errors occur, and will not allow the game to load until they are resolved.
Now that we have proper dependency errors, we need to improve the workflow for resolving them. In 1.1, you are given two options when an error occurs: disable the affected mods, or disable all mods. If resolving the issue requires enabling mods, changing active mod versions, or updating mods, then you first need to disable mods to allow the game to load before you can access the mod manager GUI to resolve them. This was so annoying for my modding workflow that I wrote a command-line mod manager to avoid the constant game restarts.
The solution was simple: In 2.0, I added a new Manage mods button that allows full access to the mod manager GUI, including all mod portal functionality.
You can see it in the screenshot above.
In 1.1, the install tab of the mod manager is relatively simple: you have a list of mods with some basic sorting/filtering options and an info pane to show mod details. The game fetches the entire mod list and creates the entire table at once, leading to noticeable performance issues and nigh-unusable performance when the game is in debug mode.
With the advent of the new explore page on the mod portal website, the usability difference between the mod portal website and the in-game mod browser has grown even larger. I have settled into a workflow of searching for a mod on the website and only searching for it in-game after I have found the mod I need. Wouldn't it be nice if the game had the same experience, with all of the same searching and filtering capabilities?
2.0 features an all-new explore tab that does just that.
Note: Filtering by bookmarked mods has not been implemented in the new GUI, but will be there for the 2.0 release.
There were several considerations I had to make when implementing this new interface. The 1.1 method of fetching the entire mod list every time was not a great solution for performance and network usage reasons, and would involve re-implementing the complex search algorithms client-side in C++. This would lead to inevitable differences between the website search and in-game search, which would not make for a great user experience. On the other hand, implementing a mod portal search API would ensure parity between the website and in-game search results.
We went with the server-side approach. To get the project up and running quicker, I chose to implement a mock server in Go that would fetch data from existing mod portal APIs and serve it in the new format. Thanks to Go's built-in HTTP libraries and very easy-to-use JSON parsing, it only took a few hours to get this server up and running on my laptop. As I implemented the explore GUI, I was able to freely adjust the API as needed without taking up any DevOps time. This allowed me to take my time doing some much-needed cleanup and refactoring of the mod manager GUI to make the explore tab easier to implement and pave the way for more changes in the future.
Once the client-side implementation was complete, it was up to Vinzenz to implement the real API. Thanks to the robustness of the mock server, only a few issues were found during testing against the real API, and merging the feature went relatively smoothly.
I feel that these changes have fixed my largest grievances with mod management. My laundry list is far from complete, but in the interest of getting 2.0 out to you all as soon as possible, the majority of my plans will have to wait until later versions. Stay tuned for more to come!
As always, send POST requests with your feedback to the usual places.
