Hello, on Thursday we received a belated Christmas package from our friends over at Steam:



They definitely won't be lasting long :-).
As you may know, one of the foundational blocks of the Factorio engine is Allegro. In fact, it has been part of the game since the very first commit! It is a library for handling all sorts of platform interaction, like creating windows, sound playback, handling input, and graphics rendering. Over the course of the last 5 years, we have hacked a lot of custom enhancements and optimizations into Allegro.

Since it is a library with a long history, Allegro copes with a lot of legacy hardware that we don't really have to worry about, which makes it hard to expand and build upon. We also have to deal with a lot of technical issues and driver problems due to the old graphics API that Allegro uses (DirectX 9 & OpenGL 1.2). This has ultimately become a real issue for us and we decided it was time to part with it. The plan is replace the graphics engine with our own code, and leave window management, event handling, and input, to SDL.

We hope that using SDL will result in fewer technical issues, better support for multiple platforms, and greater overall stability. Further down the line we can also explore supporting different input methods, such as gamepads and touch-interfaces.

Allegro has sneaked it's way into a huge portion of our codebase, so for the past few months, I have been removing Allegro from as many places as I could, and I've replaced some of its functionality with our own code. I've managed to reduce the number of places we call into Allegro by roughly 50%, and now has come the time to start working on the graphics engine.

So a month ago, HanziQ and I have started on a long and painful journey of replacing the Allegro rendering completely. There is not really a better way to do this than to just rip the band-aid off, so we removed all Allegro rendering and started writing our own from scratch. We are using OpenGL 3.2 for now, but DirectX 11 support is definitely coming before we release it.

We are obviously very good at it and encountered no problems whatsoever.



The whole process was smooth sailing from the get-go.



In fact, it was so easy, that we even had time to unwind with some controlled substances.



Right now, we've got the game back to rendering almost everything properly, and within a few weeks it should be just the same as the Allegro rendering. From this we can start building out our own feature set designed around what we need, and do more advanced work. For instance, DirectX 11 allows us to use a new shader model which has a higher instruction count limit, which will let us do more complex and interesting things with shaders. The more modern API's also have much better developer tools for diagnostics and debugging.

There are a lot of other possibilities moving forward with our own rendering engine, and it is a good step towards the long term viability of the 'Factorio engine'.

Jitka has arrived back from her vacation this week, so we have now re-opened the t-shirt shop. Orders will be sent out every Wednesday as before.

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

Hello, on Thursday we received a belated Christmas package from our friends over at Steam:



They definitely won't be lasting long :-).
As you may know, one of the foundational blocks of the Factorio engine is Allegro. In fact, it has been part of the game since the very first commit! It is a library for handling all sorts of platform interaction, like creating windows, sound playback, handling input, and graphics rendering. Over the course of the last 5 years, we have hacked a lot of custom enhancements and optimizations into Allegro.

Since it is a library with a long history, Allegro copes with a lot of legacy hardware that we don't really have to worry about, which makes it hard to expand and build upon. We also have to deal with a lot of technical issues and driver problems due to the old graphics API that Allegro uses (DirectX 9 & OpenGL 1.2). This has ultimately become a real issue for us and we decided it was time to part with it. The plan is replace the graphics engine with our own code, and leave window management, event handling, and input, to SDL.

We hope that using SDL will result in fewer technical issues, better support for multiple platforms, and greater overall stability. Further down the line we can also explore supporting different input methods, such as gamepads and touch-interfaces.

Allegro has sneaked it's way into a huge portion of our codebase, so for the past few months, I have been removing Allegro from as many places as I could, and I've replaced some of its functionality with our own code. I've managed to reduce the number of places we call into Allegro by roughly 50%, and now has come the time to start working on the graphics engine.

So a month ago, HanziQ and I have started on a long and painful journey of replacing the Allegro rendering completely. There is not really a better way to do this than to just rip the band-aid off, so we removed all Allegro rendering and started writing our own from scratch. We are using OpenGL 3.2 for now, but DirectX 11 support is definitely coming before we release it.

We are obviously very good at it and encountered no problems whatsoever.



The whole process was smooth sailing from the get-go.



In fact, it was so easy, that we even had time to unwind with some controlled substances.



