KSP2 Redux

[KincaidFrankMF]

On 2/28/2025 at 8:43 PM, munix said:

We will definitely try to tweak some things here and there and do some QoL improvements, but large-scale reworks of the UI are not currently planned, it would be a massive undertaking, since modifying existing UI is already quite difficult, and completely rewriting it from scratch would put us back months, if not years

Redux sounds awesome, thanks for stepping up this way - I'm sure it means a lot to the whole community, jaded as we are.

You mention that modifying the UI would be difficult, does this include the science UI? The new science reports are actually deeply cool, but hidden behind such a nauseatingly awful interface that new players often don't even see them. It's off-putting even once you're used to it. Any chance of introducing some simple KSP1-style pop-ups instead?

[NexusHelium]

6 hours ago, Alpha_star said:

This is what interested me the most.

https://imgur.com/a/sjLN1nv

Does that mean you will fix reentry flame colors?

[SkyHook]

A world where KSP2 is revived is a dream! Obviously, I am skeptical given how KSP2 has ended up. But I support what you all are doing, and I will be watching (and hopefully participating at some point) with GREAT interest!  

[AtomicTech]

Best of luck y'all!

[MrG]

First of all, this is amazing. I hope you're able to accomplish what you want!

I don't understand one thing. How can you make all these changes without access to the original source? I thought modding was limited to additions/some changes but could not have a giant impact on performance since the core functionality isn't accessible.  

[CKIDOW]

Quote

A little less conversation. A little more action.

 

[SpaceMonkeez]

Around how far along will we be able to test using our mods within the redux? I’d hate to dive too deep into something just to have it break.
 

Redux would obviously take priority for most people understandably. I wouldn’t try to change that with a minor addition to the game.

[SpaceMonkeez]

On 3/3/2025 at 11:38 AM, MrG said:

First of all, this is amazing. I hope you're able to accomplish what you want!

I don't understand one thing. How can you make all these changes without access to the original source? I thought modding was limited to additions/some changes but could not have a giant impact on performance since the core functionality isn't accessible.  

Anything is possible with a keyboard buddy.. and lots of time and stress lol I know they will get something to us and it will only snowball from there. It’s a good team of people that’s involved from the looks of it.

[munix]

2 hours ago, SpaceMonkeez said:

Around how far along will we be able to test using our mods within the redux? I’d hate to dive too deep into something just to have it break.
 

Redux would obviously take priority for most people understandably. I wouldn’t try to change that with a minor addition to the game.

There are some breaking changes in the modding API between SpaceWarp 1.9 and Redux, but honestly not very many, it mostly has to do with logging and configuration values, but as far as most other APIs go, it's still the same, so you should be safe making your mod, and then just adapting it very quickly for Redux. We'll also try before the release to go back and help modders update their mods so that when it does come out, most will be ready and supported

[SpaceMonkeez]

1 hour ago, munix said:

There are some breaking changes in the modding API between SpaceWarp 1.9 and Redux, but honestly not very many, it mostly has to do with logging and configuration values, but as far as most other APIs go, it's still the same, so you should be safe making your mod, and then just adapting it very quickly for Redux. We'll also try before the release to go back and help modders update their mods so that when it does come out, most will be ready and supported

Wouldn’t have thought otherwise but still happy to hear. I look forward to watching the progress as it releases.

[ILikeToBlowStuffUp37]

Have you ever heard of something called DnSpy? It's a combination decompiler and editor that recreates the source from the dll files. This can then be edited and recompiled into a modified version of the dll file.

[munix]

11 hours ago, ILikeToBlowStuffUp37 said:

Have you ever heard of something called DnSpy? It's a combination decompiler and editor that recreates the source from the dll files. This can then be edited and recompiled into a modified version of the dll file.

Yup, in fact I'd say that most if not all KSP2 modders have some experience with similar tools 

[foonix]

Redux Update: Performance -- How the little things add up

Redux contains lots of small performance improvements.  Many of them, honestly, wouldn't be noticed by the player individually.  However, they do add up.

I wanted to share some small performance tweak examples, and show how they combine.  Most of these are intended to address the speed of background (and foreground) vessel updates, so I use the infamous "2500 background parts" test to analyze improvements.

