Hello, it is Friday once again.

To make PvP fun, and fair, it is pretty important that all the teams have a fair start. We do this for the normal game by using some special logic to generate a specific starting area. While the map generation didn't support this, I worked around the issue by copy-pasting all the starting area chunks to new starting areas for all players. This looked very odd though, and since it was done in the Lua script, was very slow.



So the solution is to fix the map generator to create multiple starting points, which with all the refactoring work by TOGoS, was not so hard to do. Whereas before all the logic calculated its own 'distance from the start' from (0,0), now it looks for the closest starting area, and calculates the distance from that. This actually fixes and simplifies a lot of the PvP script, as I also don't have to worry about clearing away huge biters nests from each teams front door.



This is a much cleaner solution, as the new starting areas are seamlessly integrated into the map.

We were always saying, that we keep the full update multithreading as the last ace in the sleeve to be used after the normal optimisations become too difficult. Apart from the plan to split update into chunks and update them separately, there are also smaller and simpler things we can do.
We have for example this part of the update step, where we update trains, electric network and belts, and we update it one after another like this:



But these tasks are almost independent as neither trains or belts use electricity and belts don't interact with trains. There would be some details that would have to be solved, like Lua API calls and inserter activation order, but other than that it would be pretty straightforward. So I tried to run these things in parallel and measured how fast it would be:



To my surprise, the parallel version didn't speed things up, it was actually even slower. First I thought that it is caused by the fact, that the threads steal each others cache or the task is too short to be parallelized etc., but then I realized, that we already do the "prepare logic" in parallel. The prepare logic gathers all the data (sprite draw orders) for rendering and it is doing in parallel up to 8 threads. The task is iterating through the game world, and it is also quite short. Yet still the parallelization works pretty well there. After a few days (and many cppcon videos about multithreading later), I got the answer to my question. The answer is the same as many other answers related to performance, it is caused by cache invalidation.

There is some shared cache for all the threads (L3 I believe), and some smaller caches specific for each of the cores (L2 and L1 I believe). The cache is divided into some kind of pages. The problem is that as long as I don't control the memory allocation, the data of 3 objects that might be completely independent can end up in the same page of memory cache. So lets imagine this situation:



Even if two different cores work with the same part of memory, they don't slow each other down as long as they only read the memory (Which is the case of our prepare logic as it is read only operation) as each core has its own copy of the memory page. The problem arises when the operation is not read only:



Each thread has its own copy of the page, but whenever something is changed, the other copies of the same page need to be invalidated and updated. This means that the threads are invalidating each others cache all the time, which slows the whole process so much that it is slower than the non-parallel solution.

How do we solve it? The solution would probably be to organize the memory allocation in such a way, that everything that is on the same chunk, or related to some specific task would have to use its own memory allocator that keeps things in one place together in the memory. Every chunk would have its own piece of memory dedicated to entities in the chunk, trains would have all its data in one piece of memory together etc. This way, it shouldn't happen that two tasks would work on one piece of memory at the same time so the multithreading would actually speed things up.

The problem with this is, that it requires big changes in the code as not only the entities itself but all their dynamically allocated data would have to be always allocated depending on the entity position. Whenever the entity moves between chunks, all its data structures would have to be re-allocated in the new chunk. All pointers to any data structures in entity would have to be properly updated as they move around etc. This means, that once (if) we decide to do this step, it would probably be one big update related only to this and this is not something we have time to do before 1.0.

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

Hello, it is Friday once again.

To make PvP fun, and fair, it is pretty important that all the teams have a fair start. We do this for the normal game by using some special logic to generate a specific starting area. While the map generation didn't support this, I worked around the issue by copy-pasting all the starting area chunks to new starting areas for all players. This looked very odd though, and since it was done in the Lua script, was very slow.



So the solution is to fix the map generator to create multiple starting points, which with all the refactoring work by TOGoS, was not so hard to do. Whereas before all the logic calculated its own 'distance from the start' from (0,0), now it looks for the closest starting area, and calculates the distance from that. This actually fixes and simplifies a lot of the PvP script, as I also don't have to worry about clearing away huge biters nests from each teams front door.



This is a much cleaner solution, as the new starting areas are seamlessly integrated into the map.

We were always saying, that we keep the full update multithreading as the last ace in the sleeve to be used after the normal optimisations become too difficult. Apart from the plan to split update into chunks and update them separately, there are also smaller and simpler things we can do.
We have for example this part of the update step, where we update trains, electric network and belts, and we update it one after another like this:



But these tasks are almost independent as neither trains or belts use electricity and belts don't interact with trains. There would be some details that would have to be solved, like Lua API calls and inserter activation order, but other than that it would be pretty straightforward. So I tried to run these things in parallel and measured how fast it would be:



To my surprise, the parallel version didn't speed things up, it was actually even slower. First I thought that it is caused by the fact, that the threads steal each others cache or the task is too short to be parallelized etc., but then I realized, that we already do the "prepare logic" in parallel. The prepare logic gathers all the data (sprite draw orders) for rendering and it is doing in parallel up to 8 threads. The task is iterating through the game world, and it is also quite short. Yet still the parallelization works pretty well there. After a few days (and many cppcon videos about multithreading later), I got the answer to my question. The answer is the same as many other answers related to performance, it is caused by cache invalidation.

There is some shared cache for all the threads (L3 I believe), and some smaller caches specific for each of the cores (L2 and L1 I believe). The cache is divided into some kind of pages. The problem is that as long as I don't control the memory allocation, the data of 3 objects that might be completely independent can end up in the same page of memory cache. So lets imagine this situation:



Even if two different cores work with the same part of memory, they don't slow each other down as long as they only read the memory (Which is the case of our prepare logic as it is read only operation) as each core has its own copy of the memory page. The problem arises when the operation is not read only:



Each thread has its own copy of the page, but whenever something is changed, the other copies of the same page need to be invalidated and updated. This means that the threads are invalidating each others cache all the time, which slows the whole process so much that it is slower than the non-parallel solution.

How do we solve it? The solution would probably be to organize the memory allocation in such a way, that everything that is on the same chunk, or related to some specific task would have to use its own memory allocator that keeps things in one place together in the memory. Every chunk would have its own piece of memory dedicated to entities in the chunk, trains would have all its data in one piece of memory together etc. This way, it shouldn't happen that two tasks would work on one piece of memory at the same time so the multithreading would actually speed things up.

The problem with this is, that it requires big changes in the code as not only the entities itself but all their dynamically allocated data would have to be always allocated depending on the entity position. Whenever the entity moves between chunks, all its data structures would have to be re-allocated in the new chunk. All pointers to any data structures in entity would have to be properly updated as they move around etc. This means, that once (if) we decide to do this step, it would probably be one big update related only to this and this is not something we have time to do before 1.0.

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

Hello, there has been an illness running around the office this week, so productivity has been down. Regardless, it is still friday, so here are the Factorio Facts.

It seems concrete became the main ground texture of most megabases, which is something we didn’t expect when we added the stone and concrete 'paths' a few updates back. Since we are remastering all sprites into high resolution, we decided to redesign concrete to fix some issues we have with it:

• It has a visible grid that doesn’t match the tilted projection of the game.
• It doesn’t seem to have any height.
• Hazard concrete transition to concrete is very sharp which makes it look too artificial.

When drawing terrain, we try to hide the fact it is composed of repeated square tiles. For this reason we use various tile sizes, where bigger tiles can have some larger features that wouldn’t fit onto a smaller one. This solution was not good enough for concrete rendering any more.

We were inspired by an article about detail textures, and decided to try to draw concrete in two layers - material and detail. The idea was that we would create a larger material texture that would be laid out in a regular grid under the whole world, and we would cut out the shape of the concrete placed over it. Then on top of the material, we would add some detail defined in our regular 1x1, 2x2 and 4x4 tile sprites.

We experimented with this and liked the freedom from having to create 32 by 32 pixel sprites that need to tile with each other. For other terrain types we use prerendered transition sprites on border between two terrains, but because of the material layer, we needed to render transitions at run-time. To finish this up, we needed to add alpha masking to our rendering capabilities. The alpha mask is a greyscale or single channel image which is multiplied with the actual texture, so that a pixel in the texture becomes more transparent the darker the corresponding pixel in the mask is. Now that we have this capability we can replace the prerendered transitions with masks, that are shared by multiple terrains, so we will save some video memory. This will be big deal when we do transition from any tile type to water.



In 0.15 we made a change that merged concrete and hazard concrete transitions to other terrains. Initially hazard concrete had its own graphic for the transitions, but the algorithm that was drawing them produced flawed results in some edge cases, so we decided to use the same transition graphic as normal concrete does.

To fix the flaws of the original drawing algorithm, we render transitions in two passes. First we resolve transitions as if all hazard concrete was regular concrete, then we render transitions just for the hazard concrete. This also allows us to create irregular edges between hazard and normal concrete. In the end we didn’t use normal tile sprites to add any additional detail, but we used normal (non-masked) transition sprites to add a border from the concrete bricks. The following GIF illustrates how individual layers are added together.



In some way it's a pity that we decided to tackle the concrete last, as we could of used this functionality for all the other terrains. The final result is a much better and easier system to work with, and will allow the artists to create the best art without worrying about the technical considerations too much.



