Captain of Industry News

Ahoy sailors, Captain Zuff reporting for our next Diary post. Today we have lots of information about what we have been working on and about the next big update!


Before we get into the game updates, on behalf of the entire MaFi Games team, I would like to welcome Jeremy, our new senior software engineer from the UK. We are so happy to have you join us and help us accelerate progress on the game! Here are a few words from Jeremy:

“Hi everyone! I'm excited to be joining the team and am looking forward to getting stuck in. While I have a background in performance optimization, I'll be working on all parts of the game, from bug fixes to new features. I'll mostly be working in the background so you may not see me pop up in person too often, but hopefully, you enjoy the results of my work!”

And by the way, Jeremy has been recently working on the new upgrade tool.


Past weeks we have been busy planning the next big update as well as prototyping what is feasible to do so that we can deliver on the plan. The community feedback played a huge role in this process and we are thankful for everyone who is sharing it on Discord, Steam, feature requests site, Reddit, and elsewhere!

We have a lot of plans but in this post, I will share a smaller chunk that we are working on right now.

[h2]Terrain graphics and simulation improvements[/h2]
A pivotal change of the terrain rendering tech is the extension of the maximal number of supported terrain textures. Players have been asking why they cannot dump various materials on the ground and one reason was that our terrain supports only 24 different textures. This has been a big limitation and we are working on rewriting the terrain rendering to support up to 256 different textures! This will allow us to add more textures to the game, increasing visual variety as well as allowing players to dump more different materials on the ground. Mods will be also able to take advantage of this by adding new custom dumpable materials.

Adding more textures is not the only terrain improvement. We feel that the terrain looks too plain and is missing visual richness and variety. Our artist Miroslav is hard at work improving existing terrain graphics as well as adding new models such as grass, rocks, bushes, branches, tree stumps, etc. Take a look at a mock scene below!

Comparison of current terrain in the game (top) and our new terrain prototype with new props and textures (bottom).

Close-up of the new terrain prototype including new props.

Close-up of the new terrain prototype with new textures of rock and iron ore.

Another important change we are hoping to implement is improved terrain physics simulation. One issue we are constantly dealing with is that the material collapse angle is the same for all states of a material. For example, a solid rock on a mountain will collapse at the same angle as a mined rock from that mountain. This often results in cascading collapse of entire mountains when they are disrupted by mining.

We plan to separate “solid” materials from “already mined” ones and have different collapse rules for them so that steeper mountains are possible. We are also thinking about mining changes so that tall mountains are not always possible/easy to be mined from the bottom. This will need more testing.

[h2]Rendering improvements[/h2]
This is a big topic, but a long story short is we want to make the game look better and one feature that makes a tremendous difference is anti-aliasing.

Currently, we use the “deferred” rendering pipeline in Unity. It has many advantages such as efficient rendering of lights, or powerful post-processing features. However, one thing that it cannot do well is anti-aliasing (smoothing out jagged edges). Unity implements a technique called “temporal anti-aliasing” that renders each frame slightly differently and averages consecutive frames in time. This technique helps but does not work very well. We were experimenting with a different rendering pipeline called “forward” that does support multi-sample anti-aliasing (MSAA).

The decision on the rendering pipeline is not easy and there are always trade-offs. From our initial testing, the MSAA is such a big visual improvement to the game that we are considering removing lights (currently only used on vehicles) and switching to the forward rendering pipeline. This is a relatively big undertaking since many of our custom rendering code was assuming deferred renderer, but we think it is worth the result.

Comparison of the deferred rendering with temporal anti-aliasing (currently used in the game) and the new forward rendering with 8x MSAA.

From the comparison above you can see that the MSAA does a much better job of smoothing out the jagged edges on the models, especially in the distance. Also, you can see that the grass on the terrain is visible much further since most of the grass blades have sub-pixel size which is not possible to be rendered with the deferred renderer.

Another benefit of MSAA is that it produces “stable” images that do not change over time. A big disadvantage of temporal AA used by the deferred pipeline is that small objects and edges tend to flicker. This is part of the algorithm that reduces aliasing, but it can be very distracting to see flickering, especially when the camera is not moving. This is especially visible on bright objects such as molten metals where the flicker can be much more apparent. This issue is not present when using MSAA.