Change 1: Reducing GUID handling overhead in ThermalComponentJob

`ThermalComponent`'s purpose is to update the temperature of every part in the game based on the conditions it is being subject to.  To do that efficiently, it runs an off-thread job called `ThermalComponentJob`, which moves the calculations off of the main thread and onto background threads.  The actual calculations are done in in very fast Burst code, which is great work.

The job is loaded up, put "in flight" for the rest of the frame, and is recovered on the next frame.  This means that the only overhead on the main frame loop is loading and unloading the job data. To do that, any data relevant to thermal calculations has to be scraped from the simulation and copied to the job.  Unity jobs can't directly use normal c# objects, so the code uses GUIDs for the parts to identify after the job is done which temperature goes with which part.

What If found is that the process was doing some unnecessary conversions of the GUIDs.  It was converting the Guid from KSP2's `IGGuid` struct to a burst-friendly struct called FixedBytes16.  That's not a bad idea in and of its self.  The Burst resulting code job code was very fast.

However, the slow part was the conversion.  I ran some experiments, and it turns out that Burst can handle `IGGuid` just fine.  So I change the code to just copy the IGGuid directly to the job, and it cut out a lot of conversion overhead from the main thread.  As a bonus, it also reduced memory allocations the converter was doing, making the code more "eco friendly."  The new code simply copies the GUID struct into the job.  No fuss, no muss.

Change 2: Improving orphaned part scanning.

Near the end of every frame, the game scans all of the parts in the game to check that they belong to a vessel.  That is, every part should have an "owner."  If there is no owner, then the part is promoted to being a vessel in its own right.  This is how the game handles situations like parts that have broken off, or some error leads to invalid parts floating around.

It might be possible to completely delete this check.  However this requires very careful consideration of every possible situation that might lead to a part becoming orphaned.  So for now, I leave the basic loop in.

But I found that it was scanning every sim object in the game in an inefficient way.  It would walk each sim object, check if it had PartComponent (hash table lookup), then check if it was on a vessel.  It turns out that the simulation code already has code that keeps track of every sim object that has a PartComponet, and provides an iterator that directly yields the PartComponent.  So I changed the code to use that,  and did a few other micro optimizations to the loop to cut down on branch conditions and memory access.

Change 3: DeltaVStageInfo

One of the background updates is to check the delta-V for the vessel.  This doesn't run every frame; It runs periodically every few frames.  But when it does, oh boy, it's pretty slow.  It causes a several millisecond spike that can contribute to frame drops.  So I looked for simple ways to improve it and found one.

One of the things the code does is maintain a list of parts that could affect delta-V.  When it recalculates the data, it has to check if the parts it its data still exists on the vessel.  It did that by looping over its own data, then looping over the vessel part list to see if the list still has it.

But it turns out the vessel already keeps track of the parts in a `Dictionary<T>` by the part's GUID.  So I changed the code to use the dictionary instead of the parts list in order to avoid the loop scaling badly with part count.

In programmer terms: This is roughly changing from `O(N^2)` (with the part-per-vessel count) to `O(N)`.  Our data set was not very big, and the lookup was pretty fast, so it was not really that noticeable of an issue.  But in the 2500 part test, each background vessel has about 250 parts, so it scales particularly badly in this test.

Change 4: Reduce DataContext garbage.

KSP2 has a really interesting system to connect the simulation to the GUI that shows the player what is happening.  It's a good idea, but I think that there are areas where the implementation of the idea can be improved.  Eventually a larger overhaul is probably justified, but for now I just take swipes at it to improve small issues when the jump out at me.

I found one spot where it is parsing some strings, and it turned out to be doing some unnecessary conversion between a `List<string>` and `sting[]`.  It was a simple change to make it just return the list directly, so I did that.

The actual performance change here is absolutely microscopic.  We're talking a few hundred nanosconds per conversion, and maybe a few 100's of microseconds on the total frame loop.  However, in the broader context of reducing overhead and garbage, chipping away at even 0.1ms is worth it, especially when the actual change is a very simple, low-risk change to just a few lines of code.  A 60 fps frame only gets 16.6ms to work with, so you've got to fight for every 0.1ms or you're just not going to make it!

