There was another minor patch this week to fix a couple of issues in the latest update, improve the new thermal visualization system, and add volunteer improvements to Russian and Ukrainian language translations.
Apart from that, I've been investigating a reported memory leak. Several users had reported increasing memory consumption previously, but this week a user described a specific scenario they identified as reproducible.
A memory leak is a situation where a program continuously allocates memory (i.e., creates new objects) over time without properly releasing memory that is no longer being used, eventually exhausting system resources.
Debugging memory usage is a bit tricky. For one thing, memory management works differently in the Unity Editor compared to a build, and this leak didn't seem to happen in the Editor so I had to create a new build to test each new hypothesis. For another, memory usage fluctuates under normal usage both from game related processes as well as the engine unloading resources that have not been accessed in a while.
Here is a snapshot of all objects at a point in time using the memory profiler:
Or rather, the first few dozen objects out of almost half a million.
There are a huge number of objects in memory at all times representing textures, models, vfx, strings, numbers, etc. Basically any data the game is using. (Sometimes data is used briefly and then no longer needed, in which case it should be "recycled" by the garbage collector. There is some performance cost associated with this, so generally one prefers recycling objects to repeated create and remove, but garbage creation is not the same thing as a memory leak as its memory is automatically recovered.)
Looking at the above snapshot, I have no way of immediately recognizing which data might be part of a leak. I did at least have some clues. First, it was probably either something that made big allocations infrequently, or small allocations very often, probably every frame at least. Big allocations every frame would have been identified before, and small allocations infrequently would never exhaust system resources, even if left running for days.
The user had said they had left the game open in the station, which eliminated a large number of possibilities, because most of the game's logic is paused while in the station. This meant that I might be able to find it just by opening the station, taking a memory snapshot, leave the game running, then capturing another snapshot later and comparing the new objects.
I quickly identified one possible memory leak from screenshot thumbnail captures that occurred during automatic game saves, but this was too small and infrequent to be the culprit of a noticeable leak.
After some further investigation I identified some allocations that were the result of an operation that only occurred on the Operations screen (no pun intended), and was complex enough to potentially be hiding some bugs:
In order to display the command staff status and whether their "call button" should highlight, for each actor the conversation system needs to check if they have an active and valid conversation topic, whether it is marked "attract", and whether the player has seen it. This is moderately expensive, but since the Operations Panel is not a performance critical game state, I hadn't spent time optimizing it. I could see no obvious reason why this should leak memory, since all of its memory should be freed after each check. The calls do rely on the Lua interpreter, which is a third party library, so perhaps there was either a bug or interaction that I didn't fully understand.
Without knowing exactly where the memory leak was, I could not fix it, and I'd already spent many hours investigating it. However if it was somewhere within the "call button" check, I could at least mitigate it. There is not a strong need to check the actor button status literally every frame, since it changes infrequently. So I added a cached value and check the state only when the Operations Panel is entered, then every half second thereafter. At 60 frames per second, this would reduce the calls by 97% (and the leak by a corresponding amount if it is the culprit).
Some additional investigation suggests that this leak doesn't always occur on the Operations Panel. It's possible it only happens if the active conversation check has to invoke Lua, or maybe with some specific Lua callback function.
While I like to get to the root cause of bugs, having spent several days on this I may have to satisfy myself in minimizing its harm.
Until next week! - Kevin
Kepler 21508 Minor Update
Kepler 21508 Patch notes:
Compacted module selector layout to fix UI overrun
Further reduced respawning "deadman" station drops
Added volunteer Ukrainian language improvements
Additional volunteer fixes to Russian language translation
Fixed Polish character set issue
Fixed several localization symbol replacement errors
Several minor typos
Weekly Update: Feb 7, 2025
Very quick update this week:
Last week, the new Kepler 21506 update was promoted to default with a lot of new content, QoL improvements, bug fixes, etc. Since then, I posted patch 21507 to address relatively minor issues that have cropped up. The notes from that patch if you missed it are:
Added "resume autopilot" hotkey (default to "I")
Added "turn to mouse" in addition to "steer to mouse" hotkey
Volunteers have provided a number of corrections/improvements to the DeepL Russian translations
I'm currently working on another minor patch which will probably go up in the next day or two.
Until then, thanks for playing! Kevin
Kepler 21507 Patch
Minor patch to the latest update:
Added "resume autopilot" hotkey (default to "I")
Added "turn to mouse" in addition to "steer to mouse" hotkey
Volunteers have provided a number of corrections/improvements to the DeepL Russian translations
Kepler 21506 Update
Starcom: Unknown Space has just gotten a significant update including dozens of new anomalies, several new side-quests and regions, a few new techs and modules and a bunch of fixes / QoL improvements.
Some of the more significant non-spoilery changes in this update:
New Anomalies
There are two dozen+ new anomalies, including a mix of procedural and story-related.
New Missions
There are several new minor quest lines, which I'll leave to players to discover on their own. (See the Existing Games notes below.)
More Guidance
Some of the existing main-storyline missions have gotten a little bit more guidance and hints where players have reported getting stuck.
Trading Change
By request, trading now tracks "fractional" resources during the same trade exchange, so the "spare change" from different resource transactions is combined in the final reserve currency delta.
Plasma Autofire
As an accessibility feature, plasma cannons now have an auto-fire setting in the ship systems so players do not need to hold down the autofire button. Related to this, higher Tactics skill will improve target selection with your plasma turrets more likely to choose targets that pose a greater threat and less likely to oversaturate low-health targets.
Saucer Bridge
A slightly smaller alternative to the Dreadnought, it's lower cost with a slightly lower max size but a higher built-in support crew limit.
Full Kepler 21506 Change List:
25 New anomalies
Several new regions
Several new side quests
Several hint prompts in places where players reported getting stuck
Several new proc planet visuals
New "saucer" bridge module
Added "rename ship/commander" button to Ship's Log
New thermal visualization system, fixed heat not displayed for some modules
Trading now combines fractional values across resources
Steer to mouse bindable hotkey
Plasma autofire setting in ship info
Changes to some AI targeting values
Changes to plasma autofire: higher tactics skill improves target selection
Added lower particle count versions of Havok and Shroud bursts if graphics settings below "high"
Fixed reference issue possibly causing bugs with reloading the latest save
Fog of exploration "refogging" if a region is added to an already explored area
Fix for faction disposition not decaying if faction not loaded
Fix for possible rare soft-lock after Celaeno or Aletheia are destroyed
Fix for proc anomaly addition sometimes overwriting existing anomaly
Modified fixed gun cycle calculation to ensure fire rate is reached
Map color legend for interaction "rings"
Player damage now correctly preserved in saves
Change to VFX object pooling behavior
Various minor mission changes
Various code refactoring
Hovered module build selection now shows details (including for controller)
Fixed numerous missing minor localization strings
Added MIT attribution for Newtonsoft JSON library
Added "DebugMapCoord(string)" command line (shows map coordinates of persistent by id)
Several typos corrected
Enabled third-party download of Steam Workshop items (for GOG players)
Missile speed techs
Kinetic (collision) resistance tech
Angled kinetic armor module
Once the player has researched the Gravity Gun, a small cluster of unstable cores are added near the Chariot
New RP sources added periodically during the game to ensure the player cannot exhaust them before story-critical techs
Prevent one of the final showdown Devouts from spawning atop the player
Guild envoy not showing correct Iridium pricing for Sepharial info
New region now set as Emissary target
Warping now cancels autopilot, like other steering commands
Existing Games
This update is compatible with existing saves, so you do not need to start a new game to experience the new content. Although depending on how far along you are in the game, you may be less likely to encounter it "organically". Also, the more of the universe that you've explored, the less likely it is that you will encounter some of the new procedural anomalies.
I will give one low-spoiler hint for players who have completed or mostly completed the main storyline:
One of the goals of the new content is to guide players to revisit the Guild, who are necessary for two important main-story quests. In order to kick-off one of the new quest lines, you need to trade with the Guild, return to Celaeno, then talk to the Guild again.
These changes have been in testing for a while by opt-in beta testers, so I feel pretty good that there's no major new bugs introduced, but there's always the possibility that something was missed since opt-in testers are a small percent of total players. If you encounter a bug, please report in the discussion forums. And a big shout out to the beta testers!
Thanks for playing, until next week, - Kevin
Weekly Update: Jan 24, 2025
Two weeks ago I posted that there was a new opt-in beta available with a bunch of new content, QoL improvements, bug fixes, etc. Since then, I've released 3 patches to fix various issues players have identified in it.
At this point around 500 players have played at least some of the updated build and there haven't been any major issues reported. So barring any surprise problems, I plan on promoting Kepler 25105 to the default branch in the next week.
If you want to switch to the beta branch now, or want to read a preview of the changes see this discussion post.
Until then!
- Kevin
Weekly Update: Jan 17, 2025
The big news for this week is that Starcom: Unknown Space just hit a lifetime milestone of 100,000 copies sold on Steam!
This was a bit of a surprise for me: two weeks ago, it was at around 75,000. But last weekend it was featured as one of the "Weekend Deals" on Steam. This part wasn't a surprise, I knew it was going to be featured, I just didn't realize how big of a bump that would be. The game had been previously part of a Daily Deal during launch week which produced some additional visibility, but it was a relatively modest boost in comparison. Thanks to everyone for supporting the game!
As a result I've spent more time than usual in the discussion forums this week trying to answer new player's questions, collate new bug reports and feedback, etc. So another big shout-out to players in the forums and discord who've helped answer new players' questions.
Despite the additional community communications, I've made some good progress on a few tasks. As I mentioned last week, there's a new opt-in beta build. Yesterday, I posted an update to that build which fixed a few things and added some QoL enhancements. I haven't heard any major issues introduced by this build; it is compatible with existing saves. Players are welcome to check it out now, with the caveat that there may be bugs.
One of the more time consuming issues was addressing a long-standing bug that prevented some modules from showing thermal effects in the shipyard.
The way ships are rendered in-game is with a custom shader that blends several masking layers together, each multiplied by some color value allowing for faction and player customization. As I talked about in a video entry during EA, there's also an emissive component that handles the glowing for windows and power supplies.
In the shipyard during thermal analysis, this emissive component gets a color added to it to show the heat levels.
At some point I had added an optimized version of the module shader that removed the emissive property for modules that didn't have any glowy-bits. But I forgot that the thermal visualizer was relying on it (it may have been less obvious because most heat generating modules are also emissive).
The simple solution would be to switch all modules to use the emissive version. But this adds a small GPU cost for every pixel of every ship module on screen at all times, even if they never glow outside the shipyard.
Instead I decided to bite the bullet and use a similar trick to the one I used for cloaking ships, where a second material is added but only when needed. Due to the nuances of material stacking, it looks a bit different from the existing thermal analysis. I also added some light mottling for a more entropic appearance.
Additional things worked on this past week:
Steer to mouse bindable hotkey
Plasma autofire setting in ship info
Changes to some AI targeting values
Changes to plasma autofire: higher tactics skill improves target selection
Added lower particle count versions of Havok and Shroud bursts if graphics settings below "high"
Until next week!
- Kevin
Weekly Update: Jan 10, 2025
Starcom: Unknown Space is one of Steam's curated "Weekend Deals" right now, which has brought it in an influx of new players. If this is you, welcome and thanks for playing! Every week I use this space to give an update on what I've been working on, or talk about some aspect of the game's development.
Last week I started a full playthrough of the game to test the new updates/content that I've been teasing for the past month. This was my first complete playthrough since launch. Even using some in-editor dev cheats, this takes quite a while because I'm also noting issues, fixing minor bugs, replaying sections, etc. My save game says it was 11 hours, but actually it was probably closer to 3-4 fulltime working days.
There were a few significant issues, which I addressed. On Wednesday, I uploaded this version (Kepler 21502) to the opt-in beta branch so players can now try it out. It fixes a couple of minor bugs, adds a few QoL features as well as adding some new content, including 25 new anomalies and several new side-quests.
You can find a spoiler-free list of changes and how to switch to the beta here:
Should you switch to this beta now? Well, on the one hand the existing default build is very well tested at this point. On the other hand, the new beta adds additional content and side quests, including new hints and guidance to a few areas where players have found themselves getting "stuck". So if you want the most content and discover even more of the unknown (which might also include unknown bugs), you should switch.
The beta is intended to be compatible with existing saves, although see the notes in the above post for details.
Until next week! - Kevin
Weekly Update: Jan 3, 2025
Happy New Year all!
Over the past couple months I've made a lot of incremental fixes, changes and content additions to my local development version. Every small change has a chance of introducing a bug. So on News Year's Day I started a full playthrough, something I haven't done since launch, with two goals: 1) seeing whether anything has broken and 2) seeing if the collective changes are ready for player testing.
A full playthrough takes quite a while, so I'm only about half way through. I've discovered one new bug that has been in the game for over a year, but was only revealed through a recent change.
Currently, there is a bug where if you load a save, any damage to your ship would instantly repair. So I've fixed that exploit. But in this playthrough I noticed that sometimes I'd reload a save and have damage when there shouldn't have been any.
After investigating, I figured out the cause:
What was going on was that a while ago I added an optimization that cached your most recent save after reading it from disk, so when the player did a quick load or died the save manager could quickly pass that to the game without spending 200ms or so reading it.
The problem is that the various game systems assume that when a game is loaded, they can take any values passed to them and assign them to their respective variables.
For example, if the save file says the player has 2000 RP, then the game sets the player's RP to 2000 RP. This is not a problem and will not cause a bug because RP is an integer and integers are value types. The game can change the amount of RP that a player has, but there's nothing that will change the value of the number 2000.
But some of the data is more complex. Things like the structure of ships are represented as a bunch of ModuleData's. A ModuleData is a collection of value types (HP, rotation, module type, etc) represented as an "object". An object is a reference type, which means that when you pass it around, you aren't passing around copies of various values, you're passing around an address in memory where those values are stored.
So when I loaded the cached save, the save system handed the ship a list of modules which it used to reconstruct my current ship. But when I flew into battle and the enemy started blasting at me, my modules were still referencing the objects in the cached save for their data. Which meant that the enemies were actually damaging the modules my save game.
Now I had designed the save system very much knowing about the possibility of accidentally referencing save data, which is why the save system uses "cloning" to create copies of the game data. But it only does this on the "save" side. I suspect when I implemented the cache I had forgotten this and thought it also happened on the "load" side.
Anyway, I'll be continuing the playthrough for the next day or two. Depending on how that goes I may either spend more time tweaking, or make it available as an opt-in test build. So stay tuned!
Until next week, - Kevin
Weekly Update: Dec 27, 2024
A short update this week as I spent a few days with the family for Christmas.
This week I spent some more time on the side-quests I previously discussed, created several new related anomalies and tackled some bug fixes.
I've previously talked about how I create most anomaly images using an environmental rendering software product called Vue. Earlier this month I got a reminder from the software that my license was about to expire. When I went to renew, I discovered that the company who made the software had been acquired, and development for the product would cease.
On the plus side, they're now giving it away for free. So good on them for that. It still works for my purposes, so I plan on continuing to use it. It's not as general purpose or feature rich as something like Blender (also free), but it is much easier to quickly create cool environment images.
Some anomaly images created with Vue plus some 3rd party models.
Happy holidays and hope everyone has a wonderful New Year!
