KSP2 Redux | Blog

SAS Improvements

Tue, 28 Apr 2026 13:00:00 GMT

Hello all, I thought I’d write a quick blog post summarizing the main changes that we’ve done to SAS in KSP2 Redux, as I think it’d make for an interesting semi-technical overview.

Background

You might think that we could’ve just ripped KSP1’s SAS system into KSP2, but that approach would not have worked, mainly given that the core of the SAS logic in KSP2 is the same algorithm as it is in KSP1.

So then, why is SAS so stable in KSP1 while it is in KSP2, if the core is the same?

The simple answer is, it has to do with how data is fed into the SAS system, and how its outputs are applied to the controls, there has to be differences in there, maybe the data coming in is stale, or maybe the outputs are being applied differently. And this is what guided our changes and our investigations into the differences in the 3 main passes we looked into the SAS system.

Pass 1 - First Misguided Attempts

When I was first looking into the SAS differences, I started trying to look at how the outputs were applied, and I made the mistaken assumption that the SAS outputs were somehow going through Unity’s input system, and as such the outputs were being smoothed in a way that they weren’t in KSP2, so I tried replicating that input system to see if it improved this. The replication itself just made all the inputs feel sluggish and not fun to play with, and it did not even fix the issues with SAS in the first place, as such these changes were scrapped.

Though, I’m still mentioning this because one improvement did come out of this pass of looking at it, the stability improvements for command pods/probe cores that are the sole part of a vessel. Essentially, what was going on there was that the moment of inertia calculations for a single part were using unity’s own moment of inertia calculations directly, while every other case would apply some form of scaling to the moment of inertia based off of mass, so what I did here was just mirror the mass scaling for this case.

Pass 2 - Telemetry and other Improvements

Main Article: SAS, Flight Input, and Precision Mode

For this pass, we looked deeper into how the algorithm worked, and the data that is being fed into it, and there were 3 main things we noticed and subsequently fixed for Beta 5.

Coasting Logic The coasting logic in KSP2 was worse than KSP1 at predicting overshoots.
SAS Update Order The SAS commands were being sent out to the modules after the modules had updated their state for the frame, meaning they’d be applied later than before.
Telemetry Data The telemetry data being fed to the SAS was in the Update loop, meaning during time warp it would not be fresh, leading to stability issues

(More information on these changes can be found in the main article by Munix)

Pass 3 - Rigidbody Update Changes

The prior changes still weren’t enough to bring the SAS on par with KSP1’s performance and stability, so we decided to look further into it to see anything else that could be an issue, again focusing on the inputs to the SAS system, and where the outputs are going. By comparing this to KSP1, we found one crucial difference, which will require a bit of explanation.

ITorque

KSP2 Introduced interfaces for parts that apply torque and other forces to the main rigidbody that were not present in KSP1, in KSP1 all parts did these on their own immediately in their update cycle.

This change was part of what introduced the instability that this pass fixed, as this torque was no longer being applied immediately.

The Rigidbody Update Behaviour

So when was it being applied? During the RigidbodyBehaviour’s OnFixedUpdate method near the beginning of a physics update. The entire relevant loop, including other modules, looking something like

Begin the physics update
Copy Unity’s Rigidbody state into the data used for the simulation
Write back the current torque being provided by ITorque components and other forces to the Unity Rigidbody
Use the data copied in step 1 to update the SAS commands (SAS module)
Use the SAS commands to update part torque output (Parts with ITorque)
End the physics update

As can be seen in the loop, the actual torque output was not being applied until the next frame and the SAS was getting data fed into it that was read before these outputs were applied, so it had stale data and an output lag.

The Fix

The fix to this was quite simple, we just had to give the RigidbodyBehaviour 2 slots in the update cycle, rather than just one, keeping the early update for reading the data into the simulation state, then applying the outputs later in the cycle when everything has had a chance to update their torque and other physics outputs.

Meaning that the new correct loop in Beta 5 Hotfix 2 looks something like:

Begin the physics update
Copy Unity’s Rigidbody state into the data used for the simulation
Use the data copied in step 1 to update the SAS commands (SAS module)
Use the SAS commands to update part torque output (Parts with ITorque)
Write back the current torque being provided by ITorque components and other forces to the Unity Rigidbody
End the physics update

v0.2.3 Beta 5 Hotfix 2

Tue, 28 Apr 2026 00:00:00 GMT

v0.2.3 Beta 5 Hotfix 2

We have just released the second hotfix for the 5th beta of KSP2 Redux, which includes a bunch of minor bug fixes as well as further improvements to SAS stability.

You can install the update in the Updater application (If you don’t have it yet, download on the Updater GitHub page). - Simply select the newest beta (highest number) in the dropdown and click Install.

You can find the full changelog on the Redux GitHub page or on Discord: https://discord.com/channels/1078696971088433153/1444156522127954064/1498461514145730750.

v0.2.3 Beta 5 Hotfix 1

Sun, 26 Apr 2026 00:00:00 GMT

v0.2.3 Beta 5 Hotfix 1

We have just released a hotfix for the 5th beta of KSP2 Redux, which includes a fix for issues with Chinese, Japanese and Korean, Color Manager presets disappearing, adds 3 new missions, and a couple more bug fixes.

