HomeGamesUpdatesPricingMethodology
Steam News30 May 20261mo ago

5.811 Unfurling A Neutron Star

Full release notes here. Lots of updates in this one! Many of these are improvements along the lines of the Memory Inferno from a week or two ago.

In this update4

Full notes

Full AI War 2 update

Read the full published notes in a cleaner layout. The original post stays linked below.

What changed

8 fixes2 additions7 changes1 removal
  • Gameplay
  • Fixes
  • Maps
  • Compatibility
  • Performance
  • Store
changedMany of these are improvements along the lines of the Memory Inferno from a week or two ago. However, in this case, the focus was on background threads that generate memory pressure, rather than being on teh main thread itself. The main thread was almost pristine since Memory Inferno, and that has not changed. Similarly, the general GameCommadn framework, which was the hugest source of memory pressure in the past, has still been working great.
addedInstead, this focuses on death by a lot of papercuts, especially in games with a bunch of factions, etc. In those situations, I was measuring 29 MB per second of added GC pressure, which is far less than the high water mark prior to Memory Inferno, but still absolutely huge. This has been cut down to more like 0.7-1.3 MB per second, which is a huge savings. This makes for less contention, and just keeps everything moving along more smoothly.
fixedThe "neutron star" that the title of this build refers to is actually an incredibly-longstanding bug with the AI Instigators faction. If, in the late game, they wanted to expand to other planets but could not, then they would start using a huge amount of cpu time per frame. The details are below, but it was really intense. This was the only faction that had this specific bug, but it was in both the main game and the Classic Fusion total conversion mod, both of which are now fixed. The most it can ever do now is about 6% of what it used to, which leads to perfect sim speeds on most systems.
fixedAs part of that fix, I also made other changes to prevent anything egregious from any other factions, but they were already at the point where they would at worst dip the sim speed to 85% or so every 5-30 seconds, versus hammering it down to 40% or less constantly. Those were still nonideal, but nowhere near so intense. Anyway, they're all resolved now.
changedCode ImprovementsImproved a number of the Fireteam methods to no longer require closures that cause GC alloc pressure, but which still retain the "remove and continue" logic that is more complex than a simple foreach would normally allow for. This helps to reduce the largest source of background-thread GC pressure, although it's not entirely solved.
changedCode ImprovementsImproved some common code that runs on the galaxy map to not throw more RAM usage than needed.

AI War 2 changes

changedMany of these are improvements along the lines of the Memory Inferno from a week or two ago. However, in this case, the focus was on background threads that generate memory pressure, rather than being on teh main thread itself. The main thread was almost pristine since Memory Inferno, and that has not changed. Similarly, the general GameCommadn framework, which was the hugest source of memory pressure in the past, has still been working great.
addedInstead, this focuses on death by a lot of papercuts, especially in games with a bunch of factions, etc. In those situations, I was measuring 29 MB per second of added GC pressure, which is far less than the high water mark prior to Memory Inferno, but still absolutely huge. This has been cut down to more like 0.7-1.3 MB per second, which is a huge savings. This makes for less contention, and just keeps everything moving along more smoothly.
fixedThe "neutron star" that the title of this build refers to is actually an incredibly-longstanding bug with the AI Instigators faction. If, in the late game, they wanted to expand to other planets but could not, then they would start using a huge amount of cpu time per frame. The details are below, but it was really intense. This was the only faction that had this specific bug, but it was in both the main game and the Classic Fusion total conversion mod, both of which are now fixed. The most it can ever do now is about 6% of what it used to, which leads to perfect sim speeds on most systems.
fixedAs part of that fix, I also made other changes to prevent anything egregious from any other factions, but they were already at the point where they would at worst dip the sim speed to 85% or so every 5-30 seconds, versus hammering it down to 40% or less constantly. Those were still nonideal, but nowhere near so intense. Anyway, they're all resolved now.
changedImproved a number of the Fireteam methods to no longer require closures that cause GC alloc pressure, but which still retain the "remove and continue" logic that is more complex than a simple foreach would normally allow for. This helps to reduce the largest source of background-thread GC pressure, although it's not entirely solved.

Full release notes here.

Lots of updates in this one!

Many of these are improvements along the lines of the Memory Inferno from a week or two ago. However, in this case, the focus was on background threads that generate memory pressure, rather than being on teh main thread itself. The main thread was almost pristine since Memory Inferno, and that has not changed. Similarly, the general GameCommadn framework, which was the hugest source of memory pressure in the past, has still been working great.

Instead, this focuses on death by a lot of papercuts, especially in games with a bunch of factions, etc. In those situations, I was measuring 29 MB per second of added GC pressure, which is far less than the high water mark prior to Memory Inferno, but still absolutely huge. This has been cut down to more like 0.7-1.3 MB per second, which is a huge savings. This makes for less contention, and just keeps everything moving along more smoothly.

