• Fixed false positives in detection of crashes caused by incompatible version of RivaTuner Statistics Server.
  

You can get experimental releases by selecting the 'experimental' beta branch under Factorio's properties in Steam.

• Fixed false positives in detection of crashes caused by incompatible version of RivaTuner Statistics Server.
  

You can get experimental releases by selecting the 'experimental' beta branch under Factorio's properties in Steam.

A long time ago, in FFF-191 I wrote about improving the GUI. Well, things are finally starting to move, so this week I'll bring you an update on that. We even have a GUI team:

• Twinsen(me): UX and programming
• Albert: UI, graphical design, layouts, mockups, UX
• Rseding91: main programming and GUI internals

The plan is to go through the entire game's GUI (including main menu, all entity GUIs and all game windows) and improve it both visually and interaction wise. This is quite a huge undertaking because:

• Factorio's interactions are quite complex
• If you count all the entity windows and panels, we have about 120 windows to go through in the game.
• Mods can change many aspects of the game so we have to account for that to make sure windows still look good and are still easy to use: e.g. having 15+ recipe categories, having assembling machines with 20+ module slots, having recipes with 20+ ingredients, having players with 200+ inventory slots, etc.
• Many players are already used to interacting with the game in a specific way, so any major changes are hard to make.
• Our GUI back-end (heavily modified AGUI) is not exactly well written, programmer-friendly, or feature-rich.
• Many of the features and polishing we want to add were not done previously due to their programming complexity.

At the moment we are still early in the project, just defining the style and the concepts. During the next months, I'll try to make a series of FFF talking about the improvements we are making (starting with this one) so you can see how the project progresses, and offer feedback along the way.

Everything I mentioned in FFF-191 will be there, but we have even more cool improvements coming to the toolbar that we are working on, so today I'll talk about something else: the new train/locomotive GUI.

Disclaimers:

• Everything you see are mockups made by Albert and are not from the game, but we will try to make it look almost identical in game.
• The style (colors and look) is not final. This is the 3rd iteration and Albert is still experimenting with making everything look nice.
• The purpose of these mockups are mostly to define the layout and interaction.

This is how the new Locomotive GUI will look. As you notice, apart from the style changes, they way the stations and conditions are shown is very different, but I'd say much more intuitive, informative, and easy to use.



Let's go through a short use case. You click add station and the list of stations appears. You can add a station by clicking on the station in the list or by clicking it in the small map. The map can be zoomed and moved around so you can easily find your station. Also, as you hover over stations in the list, the map will show their location.

The stations marked differently are unreachable from the train's current position. This way you can more easily recognize and possibly ignore stations outside of the current network.



Once you click a station, it is added to the schedule, along with a default condition. You can continue adding more stations, or add/edit the conditions for the new station.









Finally a schedule can look something like this. The path of the train will be shown. We will try to paint the path the train is taking at the moment, it will change as the train takes different paths.



The fuel can be accessed from the separate tab and the color of the locomotive can be changed using the color picker.
The buttons in top of the map, from left to right are as follows:

• Turn station names on or off.
• Change the angle of the station names.
• Switch to map view.
• Switch to camera view.
• Center view on the train.

The small 'info' button you see on the right side will be a help button we will use throughout the game to help explain how different GUI work and when their elements mean. We will write more about this in some of the next parts of the FFF GUI update series.



We also want to add a neat tool for advanced players. Control-clicking on any point on the locomotive's map (or any station) will add a 'Temporary stop' to it's schedule. The train will try to go as close as it can to that point, wait a few seconds and finally automatically remove the 'Temporary stop' from it's schedule. This is very useful for quick transportation. It also allows you to quickly 'hijack' an existing train and use it to get somewhere, since the 'Temporary stop' will be deleted and the train's normal schedule will be resumed.

Another quality of life improvement will be a game option to automatically add some fuel from the player inventory when building vehicles (car, tank or locomotive), making rail transportation as simple as placing a locomotive on a rail, entering it and control-clicking where you want to go.

We hope you like the proposed changes. No doubt things will change as we implement and playtest these changes, but we thought it would be interesting to show you an early preview.

Finally the million dollar question is when will this be in game? Because it's quite a bit of work we already pushed the GUI update to 0.17. On the bright side, this mean 0.16 will come a bit sooner.

Let us know what you think by commenting in our usual topic at the forums.