You can find the full changelog on the Redux GitHub page or here on Discord: https://discord.com/channels/1078696971088433153/1444156522127954064/1497756315089637488.

v0.2.3 Beta 5

Sat, 25 Apr 2026 00:00:00 GMT

v0.2.3 Beta 5

We have just released the 5th beta of KSP2 Redux, which includes an upgrade of the game’s Unity version from 6000.3.10f1 to 6000.4.1f1, an early release of the modding SDK, an experimental KSP1 part mod loader, first few SM+ size (1.875m) parts, support for Discord rich presence, game statistics tracking, custom flags, improved SAS and flight controls, and as always, a ton of bugfixes.

You can download the new Updater application on the Updater GitHub page. This application will now be the primary way of installing, updating and uninstalling KSP2 Redux. New installation instructions are available on the Redux GitHub page.

You will need a stock install of KSP2 0.2.2 for the initial install (meaning you CANNOT upgrade from beta 4), but this won’t be the case for any future updates, those will just be installed on top of beta 5.

You can find the full changelog on the Redux GitHub page.

Along with this new release and the (at this point almost mythical) Updater/Launcher application, we have also been working on the new website: https://ksp2redux.org, as well as on updating the modding SDK and template project for Unity 6+. You can find the instructions to set up the modding environment here: https://docs.rendezvous.dev/s/0a4a3e31-0b40-48e0-bd81-e14856f80d3d/doc/getting-started-with-modding-ea0cMbSQ3V.

Custom flags can be added to the game by creating a new folder inside your Redux install’s mods folder. You can call this anything, e.g. MyMod. Then, inside it, create a flags folder, and put your flag files in (ideally PNG). On the next game launch, you should see the flags in the campaign creation menu.

KSP1 part mod import can be tested by creating a folder called KSP1 inside mods, and then putting KSP1 mod folders inside it (generally, whatever folder would go into GameData in KSP1 will go into the KSP1 folder). Please, keep in mind that this is a very experimental initial version of this feature, and it is meant to serve as more of just a tech demo for the future KSP1 mod porting Unity tools that we are working on, meaning we won’t be providing support for mods that are not working properly or breaking the game.

API Documentation Pipeline Update

Tue, 21 Apr 2026 00:00:00 GMT

A short dev update from what ive been doing for today:

I have been working on our workflow to automatically generate API documentation from the doc comments we write in the code.

This is not as simple as it may seem because unity does not have any way to export the xml documentation like msbuild would normally have, so instead I had to force unity in the CI pipeline to generate the project files as it would with rider, then have a modern dotnet sdk build the files to generate the documentation files, which took a lot of fanangling as you might imagine (i even had to write a script to selectively fix an error for this step that only occurs when using the dotnet sdk).

Then later on in the CI/CD pipeline, I invoke docfx to build all the documentation, and push to a github repo (for ease of hosting it on our own domain).

You can see current documentation here: http://api.ksp2redux.org/

This is for the develop branch so it wont accurately reflect whats in the beta, however once the next beta is out it will redirect for that beta.

Project Shakespeare

Mon, 20 Apr 2026 00:00:00 GMT

Everyone, meet The Secret Feature™, or as we like to call it, Project Shakespeare (to honor the never-implemented, never-explained mod type called Shakespeare that can be found in the stock game’s code).

This is a very basic KSP1 part-only mod loader with currently mostly functional command modules, deployables and animations, decouplers, fuel tanks, engines, gimbals, plumes, engine mode switching, variant switching, and more. It includes support for some popular modded part modules as well, such as B9 part switching and animated decouplers.

There’s a lot that doesn’t work properly yet, such as WIP control surfaces (that’s why I didn’t put on the grid fins yet, as they result in a funny, although very motion sickness-inducing death spin), or RCS thrusters. Engine plumes are also just using the default KSP2 methalox plume attached in place of where the KSP1/Waterfall plume would be, and for some parts (e.g. the booster fuel tank in the video) the textures don’t look right, either.

IMPORTANT: this is NOT going to be a “plug-and-play” feature where you just copy all 300 of your KSP1 mods into the Redux folder and can play without any issues. It is extremely limited with a small selection of part modules and types that it can handle, it’s only able to do handle basic Module Manager patching logic in order to support things like engine plumes defined in MM patches instead of the base .cfg file (which is a pattern often used in KSP1 mods), and also, it’s EXTREMELY slow. I’ve seen loading times of like 2-3 minutes with 3 part mods, and that will possibly get even slower as I iterate on it more and introduce more module translations and other functionality (though it can be somewhat mitigated by the caching of translated parts and modules).

The purpose of this feature is to be a proof-of-concept, technical demo that lets your imagination run wild with what could be possible if your favorite KSP1 mod authors ported their mods for KSP2 for real, and it also serves as a technical showcase of what sorts of authoring and conversion tools we can and will provide to KSP1 mod developers to help them with the process of converting their mods over to KSP2 Redux.

Note: this will not be a part of beta 5, you’ll need to wait a bit longer for us to polish this more.

Mods used in the showcase are Tundra Exploration and Kerbal Reusability Expansion, some of my favorite KSP1 mods.

Media

https://www.youtube.com/watch?v=RfoKk3MYoxk

SAS, Flight Input, and Precision Mode

Fri, 17 Apr 2026 00:00:00 GMT