These improvements lead to other ideas to improve our graphics rendering, and a lot of difficult issues are still left to be resolved, so let us know what you think on our forum.

Hello, there has been an illness running around the office this week, so productivity has been down. Regardless, it is still friday, so here are the Factorio Facts.

It seems concrete became the main ground texture of most megabases, which is something we didn’t expect when we added the stone and concrete 'paths' a few updates back. Since we are remastering all sprites into high resolution, we decided to redesign concrete to fix some issues we have with it:

• It has a visible grid that doesn’t match the tilted projection of the game.
• It doesn’t seem to have any height.
• Hazard concrete transition to concrete is very sharp which makes it look too artificial.

When drawing terrain, we try to hide the fact it is composed of repeated square tiles. For this reason we use various tile sizes, where bigger tiles can have some larger features that wouldn’t fit onto a smaller one. This solution was not good enough for concrete rendering any more.

We were inspired by an article about detail textures, and decided to try to draw concrete in two layers - material and detail. The idea was that we would create a larger material texture that would be laid out in a regular grid under the whole world, and we would cut out the shape of the concrete placed over it. Then on top of the material, we would add some detail defined in our regular 1x1, 2x2 and 4x4 tile sprites.

We experimented with this and liked the freedom from having to create 32 by 32 pixel sprites that need to tile with each other. For other terrain types we use prerendered transition sprites on border between two terrains, but because of the material layer, we needed to render transitions at run-time. To finish this up, we needed to add alpha masking to our rendering capabilities. The alpha mask is a greyscale or single channel image which is multiplied with the actual texture, so that a pixel in the texture becomes more transparent the darker the corresponding pixel in the mask is. Now that we have this capability we can replace the prerendered transitions with masks, that are shared by multiple terrains, so we will save some video memory. This will be big deal when we do transition from any tile type to water.



In 0.15 we made a change that merged concrete and hazard concrete transitions to other terrains. Initially hazard concrete had its own graphic for the transitions, but the algorithm that was drawing them produced flawed results in some edge cases, so we decided to use the same transition graphic as normal concrete does.

To fix the flaws of the original drawing algorithm, we render transitions in two passes. First we resolve transitions as if all hazard concrete was regular concrete, then we render transitions just for the hazard concrete. This also allows us to create irregular edges between hazard and normal concrete. In the end we didn’t use normal tile sprites to add any additional detail, but we used normal (non-masked) transition sprites to add a border from the concrete bricks. The following GIF illustrates how individual layers are added together.



In some way it's a pity that we decided to tackle the concrete last, as we could of used this functionality for all the other terrains. The final result is a much better and easier system to work with, and will allow the artists to create the best art without worrying about the technical considerations too much.



These improvements lead to other ideas to improve our graphics rendering, and a lot of difficult issues are still left to be resolved, so let us know what you think on our forum.

Hello, we are still here, working on the game.

As we were going through and polishing some of the mini-tutorials, we hit a bit of a problem. We wanted to introduce a new concept to the player, but we don't enforce or encourage any order to the tutorials. This means a player might start the ghost rail tutorial before he knows what ghosts are, or play the rail signal tutorial before he knows how to use the trains.

The solution is to add dependencies to the tutorials, so we recommend to the player, "You should play this tutorial before another".



Another advantage of this is that it sorts the tutorials better. Now suggested or unplayed tutorials will show at the top of the list, tutorials with missing dependencies will show in the middle, and complete tutorials will be at the bottom. From a tutorial design standpoint it makes things a lot easier. I can make safe assumptions about what skills the player has, and not have to worry about re-teaching the basics in every tutorial 'just in case'.

Logistic chest pasting is a great quality of life feature when setting up 'shopping malls' with logistic bots. Drop a assembling machine and requester chest, set the recipe, then copy-paste from the assembler to the requester chest. The design question is how much should the logistic chest request? Quick recipes like electronic circuits need a lot of materials to avoid idle time, while items that are slow to craft, like modules, can result in a lot of materials sitting idle in the chest. This creates a lot cases where the pasted amounts needed to be adjusted manually.

One of our community contributors, Mylon, designed a new system, which is now integrated into 0.16. The system scales the count of requested items to the crafting time of the recipe, and to the speed of the specific assembling machine. It aims to keep the chest supplied with 30 seconds of crafting ingredients. So notice in this example how the amounts varying between the machines being pasted from:



Adding modules and beacons to a design and then repeating the copy paste will recalculate the requested amounts, whereas before the amounts would need to be modified by hand. We still have a prototype defined recipe paste multiplier for very expensive items, like Nuclear reactors and Satellites, but overall this new system will be much more flexible, and deal with most of the annoying cases.