A long time ago, in FFF-191 I wrote about improving the GUI. Well, things are finally starting to move, so this week I'll bring you an update on that. We even have a GUI team:

• Twinsen(me): UX and programming
• Albert: UI, graphical design, layouts, mockups, UX
• Rseding91: main programming and GUI internals

The plan is to go through the entire game's GUI (including main menu, all entity GUIs and all game windows) and improve it both visually and interaction wise. This is quite a huge undertaking because:

• Factorio's interactions are quite complex
• If you count all the entity windows and panels, we have about 120 windows to go through in the game.
• Mods can change many aspects of the game so we have to account for that to make sure windows still look good and are still easy to use: e.g. having 15+ recipe categories, having assembling machines with 20+ module slots, having recipes with 20+ ingredients, having players with 200+ inventory slots, etc.
• Many players are already used to interacting with the game in a specific way, so any major changes are hard to make.
• Our GUI back-end (heavily modified AGUI) is not exactly well written, programmer-friendly, or feature-rich.
• Many of the features and polishing we want to add were not done previously due to their programming complexity.

At the moment we are still early in the project, just defining the style and the concepts. During the next months, I'll try to make a series of FFF talking about the improvements we are making (starting with this one) so you can see how the project progresses, and offer feedback along the way.

Everything I mentioned in FFF-191 will be there, but we have even more cool improvements coming to the toolbar that we are working on, so today I'll talk about something else: the new train/locomotive GUI.

Disclaimers:

• Everything you see are mockups made by Albert and are not from the game, but we will try to make it look almost identical in game.
• The style (colors and look) is not final. This is the 3rd iteration and Albert is still experimenting with making everything look nice.
• The purpose of these mockups are mostly to define the layout and interaction.

This is how the new Locomotive GUI will look. As you notice, apart from the style changes, they way the stations and conditions are shown is very different, but I'd say much more intuitive, informative, and easy to use.



Let's go through a short use case. You click add station and the list of stations appears. You can add a station by clicking on the station in the list or by clicking it in the small map. The map can be zoomed and moved around so you can easily find your station. Also, as you hover over stations in the list, the map will show their location.

The stations marked differently are unreachable from the train's current position. This way you can more easily recognize and possibly ignore stations outside of the current network.



Once you click a station, it is added to the schedule, along with a default condition. You can continue adding more stations, or add/edit the conditions for the new station.









Finally a schedule can look something like this. The path of the train will be shown. We will try to paint the path the train is taking at the moment, it will change as the train takes different paths.



The fuel can be accessed from the separate tab and the color of the locomotive can be changed using the color picker.
The buttons in top of the map, from left to right are as follows:

• Turn station names on or off.
• Change the angle of the station names.
• Switch to map view.
• Switch to camera view.
• Center view on the train.

The small 'info' button you see on the right side will be a help button we will use throughout the game to help explain how different GUI work and when their elements mean. We will write more about this in some of the next parts of the FFF GUI update series.



We also want to add a neat tool for advanced players. Control-clicking on any point on the locomotive's map (or any station) will add a 'Temporary stop' to it's schedule. The train will try to go as close as it can to that point, wait a few seconds and finally automatically remove the 'Temporary stop' from it's schedule. This is very useful for quick transportation. It also allows you to quickly 'hijack' an existing train and use it to get somewhere, since the 'Temporary stop' will be deleted and the train's normal schedule will be resumed.

Another quality of life improvement will be a game option to automatically add some fuel from the player inventory when building vehicles (car, tank or locomotive), making rail transportation as simple as placing a locomotive on a rail, entering it and control-clicking where you want to go.

We hope you like the proposed changes. No doubt things will change as we implement and playtest these changes, but we thought it would be interesting to show you an early preview.

Finally the million dollar question is when will this be in game? Because it's quite a bit of work we already pushed the GUI update to 0.17. On the bright side, this mean 0.16 will come a bit sooner.

Let us know what you think by commenting in our usual topic at the forums.

• Fixed a bug in the fix of electric network from 0.15.35.
  
• Fixed a crash when deleting chunks in specific cases. more
  
• Fixed a crash when coupling/decoupling trains through the Lua API.
  
• Fixed crash when unknown program arguments were passed. more
  

You can get experimental releases by selecting the 'experimental' beta branch under Factorio's properties in Steam.

• Fixed a bug in the fix of electric network from 0.15.35.
  