Right now, we've got the game back to rendering almost everything properly, and within a few weeks it should be just the same as the Allegro rendering. From this we can start building out our own feature set designed around what we need, and do more advanced work. For instance, DirectX 11 allows us to use a new shader model which has a higher instruction count limit, which will let us do more complex and interesting things with shaders. The more modern API's also have much better developer tools for diagnostics and debugging.

There are a lot of other possibilities moving forward with our own rendering engine, and it is a good step towards the long term viability of the 'Factorio engine'.

Jitka has arrived back from her vacation this week, so we have now re-opened the t-shirt shop. Orders will be sent out every Wednesday as before.

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

• When the game crashes, the crash log is uploaded to us. You can opt out by disabling it in the options menu.
  
• Player chat color when set through '/color r g b a' command will be brightened. more
  

• Fixed that LuaEntity::get_merged_signals() would return wrong value if no wires were connected. more
  
• Fixed flamethrower turret could get stuck in deactivated state when fluid type in its pipe changed. more
  
• Fixed energy consumption of laser turret in recipe tooltip. more
  
• Fixed that specifying a shift for a storage tank's fluid_background would shift it incorrectly. more
  
• Fixed that ctrl-arrow/backspace/delete worked in the console but not in other text boxes. more
  
• Fixed that you could define a fluidbox height of 0. more
  
• Fixed trains "twitching" under certain circumstances. more
  
• Fixed wrong hairy dead tree graphics positioning. more
  
• Fixed that ping-pong DNS lookup failure would shut down running multiplayer games. more
  
• Fixed LuaInventory::getbar/setbar used zero-based indexing. more
  
• Fixed incorrect electric network connection rendering on the map. more
  
• Fixed train would reset its "waiting on signal" penalty when recalculating path due to waiting too long. more
  

• Added script.on_nth_tick(n, function).
  
• Added LuaSurface::can_place_entity(...) optional parameter "build_check_type" and "forced".
  

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

• When the game crashes, the crash log is uploaded to us. You can opt out by disabling it in the options menu.
  
• Player chat color when set through '/color r g b a' command will be brightened. more
  

• Fixed that LuaEntity::get_merged_signals() would return wrong value if no wires were connected. more
  
• Fixed flamethrower turret could get stuck in deactivated state when fluid type in its pipe changed. more
  
• Fixed energy consumption of laser turret in recipe tooltip. more
  
• Fixed that specifying a shift for a storage tank's fluid_background would shift it incorrectly. more
  
• Fixed that ctrl-arrow/backspace/delete worked in the console but not in other text boxes. more
  
• Fixed that you could define a fluidbox height of 0. more
  
• Fixed trains "twitching" under certain circumstances. more
  
• Fixed wrong hairy dead tree graphics positioning. more
  
• Fixed that ping-pong DNS lookup failure would shut down running multiplayer games. more
  
• Fixed LuaInventory::getbar/setbar used zero-based indexing. more
  
• Fixed incorrect electric network connection rendering on the map. more
  
• Fixed train would reset its "waiting on signal" penalty when recalculating path due to waiting too long. more
  

• Added script.on_nth_tick(n, function).
  
• Added LuaSurface::can_place_entity(...) optional parameter "build_check_type" and "forced".
  

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

• Lamps stagger again during day/night transition. They also turn on much sooner and turn off much later.
  
• The deconstruction planner "trees/rocks only" option can be inverted using the whitelist/blacklist toggle.
  
• The Rocket silo entity info now shows 'Rocket parts: 50/100'.
  
• Removed 'starting inventory' PvP option, as starting chests are a more proper solution.
  
• Added 'required satellites sent' option to space race PvP game mode
  

• Fixed snapping locomotive to station sometimes not working. more
  
• Fixed modded loaders with different dimensions crashing when destroyed. more
  
• Fixed that module effects would go negative when adding too many beacon effects together. more
  
• Fixed that changing an assembling machine recipe by copy-paste would delete the in-progress recipe items. more
  
• Fixed that directly replacing modules didn't work correctly. more
  
• Fixed that changing train stop names wouldn't update the last-user. more
  
• Fixed that the logistic count tooltip wouldn't show correctly for negative values. more
  
• Fixed that changing the stack size of the satellite through mods could make it impossible to win. more
  
• Fixed circuit controlled stack override sometimes being incorrect. more
  
• Fixed that mods could specify invalid categories, for a few classes of modded item. more
  