"Is the thing in the cursor buildable where it is behind held?". It sounds simple at first, but as the game has advanced it has quickly become anything but. Not all entities have the same buildability rules:

• Gates can be built on rails - but not all rails.
• Mining drills can only be built on the correct ore type.
• Rail signals can only be built next to rails.
• Offshore pumps can only be built at the edge of water and land.

To complicate things even more the rules change when building ghosts:

• Other entities are ignored if they're marked for deconstruction.
• Signals can be built anywhere instead of only next to rails.
• Ghosts ignore ghosts of other forces.
• Tile ghosts can't be built on tiles of the same type (it wouldn't do anything).

When shift clicking blueprints:

• Trees and rocks are ignored - since they will be marked for deconstruction if they are in the way.
• Anything that can't be built is just ignored in the blueprint.

There are so many special cases and so many combinations of when things can and can't be built (or can be ignored when building) that I've probably missed a few of them here. Something that has been missing for some time now has been making all of these variations render correctly in the preview you see before you build something.

A simple example is when holding a blueprint over a patch of ore with shift held down. Any trees and rocks in the way will be marked for deconstruction, and the ghosts will be placed. In 0.15 the preview would not be updated, so the drills would show as red. Now in 0.16 they rendered correctly:



It's a very small thing, but one more thing that when it 'just works', it makes the overall experience that much better, after all, perfection is just doing a lot of little things right.

As always, if you have any suggestions or ideas, please let us know on our forums.

Hello, we are still here, working on the game.

As we were going through and polishing some of the mini-tutorials, we hit a bit of a problem. We wanted to introduce a new concept to the player, but we don't enforce or encourage any order to the tutorials. This means a player might start the ghost rail tutorial before he knows what ghosts are, or play the rail signal tutorial before he knows how to use the trains.

The solution is to add dependencies to the tutorials, so we recommend to the player, "You should play this tutorial before another".



Another advantage of this is that it sorts the tutorials better. Now suggested or unplayed tutorials will show at the top of the list, tutorials with missing dependencies will show in the middle, and complete tutorials will be at the bottom. From a tutorial design standpoint it makes things a lot easier. I can make safe assumptions about what skills the player has, and not have to worry about re-teaching the basics in every tutorial 'just in case'.

Logistic chest pasting is a great quality of life feature when setting up 'shopping malls' with logistic bots. Drop a assembling machine and requester chest, set the recipe, then copy-paste from the assembler to the requester chest. The design question is how much should the logistic chest request? Quick recipes like electronic circuits need a lot of materials to avoid idle time, while items that are slow to craft, like modules, can result in a lot of materials sitting idle in the chest. This creates a lot cases where the pasted amounts needed to be adjusted manually.

One of our community contributors, Mylon, designed a new system, which is now integrated into 0.16. The system scales the count of requested items to the crafting time of the recipe, and to the speed of the specific assembling machine. It aims to keep the chest supplied with 30 seconds of crafting ingredients. So notice in this example how the amounts varying between the machines being pasted from:



Adding modules and beacons to a design and then repeating the copy paste will recalculate the requested amounts, whereas before the amounts would need to be modified by hand. We still have a prototype defined recipe paste multiplier for very expensive items, like Nuclear reactors and Satellites, but overall this new system will be much more flexible, and deal with most of the annoying cases.

"Is the thing in the cursor buildable where it is behind held?". It sounds simple at first, but as the game has advanced it has quickly become anything but. Not all entities have the same buildability rules:

• Gates can be built on rails - but not all rails.
• Mining drills can only be built on the correct ore type.
• Rail signals can only be built next to rails.
• Offshore pumps can only be built at the edge of water and land.

To complicate things even more the rules change when building ghosts:

• Other entities are ignored if they're marked for deconstruction.
• Signals can be built anywhere instead of only next to rails.
• Ghosts ignore ghosts of other forces.
• Tile ghosts can't be built on tiles of the same type (it wouldn't do anything).

When shift clicking blueprints:

• Trees and rocks are ignored - since they will be marked for deconstruction if they are in the way.
• Anything that can't be built is just ignored in the blueprint.

There are so many special cases and so many combinations of when things can and can't be built (or can be ignored when building) that I've probably missed a few of them here. Something that has been missing for some time now has been making all of these variations render correctly in the preview you see before you build something.

A simple example is when holding a blueprint over a patch of ore with shift held down. Any trees and rocks in the way will be marked for deconstruction, and the ghosts will be placed. In 0.15 the preview would not be updated, so the drills would show as red. Now in 0.16 they rendered correctly:



It's a very small thing, but one more thing that when it 'just works', it makes the overall experience that much better, after all, perfection is just doing a lot of little things right.

As always, if you have any suggestions or ideas, please let us know on our forums.

• 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.