Unwanted flicker caused by the temporal anti-aliasing of the deferred renderer. This issue is not present when using forward rendering with MSAA.

Models improvement
We are also working on improving some of our 3d assets. This is going to be a continuous effort but we hope we are up to a great start.

New tier II excavator model compared to the old one. You can hopefully tell which one is which!

[h2]Map editor[/h2]
Terrain and rendering improvements lead us to the biggest and most complex feature that we are working on – the map editor. While we have a simple editor that was used to make existing maps, we cannot simply make it available to all of you since it is using Unity Editor UI. It is also very hard to use, even for us, and we wanted to offer more powerful tools that are easy to use.

Another big issue is backwards/forwards compatibility. Currently, maps are represented via code (maps are procedurally generated) and the representation is relatively brittle. Sometimes we need to do manual changes to the existing maps source code to keep them compatible. This obviously would not scale to community-made maps. We would hate to do some changes to the game that would obsolete all maps made by the community.

The solution here is two-fold. First, design a new map representation that will be as robust to game changes as possible. Second, create a new editor that uses the in-game UI that handles editing of the new map representation.

Making a COI map editor has an additional complication that many other games do not have to deal with: What is under the terrain surface matters. COI has a fully dynamic layered terrain and resources are often underground. This means that the editor has to support this. We are still not completely sure how to implement this but we have ideas to try. We will definitely give you an update on this topic as we work on it.

Another close-up of the new terrain prototype.

[h2]More music[/h2]
We are also happy to announce that our artist Ondrej has been working on another 30 minutes of music for the soundtrack. We have nearly 80% done!


We also plan to implement tree replanting, better product visualization on conveyor belts, improved unit storage visualization, and hopefully add a few more machines for more processing capabilities. We will cover these areas in more detail once we get closer to working on them.


It is hard to predict exact dates as we are diving into significantly large areas. We aim to deliver the update in Q2 2023. We will also drop at least one medium-sized update this year that has some nice improvements and bug fixes.


We also have a few changes that are coming before any big update arrives. These are bug fixes but also a new tutorial system with goals and active tracking of player progress. We hope we will be able to improve the initial experience when folks are learning the game. This update should arrive in a couple of weeks.

Example of the new tutorial system that we are working on.


This is all we had for you for now but don’t forget, this is just the first wave. There are more features coming in Update 1 and we will keep you updated as we get to work on them.

Thank you for your continued interest and support and let us know your thoughts on Discord, Steam, or Reddit!

The v0.4.12 has graduated from experimental and is now available on the main branch! To learn more about the patch, see our recent Captain's diary #31: https://www.captain-of-industry.com/post/cd-31

[h2]Performance[/h2]
* Optimized rendering of common buildings resulting in up to 3x more FPS.
* Optimized rendering of construction cubes that no longer cause any FPS drop.
* Optimized game loading which is 2-8x faster.
* Optimized save datastructures making save files 2-3x smaller.
* Fixed issues causing consecutive loads consuming more memory and being slower.

[h2]Other improvements and fixes[/h2]
* [Important] Added `ChangeConfigs` method to `IMod` interface allowing mods to change configs. This is not a backwards-compatible change.
* Building ghosts, construction cubes, and ports now have color based on construction state.
* Building ghosts now have subtle texture to make them more recognisable.
* Current weather is now shown as an icon.
* Fixed that the cargo depot would accept any fluid as fuel instead of just diesel.
* Fixed cargo depot that could give free fuel when adjusting sliders.
* Fixed loud sound when quitting the game.
* Fixed loading of files with special characters such as '['.
* Fixed a special case where cargo depot did not allow to assign a product
* Fixed top bar jumping between single and double row when a date length was changing.
* Clinic now prefers a higher tier of medical supplies if it has multiple types stored.

[h2]v0.4.12a[/h2]
* Fixed construction of transport pillars.

[h2]v0.4.12b[/h2]
* Fixed entity icons disappearing after upgrade.
* Fixed tile validation overlay for flipped/rotated entities.

[h2]v0.4.12c[/h2]
* Fixed incorrectly highlighted particles during (de)construction.
* Farm no longer simulates fertility when under initial construction.
* Fluid colors on storages and transports are now visible immediately after load.