• Fixed pipette tool orientation of curved tracks. more
  
• Fixed that beacons would ignore the allowed effects on an entity. more
  
• Fixed that rail ghosts weren't placeable on top of enemy force's land mines, thus revealing the location of the mines. more
  
• Fixed Lua module limitations array being a map of strings to numbers, instead of an array. more
  
• Fixed that the market GUI wouldn't use a scroll bar even when the offers didn't fit in the window. more
  
• Fixed worker robot speed in PvP scenario. more
  
• Fixed that the blueprint preview in the blueprint library was smaller than the blueprint view you get after opening a blueprint item. more
  
• Fixed that the technology search would be broken by disabled technologies in some cases. more
  
• Fixed that mods changing stack sizes would break the inventory transfers tutorial. more
  
• Power switch copper wire connections are now saved in the ghost when destroyed and restored when rebuilt. more
  
• Fixed LuaSurface::regenerate_decoratives() would generate much more decoratives than normal map generator run. more
  
• Fixed clicking the label in sort-able tables wouldn't effect sorting. more
  
• Fixed that recipe tooltip labels would render outside of the tooltip area in some cases. more
  
• Fixed clamp_position=true on artillery shells would negate artillery range bonus. more
  
• Fixed item icon would not be rescaled to normal size if icon_size not 32. more
  

• Added "friend" and "not-friend" force trigger modifiers.
  
• Added optional night vision equipment prototype "darkness_to_turn_on".
  

• Added LuaGameScript::ammo_category_prototypes read.
  
• Added LuaEntity::get_merged_signals().
  

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

• Lamps stagger again during day/night transition. They also turn on much sooner and turn off much later.
  
• The deconstruction planner "trees/rocks only" option can be inverted using the whitelist/blacklist toggle.
  
• The Rocket silo entity info now shows 'Rocket parts: 50/100'.
  
• Removed 'starting inventory' PvP option, as starting chests are a more proper solution.
  
• Added 'required satellites sent' option to space race PvP game mode
  

• Fixed snapping locomotive to station sometimes not working. more
  
• Fixed modded loaders with different dimensions crashing when destroyed. more
  
• Fixed that module effects would go negative when adding too many beacon effects together. more
  
• Fixed that changing an assembling machine recipe by copy-paste would delete the in-progress recipe items. more
  
• Fixed that directly replacing modules didn't work correctly. more
  
• Fixed that changing train stop names wouldn't update the last-user. more
  
• Fixed that the logistic count tooltip wouldn't show correctly for negative values. more
  
• Fixed that changing the stack size of the satellite through mods could make it impossible to win. more
  
• Fixed circuit controlled stack override sometimes being incorrect. more
  
• Fixed that mods could specify invalid categories, for a few classes of modded item. more
  
• Fixed pipette tool orientation of curved tracks. more
  
• Fixed that beacons would ignore the allowed effects on an entity. more
  
• Fixed that rail ghosts weren't placeable on top of enemy force's land mines, thus revealing the location of the mines. more
  
• Fixed Lua module limitations array being a map of strings to numbers, instead of an array. more
  
• Fixed that the market GUI wouldn't use a scroll bar even when the offers didn't fit in the window. more
  
• Fixed worker robot speed in PvP scenario. more
  
• Fixed that the blueprint preview in the blueprint library was smaller than the blueprint view you get after opening a blueprint item. more
  
• Fixed that the technology search would be broken by disabled technologies in some cases. more
  
• Fixed that mods changing stack sizes would break the inventory transfers tutorial. more
  
• Power switch copper wire connections are now saved in the ghost when destroyed and restored when rebuilt. more
  
• Fixed LuaSurface::regenerate_decoratives() would generate much more decoratives than normal map generator run. more
  
• Fixed clicking the label in sort-able tables wouldn't effect sorting. more
  
• Fixed that recipe tooltip labels would render outside of the tooltip area in some cases. more
  
• Fixed clamp_position=true on artillery shells would negate artillery range bonus. more
  
• Fixed item icon would not be rescaled to normal size if icon_size not 32. more
  

• Added "friend" and "not-friend" force trigger modifiers.
  
• Added optional night vision equipment prototype "darkness_to_turn_on".
  

• Added LuaGameScript::ammo_category_prototypes read.
  