• Fixed a crash when deleting chunks in specific cases. more
  
• Fixed a crash when coupling/decoupling trains through the Lua API.
  
• Fixed crash when unknown program arguments were passed. more
  

You can get experimental releases by selecting the 'experimental' beta branch under Factorio's properties in Steam.

We are aware that we don't add so much content to Factorio these days. The reason we always state is that we are focusing on polishing and finishing the game. There are a lot of little things and details (some call it quality of life improvements), that don't look that awesome when reviewed one by one, but once they accumulate together they should make a big difference in the game experience. I'm going to talk about some of them now, but don't be afraid that we won't add anything new in the 0.16, as the work on the artillery train has already started and it is probably going to be epic :).

One of the problems with blueprints and ghosts was when you create blueprint of this:



Entities don't connect in the blueprint itself, so it looks as ugly as this:


Once you build the blueprint, it looks like this until it is actually constructed:


This bugged me, but the solution wasn't so straightforward. The logic of connecting entities is based on the them being actually placed somewhere on the map, but in the blueprint, the entities kind of exist "in the air". So I had to make special piece code for connecting entities in blueprints. I only cared about the visuals of belts, walls and pipes, so the code wasn't that complex after all. The looks like this in 0.16:



Next step was to make special code to connect ghosts entities together (and also normal versus ghost). This was the most tricky part, as we needed to make sure to not connect the internal transport lines of belts when doing so. Otherwise, the ghost belts would just work as normal belt :). We also needed to avoid ghosts of connected gates to not interfere with opening/closing logic of existing gates etc, but it works now and this is the result of the built blueprint now:



You can see, pipes are still not connecting. They are more delicate, as it would be harder to make the connections without affecting the performance of the pipe transition logic. We might either just not do it for pipes, use some special trick later, or wait until the fluid flow gets optimized. The optimizations would probably mean that the fluid control logic would be handled externally like belts, which might simplify things regarding the fake connections.

We described the problem in fff-201. Basically, blueprints with modded content would lose all their modded content whenever you load a game with the related mod deactivated. There is no going back, once you activate the mod again, the items are still lost.

The solution of this was one of the first task to Tom, one of our new programmers. Now when the blueprint is being loaded and it encounters entities that are no longer available, the original binary source of the blueprint and some additional meta data is saved along the blueprint, so once the mod is activated again, it can be fully revived.

Blueprint with modded content.


How it looks in the blueprint library when the mod is removed.


Preview of the blueprint that indicates where are entities that are not available now.


As always, let us know your thoughts, ideas and feedback on our forum.

We are aware that we don't add so much content to Factorio these days. The reason we always state is that we are focusing on polishing and finishing the game. There are a lot of little things and details (some call it quality of life improvements), that don't look that awesome when reviewed one by one, but once they accumulate together they should make a big difference in the game experience. I'm going to talk about some of them now, but don't be afraid that we won't add anything new in the 0.16, as the work on the artillery train has already started and it is probably going to be epic :).

One of the problems with blueprints and ghosts was when you create blueprint of this:



Entities don't connect in the blueprint itself, so it looks as ugly as this:


Once you build the blueprint, it looks like this until it is actually constructed:


This bugged me, but the solution wasn't so straightforward. The logic of connecting entities is based on the them being actually placed somewhere on the map, but in the blueprint, the entities kind of exist "in the air". So I had to make special piece code for connecting entities in blueprints. I only cared about the visuals of belts, walls and pipes, so the code wasn't that complex after all. The looks like this in 0.16:



Next step was to make special code to connect ghosts entities together (and also normal versus ghost). This was the most tricky part, as we needed to make sure to not connect the internal transport lines of belts when doing so. Otherwise, the ghost belts would just work as normal belt :). We also needed to avoid ghosts of connected gates to not interfere with opening/closing logic of existing gates etc, but it works now and this is the result of the built blueprint now:



You can see, pipes are still not connecting. They are more delicate, as it would be harder to make the connections without affecting the performance of the pipe transition logic. We might either just not do it for pipes, use some special trick later, or wait until the fluid flow gets optimized. The optimizations would probably mean that the fluid control logic would be handled externally like belts, which might simplify things regarding the fake connections.

We described the problem in fff-201. Basically, blueprints with modded content would lose all their modded content whenever you load a game with the related mod deactivated. There is no going back, once you activate the mod again, the items are still lost.