[h2]v0.4.12d[/h2]
* Improved how mods are loaded, being able to reference and load dependent DLLs.
* Added command line arguments useful for modding such as --skip-assets-preload, use --help to list them all.
* Added XML documentation for all mafi DLLs. It should just show up in your IDE when using mafi APIs.

[h2]v0.4.12e[/h2]
* Fixed tree harvester UI that was not properly updating the line to goal.
* Fixed building (de)construction cancellation that could sometimes result in insta-built entities.
* Fixed hit-box of chicken farm to not contain an empty area next to it.
* Fixed issue with balancers when they were configured to have no power consumption.

Hello Captains! Zuff here bringing you exciting news about the latest patch v0.4.12 that has just landed to the experimental branch!

TL;DR: The game now loads 2-8x faster, save files are 2-3x smaller, and FPS is 2-3x higher! This patch is without a doubt the largest performance update to Captain of Industry to date! And there are also some nice changes regarding construction visualization and minor fixes. Keep on reading to learn how these amazing speedups were achieved or skip to the end for full patch notes.

Before we dive into the technical details about speedups, I would like to announce a change in the schedule of Captain Diaries. Until now, we were doing CD posts every two weeks but going forward we won’t keep a strict schedule. These posts take a long time to prepare and sometimes we’d prefer to keep working on things and announce them when ready, not when a 2 week deadline ends. In fact, that’s precisely what happened with this post.

Here’s Marek and Filip with the technical details about the performance improvements.


Ahoy! Captain Marek speaking and I am thrilled to tell you about some serious performance improvements that we have done. The two techniques used to achieve this were GPU instancing and Level of Detail (LOD).

As you might recall, our previous performance improvements were also revolving around GPU instancing (batch-rendering) of many small entities, transport pillars mentioned in Captain's Diary #15 gave as 2-3x more FPS and building ports mentioned in Captain’s Diary #29 yielded 20-50% more FPS.

We have this handy tool that can selectively disable rendering of objects and based on this performance analysis, the biggest performance offenders were 1) buildings/machines, 2) transports, and 3) construction cubes (when present). We will skip transports for now and focus on buildings and construction cubes. Let me start with the cubes optimizations.

Chart showing what takes the longest time to render.

[h2]Construction cubes optimizations[/h2]
Construction cubes are these little boxes representing scaffolding that appear over a building when it is being constructed, upgraded, or deconstructed. They appear for each voxel of the built entity. For common entities that's 100-1000 cubes per building. But a single greenhouse needs over 10k cubes! You probably see where this is going. Tens of thousands of individual cubes updated every frame (since they are animated) and we have a perfect recipe for FPS disaster.

We thought about two ways of addressing this issue. One, use GPU instancing and don’t worry about the high counts of cubes. Alternatively, we could reduce the number of cubes and make them larger to avoid too many individual objects. Well, we decided to go all-the-way and do both optimizations!

GPU instancing was already explained in the previous posts, basically it allows rendering of multiple instances of an object by the GPU given a list of data describing how each object is rendered. And you can probably imagine how four 1x1 cubes can be combined to one 2x2 cube reducing the total number of cubes. I will just note that to make this super efficient, cube position, size, color, and animation state are all handled in the GPU shader and cubes are no longer updated on the CPU every frame.

Test scene for construction cube benchmark.

For performance testing, we have set up an empty island where 5 greenhouses were being constructed at the same time. The game without construction cubes was running at 123 FPS, before optimizations this dropped to 7.4 FPS when all 50k construction cubes appeared. After our optimizations the FPS is back at 120! Suffice to say that construction cubes will no longer lag your game!!

Chart comparing rendering performance of baseline (no cubes) to 50k rendered cubes before and after our optimizations.

[h2]GPU instancing for buildings[/h2]
Building optimizations have a similar vibe as construction cubes or building ports, using GPU instancing to reduce the overhead of rendering many objects separately, but there is a problem. GPU instancing handles only rendering of 3D models, but buildings need much more than that. They need to be selectable by the player, have animations, sounds, particles, be able to collapse, and none of this can be “GPU-instanced”.

Based on our performance data shown below, we have decided to go after the low-hanging fruit and optimize only the buildings that have no animations, sounds, or particles. As a coincidence these ones are actually taking the majority of the frame time because there are so many of them. I am talking about retaining walls, connectors, balancers, solar panels, vehicle ramps, etc.

