Hello,
a large part of the team is attending GDS, if you are in Prague and interested in Games, you are welcome to come as well.

New Manage/Install/Update mods GUI (Twinsen)

As we were going through the main menu, improving the looks and sometimes the interaction of most of the GUIs, it was obvious the mod management needed some attention. Most of the interaction was quite unintuitive and limited, making most players prefer using the web version and managing the files manually.

Mods will be managed, installed and updated from the same GUI, the 3 operations being shown as 3 tabs. The interaction, arrangement and intuitiveness of the GUI should be vastly improved. It still won't have all the features of the online mod portal (such as discussions) but provides a very quick hassle-free way of installing and updating mods without having to deal with files.

Note these are just mockups, the in-game integration will be starting soon, and it should be done for 0.17.

The most notable changes are:

• Only mods compatible with your game version are shown.
• The list of visible mods can be additionally filtered by their category.
• Mods will have a picture when browsing the mods list.
• When updating mods, you can clearly see version numbers, browse the changelog, and choose what updates, if any, you want to skip.

Invariants are required (Rseding)

In a version of Factorio long ago we had this recurring problem with items and inventories. When an item was added or removed from some inventory it's meant to generate an event about what changed. These events are used for a multitude of different things and allow for many code simplifications and optimizations such as "turn off the inserter until a new item shows up in the chest it's taking from". It used to work like this:

• Code to remove/add some item in some inventory
• Some logic with those items
• Send the event about what changed in the inventory

However as with most things - things changed. Someone would add in new logic or just forget and not send the changed event. After all - programmers are human and we make mistakes. The issue kept recurring and was incredibly hard to test for because you can't write a test for some logic which doesn't exist yet: you can't test something is correct until you've written it and if you forgot to sent the changed event you can forget to write a test that checks you didn't forget it.

The only solution I could think of to the "human problem" is to remove the human part of the problem. If we no longer needed to remember to write the code to send the event and it "just happened automatically" any time we changed items around then the problem would just go away. That invariant - that changing any item sends an event - solved the problem. However, it also taught me something: if some invariant is ever allowed to vary (aside from the obvious "an invariant that varies isn't an invariant") it's completely useless.

Invariants are amazing tools. We can write tests to enforce an invariant. Programmers don't need to think about handling things outside of the invariant because they can always say: "it should work as the invariant describes so I just don't need to handle the other cases". If the invariant is ever broken it's clearly a bug and has a clear solution.

As always, let us know what you think on our forum.