Decided to take a short break from Redux (working on the rendering pipeline) and, for a change, work a bit on Redux. This time, I looked at a few flight-control related things:

SAS oscillations
Flight input
Precision mode

The main one is SAS. In stock KSP2, SAS has a tendency to oscillate a lot more than it did in KSP1, especially on vessels with a lot of control authority, meaning that rockets and planes can sometimes wobble back and forth instead of smoothly settling in the target direction. This gets especially noticeable under physics warp.

After comparing the KSP1 and KSP2 implementations, the PID controller used for SAS is basically the same, and not really an issue. The bigger differences are in the surrounding logic: how SAS estimates when it should stop pushing, when the flight control state gets updated, and how often the telemetry system updates data that SAS needs.

The first fix was related to the “coasting” logic. Basically, SAS needs to predict when the vessel is already rotating fast enough that it should stop applying torque and let itself coast into the target direction. KSP2 had a small difference from KSP1 here that made it worse at predicting overshoot, so it would often push for too long, overshoot, correct back, overshoot again, and so on. Fixing the formula here to match KSP1 helped with making vessels settle down instead of wobbling forever.

The second fix was about timing. Gimbals, control surfaces, reaction wheels, RCS, etc. all consume the flight control state during FixedUpdate, and with this change, SAS now updates that control state earlier in the fixed update order. That means parts are working with fresher SAS commands, instead of commands that are slightly behind what the vessel is currently doing.

There was also a fun little physics warp rabbit hole. SAS depends on telemetry data, but that was normally refreshed through the regular Update path (there’s always 1 Update per frame, so the frequency changes with FPS). Under physics warp, especially at lower FPS, you can get multiple FixedUpdate ticks between regular Updates (FixedUpdate is, as the name suggests, fixed - by default at 50 per second - and it scales with time warp speed), meaning SAS ends up acting on stale telemetry data. This was fixed by updating the necessary telemetry data on FixedUpdate instead of Update.

Outside of SAS, I also tweaked the manual flight inputs. Stock KSP2 input is very instant, which can feel a bit twitchy with keyboard controls. The updated version is closer to KSP1, where pitch/yaw/roll ramp up and decay back down instead of snapping immediately to full input or zero.

Precision mode is completely reworked. In stock KSP2, it simply limited the control authority of user inputs to 10% of the maximum. Now it also acts closer to the KSP1 version, where you can still go from -100% to 100% of the input, but the buildup and decay are much slower, meaning it’s now much easier to make finer inputs, while still letting you go all the way to the max if you keep holding the key.

All in all, these changes should make vessel controls and SAS feel a lot better, though it’s obviously not an all-powerful fix that will get rid of all issues.

In the attached video, you can see all of these changes: SAS on a rocket with very high control authority at 1x, 2x, and 4x physics warp, SAS on a plane, and then the updated normal and precision input behavior (with SAS disabled).

Media

https://www.youtube.com/watch?v=3EgC1tGO2eg

Early URP Port Devlog

Wed, 15 Apr 2026 00:00:00 GMT

I thought I’d make a short devlog to show off what I’ve been working on the past couple of days.

To give a bit of context, KSP2 uses the Built-in Render Pipeline. In Unity, a render pipeline is the sequence of GPU steps (culling, batching, lighting, shading, post-processing, …) that turns scene data into pixels each frame. The original, old Built-in Render Pipeline is a hardcoded implementation of that sequence, where you can tweak the parameters, but not really the logic itself. Meanwhile, the newer Scriptable Render Pipeline (which is an umbrella term for both the Universal Render Pipeline and the High Definition Render Pipeline) exposes that logic in C#, so that you can define exactly how objects are drawn, how lighting is evaluated, how render passes are structured, etc.