Approximate rendering times for top 14 buildings from factory by MaddProf. Blue marks static non-animated buildings that we decided to optimize, red are all unoptimized.

There were additional issues with GPU-instanced rendering of buildings. One of them is flipping. Most buildings can be flipped horizontally or vertically to aid with connection constraints. The issue is that when a 3D model is flipped, all triangles will change their winding order (whether the vertices are ordered clockwise or counterclockwise). Why does this matter? A typical optimization done by virtually any 3D game/engine is to do something called back-face culling. Basically, if the 3D models have all triangles with the same winding order, GPU can quickly detect whether a triangle is facing “towards” or “away” from the camera by checking its winding order and if it is facing away, it can skip drawing its pixels. Have you ever wondered why 3D models are “invisible” from inside when the camera clips inside? It is exactly thanks to this optimization. Triangles are visible only from one side.

So what is the issue with flipping again? GPU instancing can render all the instances of one 3D model at once, but the setting for back-face culling must be the same for all instances. So you either enable back-face culling and have all flipped buildings rendered “inside-out”, or disable it and draw twice as many triangles.

Two instances of Mine control tower rendered with the same setting of back-face culling. The right one was flipped along the horizontal axis and due to incorrect triangle winding order it looks “inside-out”.

Actually, there is a third option. Split buildings into two sets, flipped and non-flipped, and draw each set with a different setting of back-face culling. While this makes code infrastructure slightly more complicated and introduces a second draw-call for each building type, we went with this solution to avoid drawing unnecessary triangles.

Another issue was building selection and highlighting. We had to set up proxy elements in the scene that are invisible but allow us to select buildings with a cursor. Highlighting is done by rendering into a special buffer and this is handled by a separate draw call (a third one). Here, we do not distinguish between flipped and non-flipped buildings.

And a final issue that I’d like to touch on is the collapse mechanic. When a building is dug under it will collapse and this must work for buildings rendered with GPU instancing. We have actually borrowed a similar code that animates construction cubes and used it to animate a fall of a building. When collapse happens, the static building model is hidden and a same-looking but animated building model is displayed. We also add a proxy-object with dust particles.

A visualization of a frame as rendered by the GPU. On the left you can see the scene being rendered before GPU-instancing optimizations and the water collectors are rendered one by one. Compare this to the right half where instancing allows the GPU to render large chunks of buildings at once. Note that this comparison is not exact in the representation of time taken to render each entity.

[h2]Level of details for buildings[/h2]
GPU instancing is making triangle drawing more efficient for the GPU but it actually does not reduce the number of processed triangles. At some point, no matter how efficiently we feed the GPU with triangles, it won’t be able to keep up processing and rendering them. And we know that some of you will just keep building bigger and bigger so we’ve implemented another layer of optimization – Level of detail (LOD).

The idea behind LOD is simple. Models far from the camera can be replaced by simpler ones, reducing the number of rendered triangles. When done well, you can hardly tell the difference.


Example of LODs of the rainwater harvester. The original model (left) has 3734 triangles and the simplified model (right) has just 698.

The disadvantage of this technique is added code complexity and, more importantly, we need to make simplified models for each building which takes a lot of extra 3D modeling work. Because of the extra work, we are LOD-ing only the most important models for now and will be adding more as we go.

The kicker is that LOD and GPU instancing optimizations can go hand-in-hand. We group entities to 256x256 tile chunks and all entities on each chunk are rendered with respective LOD based on camera distance. This allows us to utilize both optimizations and also compute the LOD level only for each chunk, not for each entity.

Chart showing how LOD reduces the number of rendered triangles.

[h2]Final results for building rendering optimizations[/h2]
We will present the results on a rendering benchmark of several selected factories from the community, namely from MaddProf, Yandersen, and NeetEngineer – thanks for sharing your amazing factories with us!


Testing factory from MaddProf with a sea of retaining walls.

The overall results are impressive! We saw 2-3x more FPS on very large factories. The more buildings the greater speedups. MaddProf’s sea of retaining walls (over 4k walls to be specific) saw an improvement from 17 to 25 FPS. A factory from Yandersen with over 1700 solar panels and 480 rainwater collectors saw a FPS increase from 10 to 25 (when the gigantic solar farm was in the view). Finally, Neet Engineer's factory is something else. With nearly 4k solar panels and 5k transport connectors, it is the largest factory that we have ever loaded and due to the insane amount of buildings, we saw FPS improving from 7 to 23 (depending on the camera view). With these improvements we are looking forward to seeing what else you can build!