Putting it all together:

Since these changes are intended to reduce the background vessel overhead, I profiled the changes using the infamous "2500 background parts" test, and compare the results against the current Redux development branch.  As usual, the comparison is statistical aggregate over 299 frames.  I normally like to compare the median times, however due to DeltaVStageInfo only running periodically, it's useful to compare the mean instead.

We arrive at about %12.6 reduced overhead for these changes alone.  Total changes in this test are at %22.57 from stock+spacewarp.  

Note that this percentage is a bit lower than my previous post; Tests with heavy foreground vessel activity are way more dramatic.  I haven't specifically targeted background vessel overhead, but some prior changes did improve it.

Subjectively:  These changes make the game feel a lot less "chunky" due to the reduction in overhead spiking.  Garbage is reduced from ~0.7MB per frame to ~40KB per frame, which again helps with the frame drop issue due to less frequent GC pausing. (The total garbage change from stock to redux in this test is about 1MB/frame.)

All tests are on my i7-4790K @ 4Ghz.
 

	FPS (mean)	ms/frame (mean)	ms/frame (median)
KSP2+SpaceWarp	15.74	63.53	58.67
Redux (develop branch)	16.83	59.42	52.92
Redux (this branch)	21.66	46.17	45.43

 

Receipts (screen shots from profiler analyzer)

Redux develop branch (blue/left) vs these changes (orange/right).

Spoiler

KSP2+SpaceWarp (blue/left) vs these changes (orange/right).
Notice the frame timeline graph at the top here is very spiky. 

Spoiler

 

Edited March 17 by foonix
fix typo

[KiwiShark]

Praise be, a certified Foopost for us to feast upon.

[NexusHelium]

Foonix doing the Foonix thing

Edited March 17 by NexusHelium

[moguldogul]

Hi Everyone, can I be part of testing group? Or is it possible to test it anywhere right now?

Thank you

Jiri

[SpaceMonkeez]

On 3/16/2025 at 7:31 PM, foonix said:

Redux Update: Performance -- How the little things add up

Redux contains lots of small performance improvements.  Many of them, honestly, wouldn't be noticed by the player individually.  However, they do add up.

I wanted to share some small performance tweak examples, and show how they combine.  Most of these are intended to address the speed of background (and foreground) vessel updates, so I use the infamous "2500 background parts" test to analyze improvements.

Change 1: Reducing GUID handling overhead in ThermalComponentJob

`ThermalComponent`'s purpose is to update the temperature of every part in the game based on the conditions it is being subject to.  To do that efficiently, it runs an off-thread job called `ThermalComponentJob`, which moves the calculations off of the main thread and onto background threads.  The actual calculations are done in in very fast Burst code, which is great work.

The job is loaded up, put "in flight" for the rest of the frame, and is recovered on the next frame.  This means that the only overhead on the main frame loop is loading and unloading the job data. To do that, any data relevant to thermal calculations has to be scraped from the simulation and copied to the job.  Unity jobs can't directly use normal c# objects, so the code uses GUIDs for the parts to identify after the job is done which temperature goes with which part.

What If found is that the process was doing some unnecessary conversions of the GUIDs.  It was converting the Guid from KSP2's `IGGuid` struct to a burst-friendly struct called FixedBytes16.  That's not a bad idea in and of its self.  The Burst resulting code job code was very fast.

However, the slow part was the conversion.  I ran some experiments, and it turns out that Burst can handle `IGGuid` just fine.  So I change the code to just copy the IGGuid directly to the job, and it cut out a lot of conversion overhead from the main thread.  As a bonus, it also reduced memory allocations the converter was doing, making the code more "eco friendly."  The new code simply copies the GUID struct into the job.  No fuss, no muss.

Change 2: Improving orphaned part scanning.

Near the end of every frame, the game scans all of the parts in the game to check that they belong to a vessel.  That is, every part should have an "owner."  If there is no owner, then the part is promoted to being a vessel in its own right.  This is how the game handles situations like parts that have broken off, or some error leads to invalid parts floating around.

It might be possible to completely delete this check.  However this requires very careful consideration of every possible situation that might lead to a part becoming orphaned.  So for now, I leave the basic loop in.