• Added LuaEntity::get_merged_signals().
  

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

After a long 14 hour flight back, Albert, kovarex and I arrived back from Taipei, after our attendance at the Taipei Game Show. Jitka started her vacation by staying there to visit the Taiwan island.
We stayed there for 7 days (2 days in the business area, 3 days in the convention area and 2 days of free time where we visited the city).

In the business area we met many potential business partners and got way too many business cards. We made some friends among the other indie developers and tried all kinds of fun, weird, interesting and some bad indie games.

The convention area was very crowded, with 350,000 visitors slowly trying to make their way through the fairly small convention hall. I can't speak for the others, but I still enjoyed myself. Even though it was crowded, most of the games were in Chinese, and I only got to try one AAA game, there is something about being surrounded by games, gamers, and game developers that makes me feel great.
Our booth was in the indie area. We had many people coming to try the game but also many fans wanting to speak with us and congratulate us for making a great game. AndrewIRL who lived there for a few years, invited us for dinner to "the best restaurant in the city", and we were not disappointed.

Factorio is not an easy game to demo, since it takes at least 30 minutes to kind of understand what the game is about. But having the trailers looping on the screen, and having subtitles for the gameplay trailer meant that the people got a fair idea about what the game is about and how complex it is. While not the best, we had people start by playing the campaign. Most of them were leaving after the first level but some of them were also getting addicted and playing for multiple hours. We gave free Steam keys to some of the people who were more engaged with the game. It was a learning experience to see people play the game for the first time and to see the most common problems with the campaign, the interaction, the UI and the Traditional Chinese translation.

The days were super exhausting though, many of us collapsing at the accommodation and sleeping for 10 hours. Luckily we had 2 more days to relax and enjoy the city before flying back. We mostly split up and each of us visited what they were most interested in, with me going through the electronics markets and riding a rented bike through the rainy streets.

To give credit where credit is due, I'd like to thank the game show for inviting us and sponsoring our booths, and Razer for conveniently lending us the laptops we used to demo the game.
Financially there is no point in us going to a game show, our attendance did not bring us any extra sales in Asia, as expected. The point of going there, for us, is to visit the show floor, play and see random games, make gamer friends, meet fellow developers, meet big fans of the game and maybe make some business partners.
Since many of you mentioned PAX and some of us are interested in going there, we are trying to see if we can attend PAX East this year (April 5-8th). So you might have another opportunity to come and take selfies with some of the Factorio devs.


From left to right: Jitka, Albert, Twinsen, kovarex.

It was always a nice aesthetic touch, and we have had it for a long while, but during the most recent 0.16 one small feature has been absent. That is of course, the lamp staggering: During the day/night transition, lamps will turn on and off and different times. For example, this is how it looked it 0.15:



During the development of 0.16, there was a move by kovarex to optimize the lamps. By all means the optimization was a success, but along the way the lamp staggering was removed. This didn't go unnoticed, but a proper solution was quite tough. A simple way we tried (even in the first 0.16 release) was to just visually turn the lamps on at different times. It looked the part, but unfortunately was technically incorrect, as the lamps would look 'on', but not actually consume any electric power until the required darkness at which point they all started consuming power.

Due to its incorrectness, this visuals-only solution was reverted, so for most of 0.16 this is what it looks like:



It is also obvious in this GIF, that they turn on way too late, it is already very dark before they turn on.

So anyway, there is a problem here, in that we want the lamps to turn on 'correctly', but it needs to not basically undo all the optimization. To give a brief summary of the optimization, the lamps no longer have to update themselves, the electric network just knows how many lamps there are. When it gets dark enough, the electric network knows that all the lamps will turn on, so just multiplies the consumption of the lamp by how many there are. This is similar to the solar panel and accumulator optimization. To work correctly, the rendering of the lamp, and the electric network update, have to know exactly when a lamp will be turned on, without being able to share any information with each other.

So first we define two values, how dark is it when they start turning on, and how dark it is when they should all be turned on. This gives us a darkness interval where the staggering will take place. Then when a lamp is built, we assign it a specific time in this interval at which it will turn on, and then also keep that value in a list in the electric network. This way, the lamp will visually turn on, at the same time as the electric network will know an additional lamp is consuming electricity. The result unsurprisingly, looks similar to how it was before, and the lamps don't turn on too late:



A side benefit, now each lamp prototype can define its own intervals, so it's easy to adjust for the intrepid modders out there. The other problem was also cleanly resolved alongside the staggering, so now the lamps turn on at a reasonable time once again. You can look forward this minor change with 0.16.23, which will be released on Monday.

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

After a long 14 hour flight back, Albert, kovarex and I arrived back from Taipei, after our attendance at the Taipei Game Show. Jitka started her vacation by staying there to visit the Taiwan island.
We stayed there for 7 days (2 days in the business area, 3 days in the convention area and 2 days of free time where we visited the city).

In the business area we met many potential business partners and got way too many business cards. We made some friends among the other indie developers and tried all kinds of fun, weird, interesting and some bad indie games.

The convention area was very crowded, with 350,000 visitors slowly trying to make their way through the fairly small convention hall. I can't speak for the others, but I still enjoyed myself. Even though it was crowded, most of the games were in Chinese, and I only got to try one AAA game, there is something about being surrounded by games, gamers, and game developers that makes me feel great.
Our booth was in the indie area. We had many people coming to try the game but also many fans wanting to speak with us and congratulate us for making a great game. AndrewIRL who lived there for a few years, invited us for dinner to "the best restaurant in the city", and we were not disappointed.

Factorio is not an easy game to demo, since it takes at least 30 minutes to kind of understand what the game is about. But having the trailers looping on the screen, and having subtitles for the gameplay trailer meant that the people got a fair idea about what the game is about and how complex it is. While not the best, we had people start by playing the campaign. Most of them were leaving after the first level but some of them were also getting addicted and playing for multiple hours. We gave free Steam keys to some of the people who were more engaged with the game. It was a learning experience to see people play the game for the first time and to see the most common problems with the campaign, the interaction, the UI and the Traditional Chinese translation.

The days were super exhausting though, many of us collapsing at the accommodation and sleeping for 10 hours. Luckily we had 2 more days to relax and enjoy the city before flying back. We mostly split up and each of us visited what they were most interested in, with me going through the electronics markets and riding a rented bike through the rainy streets.

To give credit where credit is due, I'd like to thank the game show for inviting us and sponsoring our booths, and Razer for conveniently lending us the laptops we used to demo the game.
Financially there is no point in us going to a game show, our attendance did not bring us any extra sales in Asia, as expected. The point of going there, for us, is to visit the show floor, play and see random games, make gamer friends, meet fellow developers, meet big fans of the game and maybe make some business partners.
Since many of you mentioned PAX and some of us are interested in going there, we are trying to see if we can attend PAX East this year (April 5-8th). So you might have another opportunity to come and take selfies with some of the Factorio devs.


From left to right: Jitka, Albert, Twinsen, kovarex.

It was always a nice aesthetic touch, and we have had it for a long while, but during the most recent 0.16 one small feature has been absent. That is of course, the lamp staggering: During the day/night transition, lamps will turn on and off and different times. For example, this is how it looked it 0.15:



During the development of 0.16, there was a move by kovarex to optimize the lamps. By all means the optimization was a success, but along the way the lamp staggering was removed. This didn't go unnoticed, but a proper solution was quite tough. A simple way we tried (even in the first 0.16 release) was to just visually turn the lamps on at different times. It looked the part, but unfortunately was technically incorrect, as the lamps would look 'on', but not actually consume any electric power until the required darkness at which point they all started consuming power.

Due to its incorrectness, this visuals-only solution was reverted, so for most of 0.16 this is what it looks like:



It is also obvious in this GIF, that they turn on way too late, it is already very dark before they turn on.

So anyway, there is a problem here, in that we want the lamps to turn on 'correctly', but it needs to not basically undo all the optimization. To give a brief summary of the optimization, the lamps no longer have to update themselves, the electric network just knows how many lamps there are. When it gets dark enough, the electric network knows that all the lamps will turn on, so just multiplies the consumption of the lamp by how many there are. This is similar to the solar panel and accumulator optimization. To work correctly, the rendering of the lamp, and the electric network update, have to know exactly when a lamp will be turned on, without being able to share any information with each other.