Now, the issue is that the BRP is going to be deprecated in Unity 6.5, and completely removed possibly as early as Unity 6.8, which coincidentally is also the stable release of CoreCLR support (which we really, really, really want for the potential crazy performance boost and the access to modern C#). Generally, we also want to be able to keep upgrading the game and not be hard stuck on a specific Unity version.

So, in order to solve this issue, we’ll need to eventually port the game from BRP to URP or HDRP. While HDRP would make the most sense with its current feature set compared to URP, Unity just recently announced that it will no longer be developed, and that URP will eventually receive all of its features and become the single recommended pipeline to use. That means that for future use, it makes more sense to start with URP right away, rather than have to go through another port in a couple of months/years.

In our case, porting from BRP to SRP is not an easy task though, arguably much more difficult than our big upgrade from Unity 2022.3 to Unity 6.3 (and now 6.4 in development). That’s because we don’t have access to the source code of the game’s shaders, and shaders are often very particular about which render pipeline they work on. That said, there are some ways (dark magic) to “hack” around this and get stuff to render using these normally incompatible shaders, and the video in this post is a look at the first “playable” version of the very early and experimental URP port of the game. Many things are still missing, but it’s honestly been going much better than I expected, so I’m feeling positive about this little side-quest that I’m on!

Media

https://www.youtube.com/watch?v=kVZ4nv5IGCA

Custom Flags Teaser

Thu, 09 Apr 2026 00:00:00 GMT

Can you guess what new feature we’re adding next? Spoiler: custom flags are coming in beta 5.

Media

Chipping Away at Map View Performance Issues

Mon, 30 Mar 2026 00:00:00 GMT

Chipping away at map view performance issues

Most of the speedups in Redux focus on the simulation and main UI. We haven’t really done much to try to improve the map situation. After all, the simulation has to run at time as the map being open, so any improvement in the simulation should imply a performance improvement in the map. However, with the sim performance getting better, the FPS drop when opening the map is getting increasingly noticeable. One piece of code in particular, called RelativeOrbitSolver jumped out at me as actually getting worse due to some changes in the way transforms are handled. The current version in redux takes up a whopping 4ms on my test setup.

RelativeOrbitSolver is used for predicting future locations in a hypothetical future orbit, and calculate where those points would be with respect to some given viewer. It’s used by the map to do things like draw projected intercept lines.

For example, let’s say a vessel in orbit of Kerbol is not currently intercepting Moho. The player adds a maneuver plan that would cause it to intercept Moho’s SOI but transit through it. So, the map has to draw a bunch of different lines.

The current orbit line.
The line starting at where the maneuver node is showing the change in Kerbol orbit as a result of the planned impulse. Ends at the predicted Moho SOI intercept.
A line near wherever Moho currently is that shows the vessel’s predicted transit through Moho’s SOI (relative to Moho). This is technically a hyperbolic trajectory (“orbit”) of Moho.
Another line relative to Kerbol that shows what the previous line actually like from Kerbol’s perspective. This is the one that uses RelativeOrbitSolver.
A line after the projected SOI ejection that shows yet another orbit of Kerbol, but this one having been modified by Moho’s gravitational pull.

The code uses several strategies depending on what kind of line it’s drawing, but the 2nd to last one here is the one that uses RelativeOrbitSolver. It’s also used for some other tasks, such as trying to find SOI transition points.

The code for RelativeOrbitSolver is one of the few things got somewhat slower after switching to ECS frames. It created a bunch of temporary TransformModels, would move them around, and then use them for doing relative position calculations. The individual point calculations were probably faster, however the setup/teardown of the temporary frames were quite expensive. Unfortunately, a few spots in the code (such as maneuver nodes) would create a RelativeOrbitSolver to solve for exactly one point and throw it away.

So, I rewrote the code to avoid using TransformModel. While I was in there, I noticed a bug where it would ignore a celestial body’s axialTilt, which caused some issues with the line related to Moho. Now the code just scrapes the spatial relationships into a simple temporary list, and runs a simple loop to do the same calculations the more complicated transform system would do.

Media

Engine Plume Creation Tools Preview

Sun, 15 Mar 2026 00:00:00 GMT

A little preview of new tools for engine plume creation (based on the stock engine VFX system) for Redux and mods

Media

https://www.youtube.com/watch?v=gg7BSMK7Axk

New 1.875m Parts Preview

Mon, 09 Mar 2026 00:00:00 GMT

A bit of a sneak peek at some of the new 1.875m parts by glumo

Media

v0.2.3 Beta 4 Hotfix 1

Sat, 28 Feb 2026 00:00:00 GMT

v0.2.3 Beta 4 Hotfix 1

A hotfix for the fourth prerelease beta of Redux v0.2.3 has been released. You can find the download and changelog on GitHub or here on Discord: https://discord.com/channels/1078696971088433153/1444156522127954064/1477434147206336573

v0.2.3 Beta 4

Fri, 27 Feb 2026 00:00:00 GMT

v0.2.3 Beta 4

The fourth prerelease beta of Redux v0.2.3 has been released. You can find the download and changelog on GitHub or here on Discord: https://discord.com/channels/1078696971088433153/1444156522127954064/1477020790003339479

First Trailer Hits 100k Views

Sun, 22 Feb 2026 00:00:00 GMT

1 year later and the first trailer has 100k views. It’s nice to see that people care about Redux and KSP2 as a concept. Here’s to a great 2026 and… another… 100k views…? (I was going somewhere with that I swear). Thanks for all your support!

Media

KSP2 Redux Dev Blog 16 (?): Unity 6.3

Tue, 06 Jan 2026 00:00:00 GMT

KSP2 Redux Dev Blog 16 (?): Unity 6.3

When did we stop numbering these dev posts?

Hello everyone! It’s been a minute since the last dev update, as we’ve been busy with our beta releases, fixing bugs, adding more features, etc. However, this new development is a pretty big deal for us, so I thought we might share a bit of info.

We’ve just managed to upgrade KSP2 from Unity 2022.3.5 all the way to the lastest stable Unity 6.3 version (6000.3.2). This means we will have access to all the latest editor tools, Unity bug fixes, new APIs, etc. It will be a huge help to us in continuing to rewrite and update the game’s UI using the newer UI Toolkit library (like you could see in the Color Manager and orbital info panel), as well as in converting the game’s simulation code to Unity’s DOTS.

I first started working on this experiment a couple of weeks ago, but hit a wall that I wasn’t sure we could overcome. We previously thought that this would be a massive undertaking that would require us to rewrite many of the game’s shaders from scratch, as we don’t have access to their sources and the binary serialization layout for the files which (usually) contain the built shaders changes between every version, meaning we couldn’t just take the existing built assets files and reuse them in a new Unity version.

However, thanks to the amazing work that PassivePicasso and Foonix had done on the BundleKit package, we were able to convert those .assets/.assets.resS files into regular asset bundles, which Unity 6.3 can load, and after some work in the Unity internals to redirect shader and other asset loading from those files into our new bundle, as well as modifications to the core TextMeshPro package in order to fix many font bugs that we were faced with (shoutout to cheese_queen for the work on that and more), we now have a 99% functioning build of KSP2 Redux in Unity 6.3! This also means that we will be able to continuously upgrade to new Unity versions as they come out and leverage all the new improvements and technologies that come with them (such as the massive move from Mono to the incomparably faster and more stable .NET that will possibly arrive with Unity 6.7 later this year), which is a huge win for Redux.

This also means that modders will be able to take advantage of all the new Unity improvements when building their mods. The modding SDK and template will be updated soon to bring support for it, and you can expect a new beta build in the near future to help us test this experimental version of the game.

Media

v0.2.3 Beta 3 Hotfix 1

Wed, 24 Dec 2025 00:00:00 GMT

v0.2.3 Beta 3 Hotfix 1

The hotfix for a couple of issues in the Beta 3 has been released. You can find the download and changelog here: https://discord.com/channels/1078696971088433153/1444156522127954064/1453368281535742035

v0.2.3 Beta 3

Wed, 24 Dec 2025 00:00:00 GMT

v0.2.3 Beta 3

The third prerelease beta of Redux v0.2.3 has been released. You can find the download and changelog here: https://discord.com/channels/1078696971088433153/1444156522127954064/1453199730673844294

Installation Guide

Mon, 22 Dec 2025 00:00:00 GMT

Installation guide

Since there have been a couple of questions about how to install the beta of Redux, I put together a little video guide:

https://youtu.be/_73j6XiAKZM

Public Bug Tracker

Thu, 18 Dec 2025 00:00:00 GMT

Public bug tracker

Just a tiny update - in-game bug reports are now sent to both our internal bug tracker as well as to our GitHub: https://github.com/KSP2Redux/Redux/issues

You can go there to see progress on bug reports you submitted or comment on issues, as well as use it to report new issues if necessary (e.g. the game doesn’t even launch, or it doesn’t load). In any other case where you can access the in-game bug tracker (Esc -> Report Redux Bug or Ctrl+B), it is always preferable to use it.

v0.2.3 Beta 2

Sat, 06 Dec 2025 00:00:00 GMT

v0.2.3 Beta 2

We have just released the second prerelease of Redux v0.2.3: https://discord.com/channels/1078696971088433153/1444156522127954064/1446963570389553365

v0.2.3 Beta 1

Sun, 30 Nov 2025 00:00:00 GMT

v0.2.3 Beta 1

Hello everyone, after a quick round of closed testing and fixing a couple more bugs, we decided to let the floodgates open and give access to the newest beta build to everyone. Please, carefully read the linked post before downloading and/or asking questions, just in case it’s already been answered there.

Keep in mind that this is intended for testing and catching any other last minute bugs before the actual first release.

Download

Instructions and download are available here: https://discord.com/channels/1078696971088433153/1444156522127954064

Status Update

Sat, 08 Nov 2025 00:00:00 GMT

Status update

Unity issues

First of all, let me apologize for the lack of news in the past month and a half. We have been struggling hard with various Unity issues plaguing several of the developers, and they irritatingly always affect each just one person and no one can ash figure out why, and the obvious solutions like reimporting files, setting up a fresh copy of the project or even reinstalling Unity just don’t help. (More details: https://discord.com/channels/1078696971088433153/1340177797196414996/1422618937430118500)

ISRU is cut

In order to get something to you as soon as we can, we have made the decision to cut ISRU out of the initial 0.2.3 release, as it was the biggest blocker for the release - one of the main ISRU developers is one of the people affected by those Unity issues. That should give us some time to hopefully resolve these issues and polish it enough for a later release (which was originally the plan anyway, before we decided to roll all of the Foundation stage into a single release).

Release date

Back in June, when we teased the “Summer 2025” release, it seemed very likely that we’d have the release ready by the end of July, or by the end of August in the worst case. That obviously turned out to be wrong, and a large part of that was the fact that we gave ourselves this arbitrary deadline. It caused a lot of stress, overworking ourselves, and inevitably, burnout, which lead to a large part of the dev team stepping back from the project. I take personal responsibility for this, as I was was the one pushing for the internal July deadline and the public announcement of a summer release date, thinking it was a good idea and would motivate us to finish faster.

For that reason, we can’t give you an updated release date because as we’ve learned the hard way, progress is extremely unpredictable and putting pressure on people working for no compensation in their free time just makes this passion project into a very bad unpaid job. So, I’d like to ask you to keep that in mind and give these volunteers the space to do their thing out of the love for the game and the community, and not because they feel under pressure.

PS: Just to give you some sense of the progress of the release, here’s a little peek at our internal task tracker - we’re sitting at 118/125 done, and most of the game code changes are finished.

Media

Improving Performance of Background Part Modules

Sun, 21 Sep 2025 00:00:00 GMT

Improving performance of background part modules.

Some of you may remember the infamous “2500 background parts” test thread from the forum.

If you’re not familiar, it was a test using 10x250 part vessels in the background, and a single capsule in the foreground.

https://forum.kerbalspaceprogram.com/topic/219210-ksp2-is-calculating-the-physics-of-all-parts-of-all-crafts-whether-they-are-rendered-or-not-reducing-performance-of-all-scenes-at-all-times/

So far, Redux has incidentally made some small improvements on that test. The development branch is about %15-20 faster than stock, mostly due to general improvements in spatial calculations and flow request processing.

However, I hadn’t really tried to tackle the elephant in the room, which is just the shear amount of parts. Even tiny amounts of overhead for each part really adds up when we’re talking about multiple thousands of them. One save a player shared with me had organically hit 560 parts even while keeping per-vessel part count low, so it’s not really far fetched that real players could hit 1000+ parts.

So I took a look back at the 2500 parts test, and was able get another ~%10 more fps with a couple of relatively simple changes. (51.4ms -> 46.2ms)

Reworked the part module update code to make modules have to subscribe to get updates. Skip ones that don’t subscribe, and implement subscription for ones that do.
Moved some engine status display updates from background to foreground only.
Moved Module_LitPart checking if the lights should be on/off to foreground only. (Note, this is different from Module_Light. It just checks if the vessel should look like it’s had a power failure or not.)
Simplified some getter logic commonly used by modules.

All in, Redux runs the test about %30 faster on my machine. Stock KSP2 vs this branch: 16fps -> 21fps

Left/Blue is Redux development branch. Right/orange is this change set. Comparison over 384 frames.

Media

Release Delay Update

Sun, 21 Sep 2025 00:00:00 GMT

Hey everyone!

Just wanted to drop a quick update on where we’re at with KSP2 Redux. We were originally shooting to get the first update out this summer, but unfortunately real life had other plans. Since this is all volunteer work, a lot of our team has had to focus on more important stuff outside of the project, which slowed things down more than we expected or wanted.

On top of that, the update itself kind of exploded in size. What was supposed to be a smaller “starter” release has turned into something way bigger, with a bunch of features we didn’t think we’d be tackling until way later.

We know delays aren’t ever seen as a good sign, and we totally get if it’s frustrating (trust us, coming from KSP2, we really get it). While we can’t say for certain when we’ll get this mod out to you guys, we’re still hoping to get it into your hands before the end of the year, so keep an eye out for updates regarding that!

Thanks for hanging in there with us. We can’t wait to share what’s coming!

Rendezvous: The KSP2 Redux Team

Installer and Launcher Preview

Thu, 11 Sep 2025 00:00:00 GMT

One of the big ticket items left to complete before we release the first update is the installer/launcher! We want to make the setup process as straightforward as possible and this is a big part of achieving that - don’t worry, you’ll still be able to launch the game from your regular methods for opening KSP2 once you’ve patched Redux in. Here’s an in-progress screenshot PassivePicasso took recently to give a rough idea of what to expect from it, though things are of course subject to some change:

Media

Optimized RUDs

Wed, 20 Aug 2025 00:00:00 GMT

Optimized RUDs

Sorry this took so long to get to everyone!! Just for conveniences sake, here is a side-by-side comparison of our two clips showing off the performance improvements to the various explosions you will encounter in this game uploaded on our official channel!

https://www.youtube.com/watch?v=czksGn9RC6E

RUD Troubleshooting Repost

Fri, 15 Aug 2025 00:00:00 GMT

I’ve been crashing this thing repeatedly to troubleshoot bad stuff that happens during RUD.

It’s still chonkier than I’d like, but most of the errors are fixed and the UI is more well behaved.

https://vimeo.com/1109589044/33016522c0

For comparison, here’s stock 0.2.2 in the same test on the same hardware: https://vimeo.com/1109586222/9a95fb1e01

(I really shoulda put this here, so reposting)

Redux Is Looking for Volunteer Translators

Wed, 09 Jul 2025 00:00:00 GMT

Redux is looking for volunteer translators!

If you are comfortable in English, fluent in one of the languages listed below, and would like to contribute to KSP2 Redux, this is your lucky day! We are looking for translators to contribute to the project by providing translations of various game elements.

Languages: French, German, Italian, Spanish, Japanese, Korean, Polish, Russian, Portuguese (Brazil), Chinese (Simplified), Chinese (Traditional).

If you are interested please contact me on Discord.

Tech Tree Features

Thu, 03 Jul 2025 00:00:00 GMT

Tech Tree Features

One of the new features that will be introduced in the initial release of Redux are new tech tree requirements. Tech tree nodes now can have multiple new requirements that have to be met before the node can be researched: missions and science experiments.

In the showcase video, you can see that the nodes with these extra unlock requirements are marked with a small lock icon in the bottom right corner, and when you select them, you will see the requirements listed in the details panel on the left.

Once all the requirements of such a node are met, you will receive a notification that the node is now available for research, and you can proceed to unlock it as usual (that is, if you have enough science points).

Note that the video is only illustrative and the actual nodes with special requirements will be different in the release. Currently, we are planning to have missions gating the progress between the tech tree tiers.

Media

https://www.youtube.com/watch?v=eXuoOU1GW_0

UI Improvements

Wed, 18 Jun 2025 00:00:00 GMT

UI Improvements

Hey everyone, we’ve been working on some UI improvements for our first release, and wanted to give you a little preview. Make sure to watch the video to the end! Below are some screenshots of other small improvements that didn’t make it into the video.

https://youtu.be/lZ9rvqisYKE

Media

Redux Is Looking for Volunteer Developers

Wed, 18 Jun 2025 00:00:00 GMT

Redux is looking for volunteer developers!

In order to achieve the goals previously shown in our roadmap, we are looking for active volunteer developers interested in joining the team! Ideally, we are looking for applicants with experience in one or more of the following:

KSP1/KSP2 code mod development
Graphics programming: HLSL, Unity Shader Graph, ShaderLab
Unity development
C# programming

If you’re willing to join the project and would love to contribute to finishing what was promised for KSP2, please send proof of experience in one of the mentioned fields to munix or Safarte by DM. This can be your Github page, a mod’s page, info about a game you worked on or anything similar.

Note: please provide some proof that you own the KSP2 game as well. This is a hard requirement for working on the project as a developer.

Modding SDK: Unity Editor Integration

Wed, 14 May 2025 00:00:00 GMT

Redux Update: Modding tools - Unity Editor

Recently efforts have been made in the “modding support” side of Redux, today I want to share with you a breakthrough that will make modding the game a much smoother process.

Using Redux’s modding SDK, which will be partly based on the KSP2 Unity Tools package, in conjunction with PassivePicasso’s ThunderKit you will be able to test your mods by running KSP2 Redux directly in the Unity editor!

This allows you to:

Very quickly iterate, with changes being able to be tested in a matter of seconds, not minutes.
View what’s happening in-game in real time using the Scene view.
Access the full suite of Unity Editor tools, including for example custom inspectors for Unity and KSP2 components.
Use built-in Unity C# debugging tools and any other Unity package library.

On a technical note, we are still figuring out stuff like Harmony which does not really work in the editor (but will work fine in the compiled mods), we’ll keep you updated if we make progress on this front. For simplicity, we will also want the modding API to provide as many endpoints as possible that allow you to mod the game without the use of Harmony.

Media

Resource Scanning System - Work in Progress

Sat, 03 May 2025 00:00:00 GMT

Resource scanning - work in progress

Here’s another quick look at the latest version of the resource scanning system for a future Redux version.

As you can see in the video, the system is designed in such a way where you may need specialized scanner parts to be able to find certain resources, and so in this showcase, only two (or one in the second clip) out of the three available resources are revealed.

Media

https://www.youtube.com/watch?v=KgGRAsd31rI

Resource Extraction System Preview

Wed, 23 Apr 2025 00:00:00 GMT

Small teaser: preliminary exploration of resource extraction system

Redux developers have been exploring some implementation ideas for the resource extraction system in KSP2. Here are videos of a drill and a resource indicator UI (everything very WIP).

We have been brainstorming ideas on how the resource system should work, where in the complexity - usability scale we should be and other ideas.

We will try to keep you updated as continue fleshing out those ideas.

Media

https://www.youtube.com/watch?v=MA-Q98Q73PU

https://www.youtube.com/watch?v=_ZLpBhVkadA

Graphics Update: Dynamic Sunflares

Thu, 10 Apr 2025 00:00:00 GMT

Redux Update: Sunflares

Hello! I’m dan, one of the developers on KSP2 Redux. You might know me as the guy who made some KSP1 & 2 mods (mostly relating to graphics).

One of the things mentioned in the Redux Trailer were improved graphics, and I’m here to share a nice change I’ve done to the sunflare.

Sunflare Colors

I’ve changed it so that flare elements use the color of LocalSpace_Light_Kerbol (the light source for Kerbol in flight view). This means you get a white sunflare in space, a blue sunflare on Duna (on sunset/sunrise of course), and etc. While it’s a small change, it does add a lot to the cinematic experience!

Media

Community Update: Contributing to Redux

Mon, 31 Mar 2025 00:00:00 GMT

Hi! We are starting to think about how to integrate people who want to contribute to Redux into our processes. Right now we mainly think that external contributions would be best suited for asset development (parts design, model and textures, sound, animations, …) and possibly QA in the future. If you have experience working on this kind of stuff and would like to contribute to Redux, send me a DM or ping me in https://discord.com/channels/1078696971088433153/1340177797196414996. This message also extends to modders who would like to be guided through migrating their mods to Redux when we get closer to release. People familiar with UI design and Unity UITK are welcome too.

Performance - How the Little Things Add Up

Sun, 16 Mar 2025 00:00:00 GMT

Redux Update: Performance — How the little things add up

Unfortunately this post came out way too long for a discord message. So check it out on the forums:

https://forum.kerbalspaceprogram.com/topic/226985-ksp2-redux/?do=findComment&comment=4450060

TL;DR: Reduced time per frame by another %12 in the 2500 background parts test.

Media

Trailer Footage Clarification

Sat, 01 Mar 2025 00:00:00 GMT

Hey all, NexusHelium here (the editor of the trailer)!

A lot of people have (rightfully so) noticed that a good chunk of the footage is noticeably lagging. This was due to issues with the editing software, so I decided to make a video with the raw footage showing the real FPS for those various shots. We also wanted to correct an honest mistake that one of our team members made, stating that the footage was not shot in Redux - it was an assumption he made based on the last communication between us, before I recorded these specific clips.

All of these shots except for the reentry visuals (which were done as a separate mod prior to becoming part of Redux) are recorded in KSP2 Redux.

Here it is: https://www.youtube.com/watch?v=LNW0zmNv_7I

Debug Tools Updates

Wed, 26 Feb 2025 00:00:00 GMT

Update: Debug Tools

Added new “Vessel Tools” window with various helpful features included (thermal, mass & maneuver node data; flight axes & SAS display; joints manipulation; buoyancy indicators; and others)
Added transparency to all existing windows

We will be trying to send similar changelogs as we work on the project to keep you updated.

Update: Debug Tools

Added “Vessel Coordinates” window with various info about the current position to the “Vessel Tools” stats windows.
Added a “Kerbal Roster Tools” window with ability to edit the roster, add and delete Kerbals.
Added an “Experiment Reports” section to the “Vessel Science” window with ability to create and submit reports.
Added a “Teleport Bookmarks” window with the ability to create bookmarks in multiple “Bookmarks Lists” from the vessel’s current position. Comes with a built-in list of bookmarks to help debugging.

With this, all the debug windows I wanted to get done before the first release should be complete.

Media

Dev Blog 0: What's a Redux?

Tue, 25 Feb 2025 00:00:00 GMT

KSP2 Redux Dev Blog 0: “What’s a Redux?”

Hello everyone, let me introduce myself first, my name is Safarte and I am the developer of the Kerbal Life-Support System and Docking Alignment Display KSP2 mods. I joined the KSP2 Redux development team something like a month and a half ago and I’ve mostly been working on debug tools and some bug fixes.

The goal of this first dev blog for Redux is to introduce you to the project in more details and provide you with some information on what we plan to do with it.

What Redux isn’t.

The next big AAA amazing space exploration game™
A quickly put together collection of existing mods
A teapot

Now that that’s out of the way, let’s focus on what Redux really is.

Who’s working on Redux?

We are a team of (mostly) KSP2 modders that really like this game and would like to see it reach its potential. There are currently a bit less than ten people working on Redux to varying levels of involvement.

What is our scope for this project?

Our plan for Redux is to try and achieve what we interpret as the core vision of the original developers of KSP2. This means both fixing existing bugs in the game, improving performance and most importantly bring to life promised features like colonies, interstellar travel or multiplayer. We also want to make the game as moddable as possible by providing tools to help the development of mods. Regarding features such as colonies, the current plan is to include all core functionality, with some parts to fill the necessary gameplay roles. Fancier parts will be left to modders to add to the game, for example: Redux might include a simple ISRU for colonies but mods could add many more of varying size, style, etc…

What form will Redux take?

Redux will most likely be distributed as an installer which will apply some patches to the relevant files in an existing KSP2 installation. Redux will not take the form of either a standalone executable or a simple Spacewarp mod, it’s gonna be something in-between.

We hope to be able to integrate Redux’s installer into CKAN to make installation as simple as possible.

What’s gonna be in the first few releases?

The aim of the first releases will be to get KSP2 to a state where we feel we can safely add more features to without it crumbling down to pieces. This mainly includes stuff like performance improvements, bug fixes and enhanced modding support.

We also plan on including some quality of life stuff like some debug tools that can help develop mods or pinpoint issues.

How can I contribute?

If you’re a player: we are open to suggestions, do not hesitate to drop your ideas in the #🟡redux-suggestions forum. Also, once Redux has released, please report any bug that you can find and think could be caused by our modifications.

If you’re a modder: please get in touch with us so we can accompany you on how to migrate your existing mods to support Redux.

If you’re a Redux developer: chop chop get back to work

Final disclaimer

Redux is a fan project entirely developed by a team of (passionate) volunteers, we do not have access to the resources of a full game studio so temper your expectations with this in mind. Redux might (and probably will) introduce new bugs to the game, we cannot check every possible scenario otherwise we’d never release anything. We also do not have any affiliation with the former KSP2 developers, please do not interpret this project as an official continuation of KSP2’s development.

Performance Improvements Overview

Tue, 25 Feb 2025 00:00:00 GMT

Basic rundown of Redux FPS improvements:

Leverage newer unity features

Enable unity “Graphics Jobs” setting. Cuts 3-5ms off the frame on my computer.
Disable Unity Physics.autoSyncTransforms option. This required rewriting a lot of code to avoid depending on the autosync behavior.

Overhaul widely used systems for better performance

TransformFrame is how the game deals with multiple moving reference frames, and is used extensively through the code base. Redux replaces this with an ECS/Burst based system that is significantly faster.

Lots of individually minor “depessimizations” that add up to significant improvements.

Too many to list in a discord comment. Many, many code systems have been tweaked to remove unnecessary steps, fix unnecessary garbage allocations, and accomplish the same task with fewer resources.

Performance test results compilation

All tests are on my system: i7-4790K @ 4GHz, 32GB DDR3 @1333MHz, RTX2080

Small vessel test:

50 fps -> 78 fps

200 part test:

18 fps, 55.95ms/frame -> 24fps, 41.49ms/frame

1500 part test

638 ms/frame -> 347 ms/frame

Media

Unable to recover small-vessel-redux.png from Discord: HTTP Error 404: Not Found

Unable to recover small-vessel-stock.png from Discord: HTTP Error 404: Not Found

Unable to recover 1500-part-test-1.png from Discord: HTTP Error 404: Not Found

Unable to recover 1500-part-test-2.png from Discord: HTTP Error 404: Not Found