That was a lot of info, but wait, there is more! Filip has detailed info regarding optimizations of loading and save files!


Captain Filip here. We have heard your feedback on long load duration times and we have been noticing them as well. It has become our priority to understand what is going on and reduce it. The good news is that we managed to shave off a lot.

Game init consists of several phases:

• Game init + load
  
• UI build
  
• Rendering initialization
  

First critical one was game load. It turned out that for large factories it became crazily slow. I have actually received a save file from JDPlays from his YouTube series. You can check out his video here showcasing his island, it’s really impressive. We also used a couple more save files provided by folks from our community - JoneY and Manuel de Heer, thanks for that!

One of my theories was that the game simply decided to punish JD for trying to break it all the time which would make sense 🤣. But after a few technical investigations it turned out that several things were more expensive than we expected. If you recall how Marek previously improved game rendering by focusing on ports, well guess what, ports did strike again. Each port is represented by a class which turned out to be a bit too heavy as ports supported Events, however given there can be 4-6 times more ports than entities and it quickly adds up. Also, our Events are a bit special as they are automatically saveable, however their callback compilation was taking way too big of a slice of our load time, so simplifying ports by removing these Events entirely helped a ton. We have also simplified terrain designations and their backing data structures for mine towers and assigned jobs as players typically have lots of designations. With all this, the improvement got quite substantial.

First of all, the save size got reduced quite a bit. On large factories the save files are now 3 times smaller. However, it has been also reduced due to us fixing one leak in stats that not everyone was hitting.

Chart showcasing the size of save files before (red) and after (green).

The game load is now 6.5 times faster, however even for more compact factories we are still hitting 1.7 times improvement.

Chart showcasing how long it takes to load the game in seconds before (red) and after (green).

As a side effect of this effort, the save & auto save now became faster as well. Which is great because no one likes slow auto save.

Chart showcasing how long it takes to save the game in seconds before (red) and after (green).

When investigating the game load we noticed that there is actually another phase that decided to cause troubles - UI initialization. It was eating 12 sec from the start of the game. Now this one is interesting, because it does not depend on the size of a factory. So reducing this would reduce the waiting time for everyone. It turned out that Unity had few footguns in their API, and we were paying hard for re-parenting during UI build.

For Unity fans out there, we build UI via code using Unity’s API. When you want to create a new UI element you need a GameObject. The most obvious API for that is “new GameObject()”, however what happens is that Unity creates a new separate root hierarchy for it and once you place that object into a new parent, it throws the old parent hierarchy away and updates the entire sub-hierarchy about the new parent. The solution was to use Object.Instantiate which (unlike GameObject constructor) accepts a parent to create that object in the right place. Sometimes we would build an entire window UI (such as research) before we put it into Unity’s Canvas. At that point we would pay for re-parenting of every single element of that window, almost the same as creating each of those elements again. When this happened on multiple levels of the UI it added up very quickly. In total, the re-parenting was eating half of our UI build duration.

Another observation we made was that our bottom toolbar panels, that contain all the machines, were taking up significant time to build as for each category we had a separate panel. So we merged all of these into one UI view which is shared by all the categories.

And final improvement was that we added Unity Sprites caching to avoid duplicates when building the UI which saves not just time but also the memory.

At the end all the improvements got us from 12 seconds to 2 seconds. Not too shabby! When we add the load duration improvement + ui init improvement into one chart, here are our new game load + ui build improvements:

Chart showcasing how long it takes to load + init UI of the game in seconds. This is basically the major portion of time spent waiting for the game to start.

Now it becomes a bit more clear while JDs island got so well thought through. Whilst waiting for the game to load, he had so much time thinking about his next steps! 😉

[h2]Subsequent game load[/h2]
We had several reports that subsequent load takes longer (loading while already in a loaded save). It was because of a memory leak. Well, not necessarily a memory leak but a misunderstanding between us and how Unity expects us to dispose of their native objects. Also we learned that running GC right before we load a new game might be a good call to prevent C# allocating an even bigger heap. Obviously systems with smaller RAMs had to have a hard time because at that point it might have ended up page swapping the memory. So we fixed all of that and based on our experiments, subsequent load is no longer slower.