The "neutron star" that the title of this build refers to is actually an incredibly-longstanding bug with the AI Instigators faction. If, in the late game, they wanted to expand to other planets but could not, then they would start using a huge amount of cpu time per frame. The details are below, but it was really intense. This was the only faction that had this specific bug, but it was in both the main game and the Classic Fusion total conversion mod, both of which are now fixed. The most it can ever do now is about 6% of what it used to, which leads to perfect sim speeds on most systems.

As part of that fix, I also made other changes to prevent anything egregious from any other factions, but they were already at the point where they would at worst dip the sim speed to 85% or so every 5-30 seconds, versus hammering it down to 40% or less constantly. Those were still nonideal, but nowhere near so intense. Anyway, they're all resolved now.

Enjoy!

5.811 Changelog

Code Improvements

  • Extended display_name_for_sidebar to work on things other than just ships.

  • Improved a number of the Fireteam methods to no longer require closures that cause GC alloc pressure, but which still retain the "remove and continue" logic that is more complex than a simple foreach would normally allow for. This helps to reduce the largest source of background-thread GC pressure, although it's not entirely solved.

  • Improved some common code that runs on the galaxy map to not throw more RAM usage than needed.

  • Completed the work from Memory Inferno where I got rid of the gc-pressure-causing DoFor methods and converted those all into foreach methods. All of the mods that are active have also been updated to use this new format, and so the older DoFor methods have actually been fully-removed this time, rather than retained for backwards compatibility. There's nothing that should have been using them now, and they were actively causing a ton of memory pressure during heavy gameplay.

  • When the game writes to debug logs for any reason, it's now using notably less memory. There were cases where a big cascade of writes could use 400kb in a single set of calls (19 delayed from background threads, for example), and it's now very efficient, instead.

  • If ConcurrentDictionary is already empty when Clear() is called on it, it no longer allocates memory in rebuilding its tables for no reason.

  • Cleared up a variety of other sources of memory pressure from background threads -- there were several dozen patterns. I now am seeing 0.7-1.3MB/sec of gc allocation during heavy gameplay, whereas before this weekend I was seeing 29MB/sec. This is after the other intense reductions from the Memory Inferno update, so these are really high savings in this build!

  • Adjusted how the list of mods are written to your log when you start the game. It just shows a list of the enabled ones, rather than showing a list of all possible mods and whether they are enabled or disabled. This makes it vastly easier to understand from the log what is happening.

Bugfixes

  • Fixed an issue in the Extended Ship Variants mod where Polarazer was renamed to Polarizer, thus causing problems.

  • Fixed the Reclaimers mod to no longer error on startup due to having a name that was too long for sidebars.

  • Fixed an issue where if a Neinzul Custodian faction does not load properly, that it would fully error-out the entire savegame's load process.

  • Fixed an issue where if a parent faction's child faction was not properly linked in a savegame for some reason, it would fail to re-link to them and would instead create duplicates. It now properly links up, and all is well.

  • Fixed a bug with the AI Instigators, where they would run an insanely-expensive GetPlanetForInstigatorBase() call once per second, and it would take the length of like two full sim steps just to run this if there was no valid location to be found. It's now gated to just run once every 30 seconds or so if it fails, which makes the performance jump to 100% immediately, but with dips every 30 seconds or so to 70-90% sim speed. That still needs fixing, but this is a good start. The problem logic is used here and a number of other places, and it basically does a full scan of all the planets, and then a scan of every linked planet to each planet, with a bunch of other logic, and also with ONE HUNDRED RETRIES that all fail. As the retry count increases, the restrictions are relaxed, so in theory one would hit for a while, but then once we hit a few hours in, that stops working. This is not the only place in the game where this happens, so this is pretty much the smoking gun for a lot of the remaining "late-game performance suddenly tanks" type savegames, I suspect.

  • Gated the AI Instigators to only 6 retries when they are doing an expensive search across planets. Also adjusted a bunch of other factions to gate them in the same way. This should allow for the "relaxes over retries" logic to kick in like it did before, but also cuts the load that comes from a complete failure to be exactly 6% of what it was before. In the case of the instigators, it was taking 460ms or so, and that should now be only 28ms on average, which takes it from being a big downspike every 30 seconds to not really being anything that registers at all.

  • Fixed a bug that could happen when loading a save and the planet gravwell size was null for some reason.

Heart of the Machine 1.0 Is Out Now!

https://steamcommunity.com/games/2001070/announcements/detail/538879349212841215 https://steamcommunity.com/ogg/2001070/announcements/detail/664986477286917109

https://store.steampowered.com/app/2001070/Heart_of_the_Machine/

Source

Steam News / 30 May 2026

Open original post

Changelog.gg summarizes and formats this update. How we read updates.