Written by GreenFlag, edited by stringweasel, Nanogamer7, Conor_, Therenas, MyNameIsTrez, Firerazer

For the first issue in the last month of the year, first-time contributor GreenFlag presents their first big modding project that aims to add a proper RTS-style campaign to the game, in the spirit of the game’s tutorial levels. It’s pretty involved, and a lot of fun!

Story Missions: The Story GreenFlag

I want to talk about my Story Missions mod. It’s actually hard for me to decide where to start, because the idea of additional objectives for the campaign was born in my head more than a year ago. After 200 hours of Factorio I started to feel the slightly repetitive gameplay and was starting to miss a challenge. At the same time, I didn’t want to keep starting a new game and building and developing everything from scratch. So I came up with the idea of making my own maps along the theme of the tutorial, only it wouldn’t be a tutorial anymore, but regular missions instead.

When I first tried the Factorio editor, I was surprised that it was actually quite limited. I had a lot of experience with editors for StarCraft/Warcraft, in which you would write scripts in-game, using a system based on “triggers”. Basically, you have to find a good trigger which matches your requirements as closely as possible, then you have to just add values and that’s it. I was sad that in Factorio, all the scripts are not able to be pre-defined in some interface directly in the game, but as pure code instead. The basis of all this are .lua files. After discovering this problem, and in fact taking the time to re-learn how to program after 10 years, I shut the game down for good and haven’t turned it back on for a few months. (I hope no programmer will blame me here.)

Yeah, never say never. Suddenly from one day to the next I got insanely bored and I turned Factorio back on in the Spring of 2021. I actually originally wanted to delete the game, but instead I turned it on and looked at old save files from the New Hope scenario. I looked at the map structure again and started digging through the scenario files. I found it strange that after the patch (I think it was 1.1), the mod no longer appeared in the main menu section. Since my professional job is to fix everything, I wanted to find out why it wasn’t working. When I found out why and actually looked at the control.lua structure of the scenario, I thought: “Why not try that too?”, and that’s where it all started.

I went through all the tutorial map files and the New Hope campaign, and through that I learned how to make my own missions. Then all it took was a bit of inspiration (Starship Troopers, Star Wars, Star Trek, Star Gate, Avatar), a bit of experience playing games like StarCraft 1-2, Warcraft 3, Age of Empires 2, Command & Conquer (Generals, Tiberium Wars, Red Alert 2, Dune 2000) and then some heavy self-criticism, et voilà (that’s French): Within 3-4 months, a campaign of five missions and an improvised story was created, trying to be as lore-friendly to the original game as possible.

The whole campaign takes place about two years after the engineer first crash-landed on the planet Nauvis. Somehow, he survived and sent up a rocket with a satellite and was rescued a few months later. Subsequently, Earth decided to colonize the planet, taking even more resources than the engineer himself had beforehand! Add to that the space thugs, i.e. “pirates” (I love it when you say “Space Pirate”, I always think of anime series/movie Captain Harlock), it starts to get pretty cool. I won’t tell you the plot of the mod here of course, you’ll have to play it yourself and find out. Admittedly, I’m not J.K. Rowling, and the plot reflects the mood I was in at the time. It’s safe to say that I’m not entirely happy with the story, as it’s not the best I’ve ever put out, but it does fulfill its purpose.

Well, I guess we’re at the end of the “how the Story Missions mod came to be” story. I could go on and on about the creation of each mission, but you’ll find that as an Easter egg at the end of the fifth mission (when you hit continue after completing the game). The story so far is not finished and I am currently working on five more missions that continue the adventure. You should all be pleasantly surprised by mission 9 (or even cheering with joy). I’ll give you a little teaser:

I say goodbye and thank you all for your support.

P.S. It’s weird to me that Factorio is a Czech game and I’m citizen of Czech Republic. It would be nice to someday meet the authors of the game 😀

Contributing

As always, we’re looking for people that want to contribute to Alt-F4, be it by submitting an article or by helping with translation. If you have something interesting in mind that you want to share with the community in a polished way, this is the place to do it. If you’re not too sure about it we’ll gladly help by discussing content ideas and structure questions. If that sounds like something that’s up your alley, join the Discord to get started!

Written by stringweasel, edited by Nanogamer7, Conor_, Therenas, Firerazer, MyNameIsTrez

For issue #52, stringweasel returns with part two of the Fluidic Power Experiment where he dives into the rather surprising performance implications of his creation. If you liked last week’s article, you’ll like the second part this week. What a surprise!

The Fluidic Power Experiment: Part 2 stringweasel

What is it again?

