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, it 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.