Part of the performance improvements was a partial rewrite of entities construction and visualization. While at it, we have improved construction visualization in two ways.

First, building blueprints now show the entity texture in a subtle way. This makes recognising blueprints slightly easier. Take a look at the following comparison.

Example of blueprint of mining tower. Left is how it looked until now, right is the new version. Notice the subtle details of the constructed building.

Second, blueprint color as well as colors of construction cubes are now matching the construction state. Blueprints for buildings under construction are blue, paused construction is marked as gray, and deconstruction is red.

New construction coloring for buildings. Blue (left) is a furnace under construction, gray (middle) is paused construction, and red (right) is a furnace under deconstruction.

This new color scheme also eliminates the need for icons marking paused construction as they were sometimes in the way, visually cluttering the scene. All this and more is also described in a new game tutorial that is triggered when the first building construction is paused.

Old rendering with construction pause icons (left) and new rendering with gray ghosts representing buildings with paused construction (right)

v0.4.12
Performance
* Optimized rendering of common buildings resulting in up to 3x more FPS.
* Optimized rendering of construction cubes that no longer cause any FPS drop.
* Optimized game loading which is 2-8x faster.
* Optimized save datastructures making save files 2-3x smaller.
* Fixed issues causing consecutive loads consuming more memory and being slower.

Other improvements and fixes
* [Important] Added `ChangeConfigs` method to `IMod` interface allowing mods to change configs. This is not a backwards-compatible change.
* Building ghosts, construction cubes, and ports now have color based on construction state.
* Building ghosts now have subtle texture to make them more recognisable.
* Fixed that the cargo depot would accept any fluid as fuel instead of just diesel.
* Fixed cargo depot that could give free fuel when adjusting sliders.
* Fixed loud sound when quitting the game.
* Fixed loading of files with special characters such as '['.
* Fixed a special case where cargo depot did not allow to assign a product
* Fixed top bar jumping between single and double row when a date length was changing.
* Clinic now prefers a higher tier of medical supplies if it has multiple types stored.

The v0.4.11 has graduated from experimental and is now available on the main branch! To learn more about the patch, see our recent Captain's diary #30: https://www.captain-of-industry.com/post/diary-30

[h2]New Features[/h2]
* Unlocked buildings are now highlighted in menus until they are selected for the first time.
* Added an option to auto-return the main ship after exploration when there are no more reachable locations to explore.
* Added a new edict that reduces ship fuel consumption by 10%.
* Added an option to make ships 50% slower to save 30% of fuel per trip.

[h2]Cargo ships and contracts balancing[/h2]
* Increased cargo ship capacity by 2x, fuel consumption by almost 2x. World mines buffers were also increased to accommodate.
* Larger cargo ships are now more fuel efficient per trip.
* Decreased total travel duration of cargo ships from 3.3 to 3 months.
* Increased cargo depot modules unloading speed, the highest tier now unloads the ship in just one month.
* Increased profit on copper, iron and quartz contracts.
* Increased profit on contracts selling coal and vehicle parts 2.
* Added new contract: consumer electronics -> quartz.

[h2]Other balancing[/h2]
* IMPORTANT: Gas rotary kiln changed to return CO2 instead of Exhaust.
* Reduced coal consumption of the silicon recipe in the Arc furnace II by 50%.
* Reduced computing consumption of Arc furnace II from 6 to 4.
* Increased the throughput of Chemical plant for graphite production from CO2 by 2x.
* Reduced transports building duration by 80%.