So first we define two values, how dark is it when they start turning on, and how dark it is when they should all be turned on. This gives us a darkness interval where the staggering will take place. Then when a lamp is built, we assign it a specific time in this interval at which it will turn on, and then also keep that value in a list in the electric network. This way, the lamp will visually turn on, at the same time as the electric network will know an additional lamp is consuming electricity. The result unsurprisingly, looks similar to how it was before, and the lamps don't turn on too late:



A side benefit, now each lamp prototype can define its own intervals, so it's easy to adjust for the intrepid modders out there. The other problem was also cleanly resolved alongside the staggering, so now the lamps turn on at a reasonable time once again. You can look forward this minor change with 0.16.23, which will be released on Monday.

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

Stabilization goes well, the game seems to be quite stable right now (as in - not many crashes are being reported), in fact I think we are at the phase where additional bugfixing makes the game less stable, because more bugs are introduced than fixed, or some critical bug slips through our automated tests. But there are still lot of issues that need to be resolved before we declare 0.16 stable and move on to 0.17 development - the largest issue being belt compression problems.

We finally fixed compatibility problem with OS X 10.9 Mavericks after it was broken in 0.15.40, when we updated our development environment to a newer version of boost, and was still broken in 0.16.x despite of us completely replacing boost with standard libraries from a newer version of C++. However, we might drop Mavericks support in 0.17, as we are considering migrating the game to OpenGL 4.1, which won’t be available on Macs that are unable to run a newer version of macOS.

Speaking of OpenGL, we have several reports of the game crashing in rendering on Linux when the game is disturbed somehow (for example window resizes, loses focus or user switches workspaces), even though it is terribly inconvenient, the game seems to be otherwise playable on these configurations, and we don’t want to spend a terrible amount of time trying to figure out what is wrong with our current rendering system, when we plan to do complete overhaul of it in 0.17. We will investigate these issues, but they might go unresolved until 0.17.

I’ve been looking into some corrupted saves this week, still not being able to figure out how these mysterious corruptions occur. For example this save had two iron ore entities on two different chunks saved with zero entity ID. This could have happened only if those entities had a wrong pointer to the iron ore prototype, so when the game read the ID from the prototype on saving, it would read a value from some random part of memory, or if the ID was corrupted on copying from the prototype to buffer that is saved to disk. Since these kind of corruptions seem to be relatively rare, we suspect it might caused by random hardware failures (maybe cosmic ray hitting a transistor and flipping bit somewhere?), but it would be nice to have some proof it is not some dangling pointer in our code that causes random parts of memory to be overwritten by who knows what.

One way to test it would be to check for tile corruptions. Tile data for a chunk is allocated in a 4kB array at the beginning of the chunk. We could create custom allocator for chunks, so that data structure representing chunk is aligned to virtual pages. That way tile data would occupy a whole single virtual page which we could flag as read only. Then, if due to a bug we write over tile data, the OS would crash the game and we would get a stacktrace and crash dump to investigate. But if a cosmic ray would hit the RAM and flip a bit, the corrupted save would still be produced. However, we currently don’t do any custom allocation of virtual pages, so it might be quite hard to implement. We also need to change tiles sometimes (when map generation runs, when player uses concrete or landfill, when a script changes tiles, etc.) and we don’t know how expensive it would be to change pages from read only to read-write and then back to read only. So it might be just easier to spend two hours on fixing a broken save that someone sends us once every week or two.

Recently I have been working on high resolution graphics for gun and laser turrets. The 3D models are pretty much exactly the same as Albert with Pavel made them back in 2015, so I just needed to make them render correctly in our modern system. You can see the laser turret base is different, tt was created a long time ago as well, just never used. With the high resolution versions, we can now take the chance to alter the designs of entities, in this case just use what we already have. We believe that the new stand fits much better to the laser turret as it doesn't need any super heavy basing, and makes the two turrets more visually distinguishable.

They are still a work in progress, but as you can already see in the following mock-up, laser turrets are now going to shoot something we can actually call a laser.



It often happens that we make very nice graphics for the entity itself, but spend less time on extra effects which would really make it feel great in the game. In my opinion the laser turret is the prime example of this. The laser "beams" have been ridiculed many times in many discussion threads, and now with the work on the high resolution version it is finally a good opportunity to change them.

The way how it applies damage is probably going to have to change at least a little bit along with a few other minor things, so they might not make it into 0.16 to avoid any unnecessary problems, but we will see about that.

