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.

• Fixed that after a player reconnected after a desync, while blueprints were uploaded, the game would crash. more
  
• Fixed that in certain scenarios, the blueprint library wouldn't synchronise. more
  
• Fixed that the server would sometimes quit if a player tried to connect after another player tried to connect unsuccessfully. more
  
• Fixed a rare desync related to electric sub networks.
  
• Fixed archaic (from 0.12) migration that was supposed to fix rollingStockCounts on rails and it broke it instead.
  
• Fixed possible desync when rotating pipe to ground. more
  
• Fixed a rare possiblity of internal electric network crash when loading game. more
  
• Handle network errors (caused by LavasoftTcpService64.dll corrupting Winsock) gracefully. more
  

• Fixed changing force of underground belt entity would cause desync. more
  

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

• Fixed that after a player reconnected after a desync, while blueprints were uploaded, the game would crash. more
  
• Fixed that in certain scenarios, the blueprint library wouldn't synchronise. more
  
• Fixed that the server would sometimes quit if a player tried to connect after another player tried to connect unsuccessfully. more
  
• Fixed a rare desync related to electric sub networks.
  
• Fixed archaic (from 0.12) migration that was supposed to fix rollingStockCounts on rails and it broke it instead.
  
• Fixed possible desync when rotating pipe to ground. more
  
• Fixed a rare possiblity of internal electric network crash when loading game. more
  
• Handle network errors (caused by LavasoftTcpService64.dll corrupting Winsock) gracefully. more
  

• Fixed changing force of underground belt entity would cause desync. more
  

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

I need to make a confession.

I'm addicted.
Addicted to optimisation.
I earned some money by the game ... you know .. I could just .. I don't know .. play games and ... have some leisure time, but do you know what would be the problem? I would have to think about some Factorio optimisations I wanted to do anyway.

When I go to bed in the evening, I think about cache locality and data structures. I dream about ways to reorganize structures to minimize the amount of data needed to be read to perform Factorio logic. When I walk in the park, i visualize the tricks that could be done to decrease data and logic dependencies. This usually only stops when I see how many bugs need to be fixed after release when lot of changes are done.

The electric network optimisation for 0.16 was simple in principle. We currently have one continuous buffer of electric connector data stored in the electric network. It needs to be iterated twice (first for calculation, second for power distribution).



The change was to categorize energy connector data by the prototype:



It adds another layer of indirection when something needs to be added/removed from the network, but that happens quite rarely. The advantage is, that all the prototype specific values, like inputFlowLimit, outputFlowLimit etc. can be accessed once at the beginning of the processing of one category, which (together with other size squishing), results in a much smaller memory layout, which results in faster iteration of the algorithm.

The conclusion is that electric network transfers are more than twice as fast compared to 0.15.

Smoke already had the first iteration of optimisation 125 weeks ago. But Factorio is many times faster since than, so smoke started to appear in our profiling again.

The problem was that even creating the smoke object and registering it on the map was slowing the game down. The plan was to make something we internally call TrivialSmoke. The Trivial smoke data size is 32 bytes which is quite small compared to the previous "smoke as entity" size of 256 bytes. It contains only the most basic data squashed as much as possible, and it is stored in a continuous piece of memory on the chunk it was created.



As the updates happen in regular intervals (120 ticks), it is always guaranteed, that the smokes to be updated this tick are at the beginning of the buffer, I don't have to check the rest. The same buffer is used for update and for render, so these objects don't need any other references to it.

It is similar to the Chunk update planner mentioned in fff-161, just flattened.
The result is, as expected, that the smoke creation/update/removal times were significantly reduced.

The dilemma is, whether to use similar approach to the logistic bots as for the smoke. This would mean that logistic bots would be created/updated/removed very fast and their memory footprint would decrease a lot, but they wouldn't be regular entities any more. They couldn't be mined (which could be for the better actually), couldn't be attacked or damaged by anything (which again, would be welcomed by some players). I'm quite sure that it shouldn't apply for the construction robots, as they are more related to the fighting part of the game, but logistic robots aren't.

The dilemma is, whether changing the game rules like this just for optimisation isn't going too far.