[h2]Other fixes and improvements[/h2]
* Retaining walls are no longer buildable on terrain designations and vice versa. This should prevent issues with mining/dumping over the walls. A new console command `toggle_terrain_designations_over_entities` can revert this change for power users.
* Renamed "Liquid nitrogen" to "Nitrogen tank" as it is a unit product.
* Fixed UI that was not clickable in some cases in windowed mode.
* Transport snapping is always enabled when no transport is selected. This allows snapping to ports and other transports when starting transport construction.
* Fixed that entities with reserved ocean area such as ocean pump/dump could block ship access of the cargo depot/shipyard indefinitely.
* Fixed the "Recover ocean access" action. Note that all ocean areas will be recomputed after loading this game version which may cause entities being newly blocked or unblocked.
* Improved ocean area recovery action that now shows what is blocking the ocean area if the recovery fails.
* Fixed vehicle dust particles that were not emitted properly in some circumstances.
* Increased vehicle dust particles visibility distance and optimized their rendering.
* Fixed buffers clearing to only clear buffers of unassigned recipes that are not used by any assigned recipe.
* Toggling of planning mode no longer cancels the current building session (e.g. cut & paste).
* Fixed that toggling prod. level on world mine did not reduce workers when it had full buffer
* Fixed a rare case where a settlement transformer would not work for settlements with low population.
* Fixed internal buffers in the Maintenance depot that could accumulate large amounts of maintenance.
* Fixed a rare issue with terrain data serialization that could lead to corrupted save files.
* Fixed incorrect shortcuts shown when insta-copying transports.
* Partial execution for recipes was changed to kick in only when no other recipe can be satisfied fully.
* Added UI showing the state of supply of fuel rods in the nuclear reactor.
* Improved error tooltips and other places for colorblind accessibility.
* Excavators no longer forcibly turn on their lights during game pause.
* Updated translations, thanks to everyone who is contributing!

Morning Captains! Zuff here bringing you news about the latest patch v0.4.11 that has just landed to the experimental branch! To check out the experimental branch, follow instructions in Captain's diary #27.

Before we go into all of the changes, we want to give a certain person a shoutout:

Some time ago one of our early backers and Discord member, McRib, sent each of us here at MaFi Games personalized COI Mugs with a heartfelt note and some treats. As we all rely on coffee/tea to function day to day so these will be used frequently! We appreciate you, McRib, and all that you do for the community! Thank you!



We are currently focusing on fixing all reported bugs and issues that prevent a smooth playthrough. Before we start working on larger new features, we want to make sure that the current game is bug-free. This results in more frequent smaller patches such as the one today since we don’t want to delay important fixes by implementation of new features. We also have some more performance improvements in works but they will likely be available in the next patch.

Full patch notes can be found at the bottom as always.

[h2]Unlocked buildings are now highlighted before used for the first time[/h2]
Know what you’ve unlocked or haven’t used through the new highlight system! Each building/transport that has not been selected will have a yellow dot in the upper right corner.


[h2]Auto-returning ship[/h2]
It is often the case that once the main ship has no more fuel for exploration, the only reasonable action is to return home. But it has to be done manually. To avoid this micro-management we’ve added a new toggle (on, by default) that will send your ship back to the dock if it has no further options for exploration or movement on the map.


[h2]Gas rotary kiln changed to output CO2 instead of exhaust[/h2]
The Gas Rotary Kiln now outputs CO2 instead of your standard Exhaust. This was an oversight when making the advanced recipes as they were not intended to need exhaust cleaning or provide sulfur by-product. This may require changes across your factories so please adjust accordingly!


[h2]Cargo ship changes[/h2]
[h3]Doubled cargo ship capacity and increased cargo throughput[/h3]
We have double the amount of product a cargo ship can contain while also increasing the throughput when unloading at dock. With this, we’ve also doubled the amount of diesel consumed and increased the world mines’ buffer capacity to accommodate. Larger ships are more fuel efficient.
[h3]Reduce ship speed & save fuel[/h3]
Sometimes, ships deliver cargo too fast and the ship is just waiting to unload in the dock. Turns out that in real life, if you are not in a hurry, slowing down can save a significant amount of fuel. This is why we have added a new toggle that reduces ship speed to 50% but also reduces fuel consumption by 30%. This is a great way to reduce diesel consumption for lower priority routes that do not require quicker delivery.


[h2]Contract balancing[/h2]
Many of you gave us feedback that making a self-sustaining colony in the late-game phases is quite challenging due to the way how contracts are designed. We agree that the contracts needed some work so this patch is rebalancing contracts. The most significant changes are:
Added new contract: consumer electronics -> quartz

Increased profit on copper, iron and quartz contracts
Increased profit on contracts selling coal and vehicle parts 2
You can also see other changes in the screenshot below.

If you have further feedback regarding the changes, please let us know!

