1.1 stable kovarex Hello, we have a stable version! When we were releasing the 1.0 FFF-360, we actually stated that there were "around 150 bugs on the forums and around 80 internal tasks to be solved". These were obviously minor issues, things hard to reproduce or very rare problems. In other words, it was quite reasonably stable, which normally goes without saying when it comes to Factorio stable versions. But it proved to be a mistake wording it this way, since some media picked up on it and presented it as a "fairly bugged release". So I'm pretty thrilled to finally get to the point, where we actually have 0 known issues and 0 active bug reports on the forums. Its like cleaning the kitchen properly, so you can start cooking something fresh. More about that next week! For now, we want to go over some of the features of the 1.1 that you might have missed until now if you've been sticking with stable 1.0.
The Beacon Redesign V453000 The Beacon is one of the last entities that don’t have high resolution graphics yet. In the rather recent FFF-339, Albert presented the updated and redesigned Beacon. After your responses we realized some issues we hadn’t seen with the Beacon before, and we have taken some time to think about it... The red tower design by itself is very impressive, which gave it so many plus points that we didn't focus enough on the fact that it is taking too much visual attention. In this case, this happens because of aggressive red colours, the big contrasty yellow eye-like circle, the entity being quite tall, and the electric beam animation. Random variations are usually helpful to make entities look nicer in clumps (like resources), but not in this case, especially as other built entities don’t have any variations. The options to take from here would be to either update the original design, adjust the red tower, or start a new redesign. The Beacon is a very special entity, either it doesn’t appear in a factory at all or very little, or it’s everywhere. It doesn’t really do anything by itself so it doesn’t really need to show much activity either. The original design has its own problems and also saturates the screen very quickly, as they are bright, also tall, and they always move, attracting attention to the movement constantly. As for the red tower, most of the top part would have to be removed which is almost a complete redesign already, but parts of the hole could be recycled for a new version... We chose to start a new redesign, with the design goal of the Beacon trying to take much less attention.
More particle optimisations Allaizn Rseding's recent optimisations of the particle system (FFF-322) made particles much more lightweight than they were before, but it still left particles as rather complex beasts. A quick summary of the possible actions a particle can make during it's update: Move their own position. Advance their animation to another frame. Land in water and apply a trigger. Apply another trigger with a certain frequency. Remove themselves from the game world once their life time ends. What makes this complex is that triggers are general purpose systems that can do all kinds of things, including creating and destroying entities, fire, smoke and other particles as well as playing sounds or recursively applying even more triggers. In other words: applying a trigger is an "anything can happen" situation and thus totally unpredictable, which in turn makes optimisations extremely hard.
Factorio logo patches Jitka We would like to introduce our new fabric Factorio logo patches, which are now available at our e-shop. These sew-on embroidered patches are ideal for clothing, hats, backpacks, etc. The dimensions are 2.5 x 12 cm. As we are uncertain how large the demand for these patches is going to be, we have only limited stock available at the moment. Please note that our online store ships only once a week every Wednesday, and it is highly possible that the orders placed now will not be delivered before the 25th or December, this applies especially for orders shipped outside of Europe.
Release plans Klonan This week we released version 0.17.79, and marked it stable. Internally we have been calling this 'Stable 3', and the main feature was the new tooltips we showed in FFF-318. There is one constraint we put on ourselves when we started this more swift feature release schedule: We want to avoid breaking mods. This is easy enough in principle, don't start renaming things, don't remove API features, etc. However as we develop further, there are certain features and improvements that we can't realistically do in a way that won't break mods, such as the new Character GUI (FFF-289), and color correction (FFF-320). It is for this reason that we are going to accumulate some of these mod breaking changes, and release them all at once. Since it will definitely be breaking mods, we will bump the major version number, so it will be 0.18.0. We have already internally started merging in these 0.18 features into our master branch, so we will not be doing any more 0.17 releases (unless something absolutely catastrophic is discovered).
The boring phase of bug-fixing is still going, slowly but surely. Stable should be released next week, but with some people on vacation (Ben, Jitka, kovarex, Klonan, Sanqui) and with the release of WoW Classic, it might get slowed down a bit. (By the way, some of us will be playing on Pyrewood Village, Alliance, so if you want to have the chance of meeting Twinsen, kovarex or dominik while leveling, you can join that server). So since there's not much happening, this week we decided to explore some unpopular or controversial opinions about the game from within the team. In Wube we don't have a very strict management structure, everyone is free to have ideas and opinions about almost all aspects of the game. This means that with almost every change we argue and discuss a lot before making a final decision. Sometimes we argue about everything, from the smallest GUI change, to how a major feature should work. This is probably not a bad thing since this means changes are usually well thought out and unpopular ideas or changes don't make it to the game very often. Some people feel quite strongly about their opinions or sometimes the team is very divided on what should we do. Today we'll share some of those opinions and controversies. Keep in mind that these are simply opinions and none of them will actually make it into the game, we are simply sharing them to have an interesting discussion.
Lua Mod GUI additions Rseding Mod GUIs have been an interesting part of Factorio modding since I started working at Wube. They allow scenarios and mods to add GUIs that look and feel like the base game. When someone new to Factorio modding is introduced to how they function, they almost always have the same questions: Why is mod GUI part of the game state? Why do mod GUIs need to be deterministic? How can I edit the base game GUIs? And then comes the explanation: The actual widgets are not part of the game state and are not deterministic. The part that mods have access to however is. In an environment where mods have to operate deterministically, if a mod is allowed to read some data that data must be deterministic. In that simple bit of logic; if a mod can read the checked state of a checkbox then that checked state needs to be deterministic. If the mod didn't have access to read that state it would need to store the last-known state and update it every time it got the changed event. Try to imagine that: every single mod implementing their own system for remembering last-known-state about GUIs they're using. Instead of leaving that entire mess to mod developers we decided long ago that we would manage that "last-known-state" for them. The basic data about what a given mod wanted to show on screen is recorded so mods can read and change it as they want and not need to be concerned with constantly updating it every time some changed event happens. Additionally it means that the game can use that "last known state" to restore what the player sees if they save, quit, and load the game. That still leaves the last question: "How can I edit the base game GUIs?". Using the above example it's much easier to explain that: as a mod - you can't. The base game GUIs are not implemented using this same system - they're just pure collections of widgets. None of the "last known state" is saved anywhere and it's all lost when saving, quitting, and loading. However, that leaves a divide: we need to implement each widget type through the "CustomGui" system in order for mods to be able to use them. With this latest release I finally figured out a way to do tabbed panes since they're special in how they work compared to everything else. Additionally I figured out a semi-friendly way for mods to put things directly on the screen in a way that the player can drag them around - instead of being limited to some fixed area (left, top, center, etc). Another system which I've been thinking about for quite some time is some way for mods to position GUI elements relative to base game GUIs. For example: a mod wants to add a pane which shows on the left of the character inventory GUI. Currently it's not possible - the base game GUI isn't readable by mods so they can't do anything with it. My idea is some system where a mod can say "I want to add this GUI, and I want it to be shown relative to the character GUI on the left side" and then any time the character GUI is shown it would also show the mod GUI. There are some critical parts to this new system. It needs to: Be easy to expand (either automatically works with all new base game GUIs or works with minimal effort). Not break with simple refactoring. Not cause other programmers trouble by existing. Not prevent base game GUIs from working how they need to work. So far none of it seems impossible. I don't know when I'll have it working, but I'm looking forward to what mods will do with it.