In last week’s article I talked about the history of Factorio power network overhaul mods and how they worked, and then explained my own take on it called Fluidic Power. It’s recommended that you read that article first, but in a nutshell, I made Factorio’s power distribution more realistic by simulating it as a fluid – using the already built-in fluid simulation mechanics. This means you need to use transformers to minimize voltage drop over distance. It also means that, for example, it is more work to keep your laser turrets firing at 100%, or to build highly beaconed setups.

These new limitations mean that Fluidic Power achieved its goal of creating a new game mechanic that more closely resembles realistic electricity. However, it does introduce significantly more performance overhead with all the new fluid calculations required. I didn’t want to put a mod on the mod portal that will bring your PC to a halt if you built a decently sized factory. So therefore I set out to do some research. Do the extra fluid calculations really have a significant impact?

Is the performance playable?

There is a reason why Factorio implements electricity the way it does. It allows us to build absolutely gigantic factories at such a scale that you can get lost in them. Adding more realistic power might inhibit performance so significantly that you’d have to build smaller factories, and nobody wants to do that. So the question is: What would Factorio’s performance actually be like if there was fluid flowing through each and every power pole. I needed a benchmark map, so I set out to build a pure Fluidic Power base with the help of my friend JanKrater.

My goal for this base was to think of the most performance efficient way to build a base, and to then do the exact opposite (well, mostly). This resulted in a spaghetti base with way too many power poles, very convoluted belts, and way too many power-hungry laser turrets. Very importantly though, it manages to produce a steady 45 science per minute, and it draws about 600 MW with not a single efficiency module in sight.

Normally, Factorio runs at about 60 updates per second (referred to as UPS), and I managed to push this benchmark map to run at 70 UPS on my old-ish PC (i7-4770k 3.5GHz CPU, DDR3-1600MHz RAM). This means that it takes about ~14ms to update the whole base once, called one tick, where for 60 UPS the maximum amount of time per update can be 1/60 = ~16.6ms. This number is also shown below in the “show-time-usage” debug output. Interestingly, it also shows that my mod script (mod-FluidicPower) has a neglible effect on the performance (~0.05ms). This is possible because my mod makes very few calculations, as it’s able to offload all the expensive fluid and power calculations to the optimized game engine. The main timing information to look at is Fluid Manager and Electric Network.

In the output above the game tells you where most of the time is spent, and it initially confused me that game seemingly spends most of its time in the Electric Network. My expectation was that the Fluid Manager would take the biggest performance hit, but instead the output shows that the Electric Network (~10ms) is using over 70% of the update time (~13.7ms), and that the Fluid Manager (~0.03ms) doesn’t seem to be doing anything at all. This doesn’t make any sense, because I expected the amount of fluid calculations to be a massive performance drain. I headed to the Technical Factorio community, where they push Factorio’s performance to its absolute limit. Here, the brilliant mathematician SteveTrov explained to me why the in-game time usage can be misleading if you don’t know how the timing calculations are actually implemented. He described it as such:

This essentially means that the Fluid Manager’s time usage information is entangled in the Electric Network’s and Heat Manager’s time usage. It’s not possible to calculate an accurate metric as to which part takes the most processing time without changing the Factorio game engine itself. I need another approach to know if the Electric Network really is taking more processing time than the Fluid Manager, and if so, by how much?

An UPS expert called flame_Sla then suggested that I download the Very Sleepy Profiler to see detailed information about which of the Factorio engine’s C++ functions are called most often. Their community often use this tool to optimize the world’s largest and most UPS efficient megabases. In the output of the tool below you can see which C++ functions take the most time, listed in descending order. flame_Sla did also mention not to focus on the absolute times shown, but to rather use it as a metric which the biggest culprits can be identified with.

This showed something that I didn’t really expect. The fluid system (FluidSystem::update) was only in the top 10 worst timed functions, and the Electric Network was still taking more processing time! It turns out the main problem was FlowStatistics<ID<...>...>::onFlow, which is mostly called by the electric network. These flow statistics collect the data necessary to view the game’s graphs, eg. the power production window. This means that the game is not only slowing down because of all the new fluid calculations, but also to collect information to draw the graphs for all the new power networks!

It’s very likely that the collection of Electric Network statistics could take a significant amount of processing time with Fluidic Power. The Factorio engine is designed to only have a handful of electric networks, or even just a single one. The game needs to collect and update information for every power network you have, which will normally only be a few distinct datasets. So instead of having a handful of networks, Fluidic Power is designed so that each and every power pole is a single electric network. The Factorio engine will then attempt to collect statistics for each of these electric networks – which is about 3000 electric networks in my benchmark save! That’s at least 100 times more networks to collect statistics on than Factorio is designed for. This has been a known limitation for some other mods, but Fluidic Power takes this to a new extreme. However, we still don’t know the impact of these calculations relative to the fluid calculations. Does the collecting of statistics really take that much more time than the fluid calculations themselves?