[h2]Better explanation of nuclear plant fuel rod consumption[/h2]
New UI changes make it easier to understand how nuclear plants consume fuel rods. We saw a lot of players confused on why their plants were consuming multiple rods without starting since we didn’t explain that 16 rods were required before the reactor would even start. This is now shown in the tooltip that breaks down the information to make it easier to understand.


[h2]Prevention of digging through your retaining walls[/h2]
We’ve heard reports from players who were experiencing excavators digging though and behind retaining walls, rendering them useless in some situations.
A post by reddit user u/clarkinum titled “Why excavators digs through the retaining walls? I build those walls before digging only the right side but land kind of slides anyway”.

To prevent this from happening, mining/dumping designations now cannot be placed on tiles that contain retaining walls and vice-versa. This should help avoid excavators and trucks messing up your neatly placed mine walls! We’ve added a console command

toggle_terrain_designations_over_entities

for power users who wish to disable this restriction.
Designations cannot be placed on retaining walls.

An alert message will appear if trying to place a wall over a previously designated zone and you will not be able to place the wall there


Discord user bluetanuki999 submitted this lovely piece a bit late but we still feel it’s worth a share:
Abyss by BlueTanuki999

v0.4.11
New Features
* Unlocked buildings are now highlighted in menus until they are selected for the first time.
* Added an option to auto-return the main ship after exploration when there are no more reachable locations to explore.
* Added a new edict that reduces ship fuel consumption by 10%.
* Added an option to make ships 50% slower to save 30% of fuel per trip.

Cargo ships and contracts balancing
* Increased cargo ship capacity by 2x, fuel consumption by almost 2x. World mines buffers were also increased to accommodate.
* Larger cargo ships are now more fuel efficient per trip.
* Decreased total travel duration of cargo ships from 3.3 to 3 months.
* Increased cargo depot modules unloading speed, the highest tier now unloads the ship in just one month.
* Increased profit on copper, iron and quartz contracts.
* Increased profit on contracts selling coal and vehicle parts 2.
* Added new contract: consumer electronics -> quartz.

Other balancing
* IMPORTANT: Gas rotary kiln changed to return CO2 instead of Exhaust.
* Reduced coal consumption of the silicon recipe in the Arc furnace II by 50%.
* Reduced computing consumption of Arc furnace II from 6 to 4.
* Increased the throughput of Chemical plant for graphite production from CO2 by 2x.
* Reduced transports building duration by 80%.

Other fixes and improvements
* Retaining walls are no longer buildable on terrain designations and vice versa. This should prevent issues with mining/dumping over the walls. A new console command `toggle_terrain_designations_over_entities` can revert this change for power users.
* Renamed "Liquid nitrogen" to "Nitrogen tank" as it is a unit product.
* Fixed UI that was not clickable in some cases in windowed mode.
* Transport snapping is always enabled when no transport is selected. This allows snapping to ports and other transports when starting transport construction.
* Fixed that entities with reserved ocean area such as ocean pump/dump could block ship access of the cargo depot/shipyard indefinitely.
* Fixed the "Recover ocean access" action. Note that all ocean areas will be recomputed after loading this game version which may cause entities being newly blocked or unblocked.
* Improved ocean area recovery action that now shows what is blocking the ocean area if the recovery fails.
* Fixed vehicle dust particles that were not emitted properly in some circumstances.
* Increased vehicle dust particles visibility distance and optimized their rendering.
* Fixed buffers clearing to only clear buffers of unassigned recipes that are not used by any assigned recipe.
* Toggling of planning mode no longer cancels the current building session (e.g. cut & paste).
* Fixed that toggling prod. level on world mine did not reduce workers when it had full buffer
* Fixed a rare case where a settlement transformer would not work for settlements with low population.
* Fixed internal buffers in the Maintenance depot that could accumulate large amounts of maintenance.
* Fixed a rare issue with terrain data serialization that could lead to corrupted save files.
* Fixed incorrect shortcuts shown when insta-copying transports.
* Partial execution for recipes was changed to kick in only when no other recipe can be satisfied fully.
* Added UI showing the state of supply of fuel rods in the nuclear reactor.
* Improved error tooltips and other places for colorblind accessibility.
* Excavators no longer forcibly turn on their lights during game pause.
* Updated translations, thanks to everyone who is contributing!