But I found that it was scanning every sim object in the game in an inefficient way.  It would walk each sim object, check if it had PartComponent (hash table lookup), then check if it was on a vessel.  It turns out that the simulation code already has code that keeps track of every sim object that has a PartComponet, and provides an iterator that directly yields the PartComponent.  So I changed the code to use that,  and did a few other micro optimizations to the loop to cut down on branch conditions and memory access.

Change 3: DeltaVStageInfo

One of the background updates is to check the delta-V for the vessel.  This doesn't run every frame; It runs periodically every few frames.  But when it does, oh boy, it's pretty slow.  It causes a several millisecond spike that can contribute to frame drops.  So I looked for simple ways to improve it and found one.

One of the things the code does is maintain a list of parts that could affect delta-V.  When it recalculates the data, it has to check if the parts it its data still exists on the vessel.  It did that by looping over its own data, then looping over the vessel part list to see if the list still has it.

But it turns out the vessel already keeps track of the parts in a `Dictionary<T>` by the part's GUID.  So I changed the code to use the dictionary instead of the parts list in order to avoid the loop scaling badly with part count.

In programmer terms: This is roughly changing from `O(N^2)` (with the part-per-vessel count) to `O(N)`.  Our data set was not very big, and the lookup was pretty fast, so it was not really that noticeable of an issue.  But in the 2500 part test, each background vessel has about 250 parts, so it scales particularly badly in this test.

Change 4: Reduce DataContext garbage.

KSP2 has a really interesting system to connect the simulation to the GUI that shows the player what is happening.  It's a good idea, but I think that there are areas where the implementation of the idea can be improved.  Eventually a larger overhaul is probably justified, but for now I just take swipes at it to improve small issues when the jump out at me.

I found one spot where it is parsing some strings, and it turned out to be doing some unnecessary conversion between a `List<string>` and `sting[]`.  It was a simple change to make it just return the list directly, so I did that.

The actual performance change here is absolutely microscopic.  We're talking a few hundred nanosconds per conversion, and maybe a few 100's of microseconds on the total frame loop.  However, in the broader context of reducing overhead and garbage, chipping away at even 0.1ms is worth it, especially when the actual change is a very simple, low-risk change to just a few lines of code.  A 60 fps frame only gets 16.6ms to work with, so you've got to fight for every 0.1ms or you're just not going to make it!

Putting it all together:

Since these changes are intended to reduce the background vessel overhead, I profiled the changes using the infamous "2500 background parts" test, and compare the results against the current Redux development branch.  As usual, the comparison is statistical aggregate over 299 frames.  I normally like to compare the median times, however due to DeltaVStageInfo only running periodically, it's useful to compare the mean instead.

We arrive at about %12.6 reduced overhead for these changes alone.  Total changes in this test are at %22.57 from stock+spacewarp.  

Note that this percentage is a bit lower than my previous post; Tests with heavy foreground vessel activity are way more dramatic.  I haven't specifically targeted background vessel overhead, but some prior changes did improve it.

Subjectively:  These changes make the game feel a lot less "chunky" due to the reduction in overhead spiking.  Garbage is reduced from ~0.7MB per frame to ~40KB per frame, which again helps with the frame drop issue due to less frequent GC pausing. (The total garbage change from stock to redux in this test is about 1MB/frame.)

All tests are on my i7-4790K @ 4Ghz.
 

	FPS (mean)	ms/frame (mean)	ms/frame (median)
KSP2+SpaceWarp	15.74	63.53	58.67
Redux (develop branch)	16.83	59.42	52.92
Redux (this branch)	21.66	46.17	45.43

 

Receipts (screen shots from profiler analyzer)

Redux develop branch (blue/left) vs these changes (orange/right).

  Reveal hidden contents

KSP2+SpaceWarp (blue/left) vs these changes (orange/right).
Notice the frame timeline graph at the top here is very spiky. 

  Reveal hidden contents

 

So what you’re saying is that because I’m already getting super great FPS I can now tank my install when Redux drops? lol jk can’t wait to get some QoL in the overpriced framework we all bought (even though I only paid $15)