flame_Sla mentioned that he once managed to measure the Fluid Manager’s time usage on the world’s biggest megabase, and that it only used ~0.4ms for a 40KSPM 60UPS megabase! That means only 2.5% of the update time was spent on fluid calculations! The way he isolated the Fluid Manager’s time usage from the Electric Network is by completely eliminating the Electric Network from the measurement. He achieved this by changing all machines to run on wood as fuel which meant no more electricity was used and the Electric Network was idle. Due to how Fluidic Power works, I cannot easily eliminate the effect of the Electric Network the same way without also reducing the Fluid Manager’s load, but I can do it the other way around! I can remove all the fluid components, and replace them with EEIs that supply or drain the power. This will cleanly eliminate all added fluid computations without removing the strenuous load on the Electric Network by making sure the factory is still running normally. In order to record an accurate and comparable time usage metric I also attempted to force Factorio to run on a single core. I ran a quick script to replace the power poles’ hidden fluid components for this test and the result are as follows:

	Baseline	Modified	Difference
Electric Network	9.3ms	9.2ms	0.1ms
Heat Manager	0.03ms	0.03ms	0ms
Fluid Manager	0.13ms	0.08ms	0.05ms
Total	9.46ms	9.31ms	0.15ms

Table showing timing results of unmodified baseline benchmark compared to the modified benchmark where all fluid components are removed.

This shows that all the extra fluid computations from Fluidic Power in this benchmark only take roughly ~0.15ms! This number is probably still not very accurate as it’s within the noise margins of the spaghetti base, the test is not ideal, and measuring time in parallel threads is inaccurate. However, it does give us a good indication of where most processing time is going. This proves that the electric network does have the biggest impact on performance by far, and that the extra fluid calculations are almost negligible. It makes one wonder what performance could be achieved if the electric network didn’t unnecessarily collect statistics – perhaps we’d see enormous Fluidic Power megabases with gigantic transformer substations next to nuclear reactors and massive solar panel arrays.

All in all, Fluidic Power performs much better than I had expected. Any perceived slowdowns will mainly be caused by the many electric networks collecting statistics, and not the fluid computations themselves. You will still likely be able to launch a rocket without having your UPS drop below 60 UPS. You could probably even build quite a bit bigger if you have an efficient layout (I’ve achieved 90SPM at 220UPS!), and the mod won’t neccesarily tank your UPS as Rseding1 predicted. Factorio is luckily really well designed and optimized, even when not running as intended. This proves that Fluidic Power is definitely playable performance-wise, but that’s not the only aspect that counts.

Should you play it?

Personally, I think Fluidic Power creates a really fun challenge. It’s maybe not for you if you’re planning on building a long-lived megabase, but if you’re looking for an interesting adventure playthrough with new challenges then this mod might just be for you. I really enjoyed overcoming all the new gameplay obstacles it creates. For example, the machines furthest away from your steam engines shut down first, which are usually the electric mining drills on your coal patch that feed your boilers. I hadn’t ever experienced such a dangerous coal death spiral before. Or, if you defend your walls with laser turrets, you’ll need to ensure there are enough transformers to supply power at the correct voltage.

However, my favourite part of this mod by far is knowing that there is actual electricity flowing through the power poles. You can even see the waves of intermittent brownouts over your machines when your base is pulling too much power, like when many laser turrets fire at once. It’s similar to the feeling I get when I look at a circuit I designed, while knowing it’s working because of the fluid-like motion of electrons through the copper and silicon. It builds on the feeling of seeing your complex networks of belts working together to build a rocket. It makes the factory feel more alive. You can basically see its steady heartbeat, and it’s really satisfying.

Contributing

As always, we’re looking for people that want to contribute to Alt-F4, be it by submitting an article or by helping with translation. If you have something interesting in mind that you want to share with the community in a polished way, this is the place to do it. If you’re not too sure about it we’ll gladly help by discussing content ideas and structure questions. If that sounds like something that’s up your alley, join the Discord to get started!

Written by garr890354839, everLord, edited by stringweasel, Nanogamer7, Conor_, Therenas, Firerazer

This week is the golden anniversary of Alt-F4, it being issue #50 and all. No special festivities though, feels like we are doing that often enough. Instead, garr890354839 makes their first contribution by talking about some of the weirdnesses and some of the math surrounding rocket silos. Then, everLord introduces another community event by the comfy squad called ‘Biter Battle Championship’!

The Rocket Silo: Mysteries in Full garr890354839

Ah, the rocket silo. It is the largest in-game entity outside of the crashed spaceship. It is also one of the most expensive craftable entities. However, when it’s placed, it has some weird effects on the electric grid. We also mostly know that using productivity modules inside of it pays off. What about around the silo? All of that right here!

Continue reading