Mod settings

Right now when you want to customize a particular mod you have to:

1. Know what folder the mods are stored on your computer
2. Unzip the mod
3. Figure out what line of which file has the thing you want to change
4. Save and optionally re-zip the mod
5. Hope what you changed is compatible with the way the rest of the mod works

This is obviously not so great and I want to address the main problem: there's no good way for mod developers to give users any portable way to configure their mods.

To fix this we're going to add the ability for mods to define settings that will be presented like our in-game options menu now under a new section "options -> mods". This will let mods give some basic information about what kind of setting they have and we can present it to the player in a (hopefully) nice GUI with verification and feedback about why what they've entered isn't valid (if it's not valid) as well as the ability to change them runtime should the particular setting allow it.

We can then sync these settings on joining multiplayer sessions (or not should you not want your settings to carry between games) and everything will just work.

Optimizations

My (Rseding91) favorite tasks are still optimizations. I can sit for hours (sometimes all day) working on improving some section of the code and not get bored. 0.12 saw a major improvement in performance and during 0.13 development there were a few edge case slowdowns that got fixed but nothing much was done during 0.14 development. For 0.15 I've started looking again at performance and not at the obvious slow areas. Mostly because there aren't any obvious huge slow areas (or we already know that 25,000 belts tend to be slow) but all of the surrounding code that gets run each tick. Honza (another Factorio developer) said it best to me the other day: "I think our performance issues are death by a thousand cuts." meaning there's no one thing that's particularly slow but everything is just a little bit slow.

I took a few larger save files and started looking at them and every time I would re-run the profiler some small piece of code would show up taking 1-2% of the time. I'd spend 20~ minutes re-writing it and then it takes < 0.1% of the time (not accurately measurable by the profiler). I did that for 3 days and when I finished with the saves I had the end result was almost a 2x speedup over 0.14. Our test suite was invaluable during all of this to make sure I didn't break anything in the name of performance.

The great part about these "micro optimizations" is that they are almost never specific to one thing but are shared pieces of code so improvements to them gives general gains across the entire game. The save files I was testing with that would run around 30 UPS in 0.14 are now running between 55 and 60 UPS in 0.15. There are still many more areas like this that can be addressed so I'm always interested in unique save files that stress different parts of the game.

Rendering test

Albert has spent some time this past week making a test render to see how the new train models will hold up in higher resolution settings, and has put together this UHD render of a simple train scene.

Click to view full resolution

While the final render may look very pretty, it only has a minimal amount of post-processing applied, instead relying on the setup of the scene and the specifics of the render to really show off the latest models.

As always, let us know what you think on our forums