The solution of this was one of the first task to Tom, one of our new programmers. Now when the blueprint is being loaded and it encounters entities that are no longer available, the original binary source of the blueprint and some additional meta data is saved along the blueprint, so once the mod is activated again, it can be fully revived.

Blueprint with modded content.


How it looks in the blueprint library when the mod is removed.


Preview of the blueprint that indicates where are entities that are not available now.


As always, let us know your thoughts, ideas and feedback on our forum.

It’s been several weeks since we showed you the graphics for new high resolution circuit connector modules (FFF-202). However now is finally the time when we have them in the game. In this article I will briefly show you what was done both in the graphics and code, and what new benefits are there for you as players and modders.

I find the 0.15 version of the circuit connector module has following “problems”:

1. The wire connectors are different from the combinators.
2. Wires sometimes completely overlap, making only one of them properly visible.
3. Modularity - you can somewhat tell what is happening based on the LED states, but it could be much nicer.
4. Connecting a belt always looks weird, while the yellow structure which holds the connector box could be made more specific.
5. Some of the rotations are utterly useless.
6. The Lua definitions are spread over every single entity, so revisiting them all is a big pain.

We have been experimenting with the design of how the little pieces which connect to wires should look like. Most of them don’t really make sense in terms of physics, but visually the combinator ones seem to work pretty nicely in my opinion. That, and the circuit connector should be somewhat consistent with the combinators in this regard, so we just used the combinator design from when Albert made the combinators back in 2015 (FFF-88).



As we already tried to hint in FFF-202 (but we didn’t have a proper picture for it yet because the hr circuit connector wasn’t in the game yet), when you build entities vertically, they would very often only show one colour of wire.



To prevent this from happening, I took a pixel grid in Blender and I tried to always have the connectors far away from each other to prevent this from happening. The same issue happens with combinators, but let’s see if we ever have time to change that.



The system of drawing has slightly changed - now when you connect an entity, you can clearly recognize what it is doing and what is it's state. The rule is: Red/Green LED means write mode - generally stopping/starting the entity. Blue LED means reading mode - generally reading chest contents, reading signal colours, and so on.



If you only connect to the logistic network, even the wire connection points are going to disappear as you can see on the pump above.

Previously we were using the universal connector on belts, and to support it we made a special layer with a frame to hold it. This just uses another layer and generally looks rather weird.



We found it better to just make specific sprites for belts, which should integrate nicer and use less layers.



If you ever looked at how the circuit connector module spritesheet actually looks, you would have noticed that there are 32 rotations of it. For the first row, which is just flat on the ground, all of the 8 rotations are useful, but when the box starts tilting, the last three are looking away from the camera and are basically impossible to use.



At the same time, on some entities and in some cases it would be really cool to be able to just put the wire connection points at the opposite side of the box.

I put the two things together and made the impossible-to-use rotations just be a flipped version of the useful ones. The picture below is a mockup, the actual spritesheets have separate layers to allow the modularity mentioned above.



The game does not actually utilize all of the 32 rotations, but it’s easier to have them all for future new entities - importantly also new entities added by mods.

When the graphics were finished, I was looking at how could I put the connector in the game. We had good experience with generating the Lua code in combinators, and I wanted to make use of some similar system again, because there is just a stupid amount of shiftings and definitions to be made.

To get all the shifting values, we are using a very similar system to what was described in FFF-202, special pictures from After Effects processed by python scripts. The only real difference is that now After Effects also has to import spritesheets of our existing entities and align them with the shifting values. Luckily, After Effects supports javascript based expressions which makes this work simpler.


This simple expression just lets me center the sprite and copy the X and Y shifting values from Lua, instead of having to worry about making calculations all the time, and it’s more readable when re-visiting and checking.

With the shifting values ready, the next step is to tell the game to accept them somehow. I wouldn’t dare to try overwriting all of the entries in entities.lua and similar files, simply because it would probably mean massive amount of errors, both by hand or somehow automatically.

So instead Michal (Posila) wrote a python script which generates a new circuit connector file where all of the specific definitions are kept, and refactored the entities so that each entity connectible to the circuit network just grabs the values from the master circuit connector file. Hopefully this makes it more maintainable for the future...

As one of the often used entities in the circuit network, the lamp is getting a high resolution version. The graphics are a work in progress so there will likely be some changes.