I benchmarked a huge save of Vaclav (https://imgur.com/a/qDDs1), and it can already run 2.4 times faster in 0.16 compared to 0.15 so we met our "2 times faster release" quota,
but I'm afraid that this won't stop the addiction.

Almost all of the terrain has been updated for 0.16, which includes the high-res update of it. We will certainly cover the terrain/trees/decals improvements in future FFF. Here I would like to present the new version of the stone path terrain made by Ernestas. It is inspired (as many things in Factorio) by the eastern style of pavements, and I'm starting to be a fan of his work.



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

I need to make a confession.

I'm addicted.
Addicted to optimisation.
I earned some money by the game ... you know .. I could just .. I don't know .. play games and ... have some leisure time, but do you know what would be the problem? I would have to think about some Factorio optimisations I wanted to do anyway.

When I go to bed in the evening, I think about cache locality and data structures. I dream about ways to reorganize structures to minimize the amount of data needed to be read to perform Factorio logic. When I walk in the park, i visualize the tricks that could be done to decrease data and logic dependencies. This usually only stops when I see how many bugs need to be fixed after release when lot of changes are done.

The electric network optimisation for 0.16 was simple in principle. We currently have one continuous buffer of electric connector data stored in the electric network. It needs to be iterated twice (first for calculation, second for power distribution).



The change was to categorize energy connector data by the prototype:



It adds another layer of indirection when something needs to be added/removed from the network, but that happens quite rarely. The advantage is, that all the prototype specific values, like inputFlowLimit, outputFlowLimit etc. can be accessed once at the beginning of the processing of one category, which (together with other size squishing), results in a much smaller memory layout, which results in faster iteration of the algorithm.

The conclusion is that electric network transfers are more than twice as fast compared to 0.15.

Smoke already had the first iteration of optimisation 125 weeks ago. But Factorio is many times faster since than, so smoke started to appear in our profiling again.

The problem was that even creating the smoke object and registering it on the map was slowing the game down. The plan was to make something we internally call TrivialSmoke. The Trivial smoke data size is 32 bytes which is quite small compared to the previous "smoke as entity" size of 256 bytes. It contains only the most basic data squashed as much as possible, and it is stored in a continuous piece of memory on the chunk it was created.



As the updates happen in regular intervals (120 ticks), it is always guaranteed, that the smokes to be updated this tick are at the beginning of the buffer, I don't have to check the rest. The same buffer is used for update and for render, so these objects don't need any other references to it.

It is similar to the Chunk update planner mentioned in fff-161, just flattened.
The result is, as expected, that the smoke creation/update/removal times were significantly reduced.

The dilemma is, whether to use similar approach to the logistic bots as for the smoke. This would mean that logistic bots would be created/updated/removed very fast and their memory footprint would decrease a lot, but they wouldn't be regular entities any more. They couldn't be mined (which could be for the better actually), couldn't be attacked or damaged by anything (which again, would be welcomed by some players). I'm quite sure that it shouldn't apply for the construction robots, as they are more related to the fighting part of the game, but logistic robots aren't.

The dilemma is, whether changing the game rules like this just for optimisation isn't going too far.

I benchmarked a huge save of Vaclav (https://imgur.com/a/qDDs1), and it can already run 2.4 times faster in 0.16 compared to 0.15 so we met our "2 times faster release" quota,
but I'm afraid that this won't stop the addiction.

Almost all of the terrain has been updated for 0.16, which includes the high-res update of it. We will certainly cover the terrain/trees/decals improvements in future FFF. Here I would like to present the new version of the stone path terrain made by Ernestas. It is inspired (as many things in Factorio) by the eastern style of pavements, and I'm starting to be a fan of his work.



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

Hello, it's another Friday, so time for another Friday Facts.

As we were discussing the GUI/UX rewrite (which is going to be covered in detail in future FFF), we came across the crafting categories implementation. We have 4 in base game, but with few mods, it can go up to 20+ which is quite hard to manage in a GUI that is still practical and looks nice.

Making its own sub-category for transport belts and putting them there is (probably) fine, but if it is done this way (5dim code), it only moves the vanilla transports belts there. but if some other mod adds transport belts, they will still stay in the old category, making it all messy.


This is a typical situation, where the fact that our data definition is done in a scripting language can be taken advantage of. We can just replace the previous code by more generic variant.


The code goes through all the recipes and whenever its result is a transport belt, it is moved to the correct category. This way, all the possible other transport belts added by other mods will go there and my change of categories doesn't actually make more problems than it solves. This is a shoutout to the mod devs so they try to be reasonable with the crafting categories, so it doesn't happen that often that <something>-1, <something>-2, <something>-3 is on one place, but <something>-4 is somewhere else, just because it was introduced by a different mod. Either try to keep things in their official categories as long as possible, or recategorize properly.

The tips and tricks GUI is perhaps one of the greatest sources to teach players about some of the obscure convenience features we have added to the game over the years:

• Fast replacing furnaces, inserters, assembling machines etc.
• Copy-pasting entity information, recipes, schedules etc.
• How to turn on detailed view (alt-mode).
• The hotkeys for the quickbar.
• And the rest...

It is a shame then that this GUI is rarely read by the player, and this is our fault. It is easy to see the main reasons why:

• It is only shown at the start of a new game, when many of the tips are not relevant.
• Once it is closed, it cannot be reopened without starting a new game.
• Many of the tips are outdated, old, or just plain ugly.

So with this in mind, I set to correcting things as best I could. Since the tips and tricks have been in the game for a very long time, this involved moving some of the information around to make it work in multiplayer, but because they don't affect the gamestate, determinism was not a concern. After adding a hotkey to bring the tips back up, it feels very natural now to hit the hotkey on and off just to quickly check them. Another improvement I made was a button to go backwards through the tips, and to loop once you've reached the last one.

Then it comes to the visuals. The biggest flaw is that most of the images are out of date, and taken on differing terrains - many are not even the same size as the others. This not only affects the size of the GUI, but gives the unpolished feel to the whole system. The other issue is the layout of the widgets in the GUI. With an invaluable mock-up from Albert, defining the styles and arranging necessary elements wasn't too much of a struggle. So the main task now is to recapture and go over the images, and recreate them in a consistent visual style.



After freshening up the current tips, I will feel better about adding more, without the worry that "Nobody will ever read them". No doubt the GUI will still change, especially with the GUI rewrite in the works, so I wouldn't get too attached to the exact way it looks now.

Back in 2016 just before Steam launch, we didn't really have a good online guide for the game. We had the wiki but it was somewhat underdeveloped, and not geared towards a new player to the game. So the guide was the perfect resource for us, and it has served our newer players extremely well.

Unfortunately in the 18 months since Its introduction, a lot of the materials on the guide have become outdated. It would no doubt be a losing battle to try to keep it updated as we are continually adding and changing things in the game, so we have decided to take down the guide from public access. The wiki has received a lot of care from Gangsir and Bilka, and is a much better resource for players of all skill levels, so it is now our recommended destination.

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

Hello, it's another Friday, so time for another Friday Facts.

As we were discussing the GUI/UX rewrite (which is going to be covered in detail in future FFF), we came across the crafting categories implementation. We have 4 in base game, but with few mods, it can go up to 20+ which is quite hard to manage in a GUI that is still practical and looks nice.

Making its own sub-category for transport belts and putting them there is (probably) fine, but if it is done this way (5dim code), it only moves the vanilla transports belts there. but if some other mod adds transport belts, they will still stay in the old category, making it all messy.


This is a typical situation, where the fact that our data definition is done in a scripting language can be taken advantage of. We can just replace the previous code by more generic variant.


The code goes through all the recipes and whenever its result is a transport belt, it is moved to the correct category. This way, all the possible other transport belts added by other mods will go there and my change of categories doesn't actually make more problems than it solves. This is a shoutout to the mod devs so they try to be reasonable with the crafting categories, so it doesn't happen that often that <something>-1, <something>-2, <something>-3 is on one place, but <something>-4 is somewhere else, just because it was introduced by a different mod. Either try to keep things in their official categories as long as possible, or recategorize properly.

The tips and tricks GUI is perhaps one of the greatest sources to teach players about some of the obscure convenience features we have added to the game over the years:

• Fast replacing furnaces, inserters, assembling machines etc.
• Copy-pasting entity information, recipes, schedules etc.
• How to turn on detailed view (alt-mode).
• The hotkeys for the quickbar.
• And the rest...

It is a shame then that this GUI is rarely read by the player, and this is our fault. It is easy to see the main reasons why:

• It is only shown at the start of a new game, when many of the tips are not relevant.
• Once it is closed, it cannot be reopened without starting a new game.
• Many of the tips are outdated, old, or just plain ugly.

So with this in mind, I set to correcting things as best I could. Since the tips and tricks have been in the game for a very long time, this involved moving some of the information around to make it work in multiplayer, but because they don't affect the gamestate, determinism was not a concern. After adding a hotkey to bring the tips back up, it feels very natural now to hit the hotkey on and off just to quickly check them. Another improvement I made was a button to go backwards through the tips, and to loop once you've reached the last one.

Then it comes to the visuals. The biggest flaw is that most of the images are out of date, and taken on differing terrains - many are not even the same size as the others. This not only affects the size of the GUI, but gives the unpolished feel to the whole system. The other issue is the layout of the widgets in the GUI. With an invaluable mock-up from Albert, defining the styles and arranging necessary elements wasn't too much of a struggle. So the main task now is to recapture and go over the images, and recreate them in a consistent visual style.



After freshening up the current tips, I will feel better about adding more, without the worry that "Nobody will ever read them". No doubt the GUI will still change, especially with the GUI rewrite in the works, so I wouldn't get too attached to the exact way it looks now.

Back in 2016 just before Steam launch, we didn't really have a good online guide for the game. We had the wiki but it was somewhat underdeveloped, and not geared towards a new player to the game. So the guide was the perfect resource for us, and it has served our newer players extremely well.

Unfortunately in the 18 months since Its introduction, a lot of the materials on the guide have become outdated. It would no doubt be a losing battle to try to keep it updated as we are continually adding and changing things in the game, so we have decided to take down the guide from public access. The wiki has received a lot of care from Gangsir and Bilka, and is a much better resource for players of all skill levels, so it is now our recommended destination.

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