In the following action movie you can see our very own Posila running away from the fauna of the unexplored planet full of life and natural resources, being saved by nothing other than his skills and laser turrets, while his productive teammate watches the action unfold.



The flamethrower turret is also going to receive some small graphical polishing with its high resolution version. We will present that one some other time as it is not ready yet.

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

Stabilization goes well, the game seems to be quite stable right now (as in - not many crashes are being reported), in fact I think we are at the phase where additional bugfixing makes the game less stable, because more bugs are introduced than fixed, or some critical bug slips through our automated tests. But there are still lot of issues that need to be resolved before we declare 0.16 stable and move on to 0.17 development - the largest issue being belt compression problems.

We finally fixed compatibility problem with OS X 10.9 Mavericks after it was broken in 0.15.40, when we updated our development environment to a newer version of boost, and was still broken in 0.16.x despite of us completely replacing boost with standard libraries from a newer version of C++. However, we might drop Mavericks support in 0.17, as we are considering migrating the game to OpenGL 4.1, which won’t be available on Macs that are unable to run a newer version of macOS.

Speaking of OpenGL, we have several reports of the game crashing in rendering on Linux when the game is disturbed somehow (for example window resizes, loses focus or user switches workspaces), even though it is terribly inconvenient, the game seems to be otherwise playable on these configurations, and we don’t want to spend a terrible amount of time trying to figure out what is wrong with our current rendering system, when we plan to do complete overhaul of it in 0.17. We will investigate these issues, but they might go unresolved until 0.17.

I’ve been looking into some corrupted saves this week, still not being able to figure out how these mysterious corruptions occur. For example this save had two iron ore entities on two different chunks saved with zero entity ID. This could have happened only if those entities had a wrong pointer to the iron ore prototype, so when the game read the ID from the prototype on saving, it would read a value from some random part of memory, or if the ID was corrupted on copying from the prototype to buffer that is saved to disk. Since these kind of corruptions seem to be relatively rare, we suspect it might caused by random hardware failures (maybe cosmic ray hitting a transistor and flipping bit somewhere?), but it would be nice to have some proof it is not some dangling pointer in our code that causes random parts of memory to be overwritten by who knows what.

One way to test it would be to check for tile corruptions. Tile data for a chunk is allocated in a 4kB array at the beginning of the chunk. We could create custom allocator for chunks, so that data structure representing chunk is aligned to virtual pages. That way tile data would occupy a whole single virtual page which we could flag as read only. Then, if due to a bug we write over tile data, the OS would crash the game and we would get a stacktrace and crash dump to investigate. But if a cosmic ray would hit the RAM and flip a bit, the corrupted save would still be produced. However, we currently don’t do any custom allocation of virtual pages, so it might be quite hard to implement. We also need to change tiles sometimes (when map generation runs, when player uses concrete or landfill, when a script changes tiles, etc.) and we don’t know how expensive it would be to change pages from read only to read-write and then back to read only. So it might be just easier to spend two hours on fixing a broken save that someone sends us once every week or two.

Recently I have been working on high resolution graphics for gun and laser turrets. The 3D models are pretty much exactly the same as Albert with Pavel made them back in 2015, so I just needed to make them render correctly in our modern system. You can see the laser turret base is different, tt was created a long time ago as well, just never used. With the high resolution versions, we can now take the chance to alter the designs of entities, in this case just use what we already have. We believe that the new stand fits much better to the laser turret as it doesn't need any super heavy basing, and makes the two turrets more visually distinguishable.

They are still a work in progress, but as you can already see in the following mock-up, laser turrets are now going to shoot something we can actually call a laser.



It often happens that we make very nice graphics for the entity itself, but spend less time on extra effects which would really make it feel great in the game. In my opinion the laser turret is the prime example of this. The laser "beams" have been ridiculed many times in many discussion threads, and now with the work on the high resolution version it is finally a good opportunity to change them.

The way how it applies damage is probably going to have to change at least a little bit along with a few other minor things, so they might not make it into 0.16 to avoid any unnecessary problems, but we will see about that.

In the following action movie you can see our very own Posila running away from the fauna of the unexplored planet full of life and natural resources, being saved by nothing other than his skills and laser turrets, while his productive teammate watches the action unfold.



The flamethrower turret is also going to receive some small graphical polishing with its high resolution version. We will present that one some other time as it is not ready yet.

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