As always let us know what you think, just like you have been in the last 4 years (FFF-1) on our forum. We would like to thank you for all the attention and feedback through all this time, it’s really nice to be able to talk about our work, and sometimes even add something we forgot and you mentioned.

It’s been several weeks since we showed you the graphics for new high resolution circuit connector modules (FFF-202). However now is finally the time when we have them in the game. In this article I will briefly show you what was done both in the graphics and code, and what new benefits are there for you as players and modders.

I find the 0.15 version of the circuit connector module has following “problems”:

1. The wire connectors are different from the combinators.
2. Wires sometimes completely overlap, making only one of them properly visible.
3. Modularity - you can somewhat tell what is happening based on the LED states, but it could be much nicer.
4. Connecting a belt always looks weird, while the yellow structure which holds the connector box could be made more specific.
5. Some of the rotations are utterly useless.
6. The Lua definitions are spread over every single entity, so revisiting them all is a big pain.

We have been experimenting with the design of how the little pieces which connect to wires should look like. Most of them don’t really make sense in terms of physics, but visually the combinator ones seem to work pretty nicely in my opinion. That, and the circuit connector should be somewhat consistent with the combinators in this regard, so we just used the combinator design from when Albert made the combinators back in 2015 (FFF-88).



As we already tried to hint in FFF-202 (but we didn’t have a proper picture for it yet because the hr circuit connector wasn’t in the game yet), when you build entities vertically, they would very often only show one colour of wire.



To prevent this from happening, I took a pixel grid in Blender and I tried to always have the connectors far away from each other to prevent this from happening. The same issue happens with combinators, but let’s see if we ever have time to change that.



The system of drawing has slightly changed - now when you connect an entity, you can clearly recognize what it is doing and what is it's state. The rule is: Red/Green LED means write mode - generally stopping/starting the entity. Blue LED means reading mode - generally reading chest contents, reading signal colours, and so on.



If you only connect to the logistic network, even the wire connection points are going to disappear as you can see on the pump above.

Previously we were using the universal connector on belts, and to support it we made a special layer with a frame to hold it. This just uses another layer and generally looks rather weird.



We found it better to just make specific sprites for belts, which should integrate nicer and use less layers.



If you ever looked at how the circuit connector module spritesheet actually looks, you would have noticed that there are 32 rotations of it. For the first row, which is just flat on the ground, all of the 8 rotations are useful, but when the box starts tilting, the last three are looking away from the camera and are basically impossible to use.



At the same time, on some entities and in some cases it would be really cool to be able to just put the wire connection points at the opposite side of the box.

I put the two things together and made the impossible-to-use rotations just be a flipped version of the useful ones. The picture below is a mockup, the actual spritesheets have separate layers to allow the modularity mentioned above.



The game does not actually utilize all of the 32 rotations, but it’s easier to have them all for future new entities - importantly also new entities added by mods.

When the graphics were finished, I was looking at how could I put the connector in the game. We had good experience with generating the Lua code in combinators, and I wanted to make use of some similar system again, because there is just a stupid amount of shiftings and definitions to be made.

To get all the shifting values, we are using a very similar system to what was described in FFF-202, special pictures from After Effects processed by python scripts. The only real difference is that now After Effects also has to import spritesheets of our existing entities and align them with the shifting values. Luckily, After Effects supports javascript based expressions which makes this work simpler.


This simple expression just lets me center the sprite and copy the X and Y shifting values from Lua, instead of having to worry about making calculations all the time, and it’s more readable when re-visiting and checking.

With the shifting values ready, the next step is to tell the game to accept them somehow. I wouldn’t dare to try overwriting all of the entries in entities.lua and similar files, simply because it would probably mean massive amount of errors, both by hand or somehow automatically.

So instead Michal (Posila) wrote a python script which generates a new circuit connector file where all of the specific definitions are kept, and refactored the entities so that each entity connectible to the circuit network just grabs the values from the master circuit connector file. Hopefully this makes it more maintainable for the future...

As one of the often used entities in the circuit network, the lamp is getting a high resolution version. The graphics are a work in progress so there will likely be some changes.



As always let us know what you think, just like you have been in the last 4 years (FFF-1) on our forum. We would like to thank you for all the attention and feedback through all this time, it’s really nice to be able to talk about our work, and sometimes even add something we forgot and you mentioned.