Kerbal Space Program 2 News & Announcements
Good afternoon, Kerbonauts!
This week, we're working on many of the same bugs we were working on last week (one aspect of our increased transparency is likely to be that you get to share in the joy of waiting for the oven to go "ding"). We did see some encouraging movement on a few items, but I'll keep the original ten bugs on the list until we've got bona fide QA sign-off on them.
Bug Status
For most of this list, investigation and/or testing is ongoing. Areas that saw significant change have been marked in bold:
Vehicles in stable coasting orbits sometimes experience orbit instability/decay - Status: possible fix in progress
Trajectories change when vehicles cross SOI boundaries - Status: fix in progress
Certain inline parts cause aerodynamic drag numbers to spike - Status: fix being tested
Returning to craft from VAB causes craft to go underground (possibly related to Kerbals and landed vehicles dropping through terrain while being approached) - Status: possible fix being tested
Decoupling events result in various issues including loss of control, incorrect controllability of decoupled subassemblies, loss of camera focus, and other issues - Status: may have many causes, but some fixes in progress
Save files get bigger over time (TravelLog experiencing "landed" status spam) - Status: fix being tested
Opening part manager causes major frame lag - Status: experiments ongoing
Major post-liftoff frame rate lag immediately above launchpad (associated with engine exhaust lighting) - Status: fix being tested
Root parts placed below decouplers cause issues with stage separation - Status: under investigation
Vehicle joints unusually wobbly, some part connections unusually weak - Status: under investigation
Issue 2: Trajectories change when vehicles cross SOI boundaries
We have three engineers looking at this and we have already ferreted out a couple of issues - the introduction of axial tilt to KSP2 introduced some discrepancies, and our SOI transit handoff math had some inconsistencies as well. A few other issues surfaced in the simulation code, and we're assessing both the impact of those issues and the scope of work required to correct them.
Issue 3: Certain inline parts cause aerodynamic drag numbers to spike
This bug is the one that saw the most movement this week. Our investigation of the spiking drag numbers revealed that we had a problem with drag occlusion. There is special code that reduces the frontal drag impact of a part that is blocked by another part, and in some cases we were seeing inline parts behave as though they weren't shielded from airflow at all. In some cases, we were also seeing the opposite - wide parts that should have been creating drag were not having their frontal drag assessed at all. Of course, this latter case would rarely register as a problem, whereas the initial problem manifested in all sorts of unpleasant ways - essentially, parts positioned aft of other problem parts behaved like airbrakes, affecting both the overall drag and stability of the vehicle. Even weirder, these drag occlusion issues only arose when a vehicle was built horizontally!
This problem has been corrected. In fact, it’s been SO corrected that after we fixed it, we started to get messages from QA that aircraft felt too fast! We checked the numbers, and they’re correct. We’re still testing this fix, but it’s looking very good for the upcoming update. The details of how this problem was analyzed and corrected would make a very interesting dev diary from Chris Adderley, if he ever gets a few moments to spare.
Issue 8: Major post-liftoff frame rate lag immediately above launchpad (associated with engine exhaust lighting)
Quick clarification: engines had previously each spawned a point light that cast shadows. While this was very pretty, it wasn’t great for performance (and this impact was increasingly pronounced at high engine counts). We have turned off shadow casting for those lights and are seeing an improvement in framerate near the launchpad.
Bug Reporting Progress
I also mentioned last week that we were exploring ways of communicating our current priorities more clearly, as well as giving members of the community more agency to communicate their own experiences and priorities to us. With that in mind, Dakota Callahan and the Community Team have begun to make some changes to the Suggestions and Development subforum on the KSP2 Forums. We’ll get into more detail about our specific implementation next week, but Dakota has already shown some of his work in that subforum - he’s taking several steps, including creating a new Bug Hunter member role, reformatting threads so that they can be up-/down-voted (this is just for bug threads), adding recommended tags/prefixes, and setting up a system that allows administrators to combine duplicate issues. This will start as a pilot program, and its success will hinge on how useful the community finds it and how maintainable our team finds it. The best possible outcome would be that players use the subforum to surface the issues they find most pressing, and our devs have the ability to ask directly for additional context. Again, I’ll provide more detail about this new structure when it’s fully in place, but in the meantime check out Dakota’s post - he’s got some great ideas!
Engines
After posting footage of the three new deep space methalox engines that will be arriving in update v.0.1.3.0, we’ve been asked by a few people what those engines can really do. Our Lead Producer Nestor Gomez (of KSP1 fame) suggested that we share some stats in the time-honored old-school way - with cool blueprint-style graphics! Without further ado, here are the three new engines (with special thanks to Matt Poppe, who continues to do amazing work on everything he touches):
I have run a few missions with these engines, and I can attest that they’ve opened up quite a few new capabilities - ones that will become invaluable when the R + D progression enters the picture and nuclear thermal engines are not yet in reach.
Community Highlights
Last week, we did a space station challenge! Several of your impressive submissions can be seen over on our recent Community Highlights post. Some of this stuff is just nuts.
Weekly Challenge
This week’s challenge is technically about landing, though given Gilly’s low gravity, it might just as easily be called a docking challenge. We challenge you to land on Gilly!
Good luck to you all and see you next week!
Good afternoon, Kerbonauts!
This past week has been a learning experience. The last post received a lot of comments, many of which expressed doubt, frustration, and in some cases anger about either the seeming lack of progress on KSP2 or the perception that a dark reality about the game's state is being concealed. Our team has been reading your comments and asking one another if there's some way we can do better.
In the past, every item in these posts has has to cross a threshold of certainty - we don't want to announce some new feature or target date, only to experience a trust-eroding failure to follow through. I feel this burden especially keenly because in the past I have personally announced dates that turned out to be incorrect. For this reason, we have avoided talking about features in progress, bugs under investigation, or internal delivery deadlines. With a game this complex, nothing is ever assured until is has been thoroughly tested by QA. When you combine this "stay quiet until you're absolutely sure" ethos with a more dispersed update cadence, what you get is long periods of silence.
Now of course, I haven't gone literally silent. Posts come out every week. Before each post goes out, I meet with the production and community teams to review the past week's progress, and many great, exciting developments are discussed. They often take the form of "we've made great progress on x category of a super annoying bug" or "this feature looks good but we haven't had time to fully validate it yet". By my standard of "don't talk about it until it's truly done," neither of those scenarios yield anything that's safe to post about. What is safe, then? Well, for the most part, content updates like new art, parts, and graphic improvements come along in nice, neat little parcels that are not only visually pleasing, but also are unlikely to generate an unmet expectation. They're fun and they're safe, and artists are always creating new content. So you see lots of that.
But the other thing you see lots of is some variation on "improved stability and performance". That's my catch-all term for that very meaningful category of progress that, because of my reluctance to write bad checks, can't yet be talked about it detail. When I hold back on such items, I comfort myself that the less I reveal now, the more surprising the patch notes will be when we release them.
Still, I'm questioning my choice to withhold information about systems in progress. Yes, there's always the chance that when we talk about a feature in development, that we're also creating an expectation that the feature will be present in the next update. Similarly daunting is the possibility that we'll announce that we're working on something the community perceives as "easy" (an especially common situation when we're working on a feature that is already functional in the original KSP), and then take a long time delivering that feature that people may decide we don't know what we're doing. In such cases, we then need to take the time to explain in technical detail why the implementation of such and such of a feature is non-trivial in KSP2. Increased transparency carries costs, and those have to be balanced against other feature-facing work we could be doing.
I'm extending trust to you and will talk about a few things that are not yet complete, so you can see some of the ropes we're hauling on every day - some of which may prove to be long. This list is not exhaustive (there are dozens of people working on dozens of items simultaneously, and there are some features that we really do want to be surprises), but it'll give some visibility into the issues we're tackling. Please do not assume that if a bug isn't mentioned that it is unknown to us or not being worked on - this is a top-ten list.
Our bug prioritization is broadly guided by the following:
- Category A: Any bug that causes loss of a vehicle in flight (physics issues, trajectory instability, decoupling instability, loss of camera focus, unexpected part breakage/RUD)
- Category B: Any bug that affects the fidelity or continuity of a saved game (rigidbody degradation, save file inflation, loss of vehicle or Kerbal during instantiation or focus switching)
- Category C: Any bug that negatively affects the expected performance of a vehicle (drag occlusion, staging issues, thrust asymmetry, joint wobbliness, landing leg bounciness)
- Category D: Any VAB bug that prevents the player from creating the vehicle they want to make (symmetry bugs, fairing/wing editor bugs, strut instability, inconsistent root part behavior)
Until a player can envision a vehicle, create it without being impeded by VAB issues, fly it with a reasonable expectation that physical forces will be consistently applied, and have their progress at any point without worrying about the fidelity of that save, the KSP2 experience will be compromised. Obviously, now that we are layering in progression mechanics (Science gathering and transmission, missions, and R&D tech tree) in preparation for downstream Roadmap updates, the importance of addressing these issues only increases.
Therefore, here are a few of the biggest issues we're wrangling with right now:
Vehicles in stable coasting orbits sometimes experience orbit instability/decay - Status: possible fix in progress
Trajectories change when vehicles cross SOI boundaries - Status: fix in progress (see below)
Certain inline parts cause aerodynamic drag numbers to spike - Status: under investigation
Returning to craft from VAB causes craft to go underground (possibly related to Kerbals and landed vehicles dropping through terrain while being approached) - Status: possible fix being tested
Decoupling events result in various issues including loss of control, incorrect controllability of decoupled subassemblies, loss of camera focus, and other issues - Status: may have many causes, but some fixes in progress (see below)
Save files get bigger over time (TravelLog experiencing "landed" status spam) - Status: fix being tested
Opening part manager causes major frame lag - Status: experiments ongoing
Major post-liftoff frame rate lag immediately above launchpad (associated with engine exhaust lighting) - Status: fix being tested
Root parts placed below decouplers cause issues with stage separation - Status: under investigation
Vehicle joints unusually wobbly, some part connections unusually weak - Status: under investigation
We’re tracking down some strange vehicle behaviors associated with spurious autostrut errors. As we’ve discussed here before, some radially-attached parts are reinforced by additional invisible autostruts to improve their stability. It turns out that these autostruts don’t always break cleanly during decoupling events, and may be the cause of some of our more frustrating decoupling issues (including those where detached vehicle elements appear to still affect one another’s behavior). We’re still investigating this one, but we have high hopes that its correction will result in a significant reduction of mission-killing errors.
Finally, we have zeroed in on the cause of some of the trajectory errors we’ve been seeing - especially the situation in which a trajectory changes spontaneously when crossing an SOI boundary. This one is deep in the code and its correction may end up fixing a few other downstream issues. This is a complicated problem, however, and we may not solve it in time for the June update. We should know more about this one soon.
I’ve provided the list above as a stopgap. We have been discussing internally how best to improve bug status visibility so that you have a better idea of what we’re working on. We’re looking at a lot of options right now, and I’ll update you when we’ve settled on something. We recognize the need for this transparency and we’ll come to a solution soon.
ANYWAY...we have some nice content news! Update v0.1.3.0 will be the first KSP2 update to contain not only bug fixes, but a few new parts. Right now, we can confirm the arrival of the following:
- A.I.R.B.R.A.K.E
- Clamp-O-Tron Shielded Docking Port
- Clamp-O-Tron Inline Docking Port
- MK2 Clamp-O-Tron Docking Port
- Cornet Methalox Engine (new small extensible-nozzle orbital engine)
- Trumpet Methalox Engine (new medium extensible-nozzle orbital engine)
- Tuba Methalox Engine (new large extensible-nozzle orbital engine)
- S3-28800 Large Inline Methalox tank (longer version of large methalox tanks)
Note: This is a shortened version of the video due to Steam's file constraints. Check out the full 1:17-minute long video here!
We're still testing the new grid fins. Because these parts require some special part module support, engineering work is ongoing. Due to the complexity of this work, we don't believe grid fins will make it into the v0.1.3.0 update.
Next for the Weekly Challenge, we're building space stations! Thanks to @RyanHamer42 on Twitter for the suggestion!
Good luck and have a good weekend, everyone!
A fine May afternoon to you, fellow Kerbonauts!
I'll start with a bit of good news: the v0.1.3.0 update will be dropping in June. We'll announce an exact target date when we're a little closer to the day. We've already seen a few big bugs go down (you can throw a fairing away now in the VAB without endlessly redeploying its editor, for example), but I'm going to hold off on itemizing other fixes until they're confirmed zapped by QA. Regardless, we're feeling good about our progress in all areas and are confident that the next update will provide good performance, stability, and gameplay improvements.
In the meantime, our design and content teams continue to bring new parts to life. One thing they're working on now: grid fins! There were designed by Chris Adderley and brought to life by Alexander Martin. Chris would like me to point out that the fin on the right is shown upside-down so that you can see the beautiful serration detail:
Our tech artist Jon Cioletti (with the help of graphics gurus Christ Mortonson and Phil Fortier) has pulled off the impressive feat of improving both polish and performance by overhauling the solar lens flare occlusion system. Lens flare occlusion (the scaling/disappearance of the sun's lens flare when passing behind objects) no longer uses raycasts or colliders - now we're literally counting pixels on the sun itself. The result: no more sun peeking through terrains or oceans, no more weird flare behavior behind vehicle parts, and the sun now shines correctly through visors, trusses, parachutes, and windows! Check it out:
Disclaimer: This is a compressed GIF version for Steam due to file size constraints. Check out the full video res version here.
We've also been building some lovely Science collection parts, which are meant to provide interesting, meaningful payloads for research missions. This is one of our new radial science collection parts (designed by Chris Adderley, built by Alexander Martin, and animated by Paul Zimmer):
In community highlight news, we've received your capybaras and have found them various cute, hilarious, and unsettling. For more capybara shenanigans, check out this week's roundup. This week's challenge is to land on Moho!
See you all next week and happy flying!
Keep up with all things Kerbal Space Program 🚀
KSP Forums
KSP Website
Intercept Games Discord
KSP YouTube
Good day, fellow Kerbonauts!
In last week's post, I communicated our intent to decrease the update cadence during Early Access to allow our team to devote a greater portion of their time moving toward 1.0 and a little less time prepping incremental public updates. Some have expressed concern that this change signified some dark portent. To ease some of your concerns, here are a few clarifications:
- Our team is fully funded, properly staffed, and completely focused on executing the full vision of KSP2. Our velocity is good and our morale is great. This is still a dream job, and we're still committed to making this game spectacular.
- We want to balance our desire to be Santa (literally the most fun part of my job) against our goal of delivering an excellent product. The update cadence we're looking at right now extends the previous cadence by two to three weeks - structurally, the change is not radical. I know the waiting is painful, especially when there are still game-breaking bugs. Hopefully, the fact that each update will contain more improvements due to that lower frequency helps to offset some of the frustration of waiting.
- This project has from the beginning been viewed as a long-tail endeavor requiring a long-term investment. We are not worried about keeping the lights on; and we will be delivering on all of the promised roadmap features over the course of the Early Access period.
- These development updates will continue to provide visibility into areas where gains are being made. These posts are by no means comprehensive, not least because many of the improvements we're seeing aren't necessarily photogenic. They are meant to give you a taste of what's to come.
Note: This is a work in progress!
Darrin House, our Director of QA, posted a really in-depth Dev Blog that I think does a great job of showing the behind-the-scenes reality of testing this game. It pairs well with a lot of recent discussion in the community about the role of QA in the development process, and it gives some insight into the unique challenges presented by KSP2. No shade on previous dev blogs, but this one raises the bar. I am perhaps saying how much I like pictures here. It has lots of pictures.
This week saw some unprecedented radness on the ksp2_screenshots Discord channel. Check out these masterpieces from Coriolis, Little Earl, memes1, and Schwing2727:
Finally, this week's challenge: fly a mission inspired by ESA's JUICE program. While we wait for the RIME antenna to get itself unstuck, let's send good vibes ESA's way by flying our own multi-moon probes to the satellites of Jool! Now's a great time to polish up your gravity-assist chops.
Have a lovely weekend!
Keep up with all things Kerbal Space Program 🚀
KSP Forums
KSP Website
Intercept Games Discord
KSP YouTube
Who Are You?
My name is Darrin, and I'm the new Director of QA here at Intercept Games. I'm new to the Intercept team (I joined a week before the KSP2 launch) but I'm not new to QA. I've been doing software testing since the early 90s and worked at Visio/Microsoft for 17 years and then at Amazon for the last several years (most recently as a founding member of the Luna game streaming service). I'm an old-school hardcore gamer - I've been playing since I had "The Bard's Tale" on my Commodore 64; my Xbox gamer score is 150,000+ and I don't pad that with those silly games to just farm achievements! I'm doing my best to learn KSP2 as fast as I can, and just so happen to sit directly to Nate; I've received the rarely given "high five" that I will cherish always.
I'm here to help as much as I'm able. People here in the office GREATLY appreciate the feedback you give. To that end, we need to help make the flow of bugs that you find as easy as possible for all of us to track in our systems (for all of us).
Please contact Private Division Customer Support for any game breaking issues such as hard crashes. But, if you are posting about an issue, the more data we have the better (aka in the Specs discussion in Discord, you'll want to post your detailed specs info!).
Bugs and Stuff
Running into an issue is frustrating; I feel your pain. Trust me when I say, bugs drive us just as crazy as they do you (honestly probably more, because we need to retry them over, and over, and over!). But when you find an issue that is important enough to post about - you can do it one of two ways:
So, help us help you and please give us all the information we might need. Please submit your feedback on the KSP forums to ensure we see it. By giving us necessary information, this helps us move issues up the chain faster and keeps others from having to ask you for the same information over and over:
Helping Us Test
I can hear some of you now: "Hey...! Why do we have to do the work for you? I'll be 100% honest - you don't. Some bugs that come from the community have already been found by our QA team here. But sometimes, bugs can seem to be a "one off" or very difficult to put together consistent repro steps.
The more information we have and the more we know people hit it, the less time it will take to turn around a meaningful fix.
Why Did You Fix Bug A and Not Bug B?
"Wait...if the QA team is finding all these bugs, why aren't they all fixed?"
The process of deciding what bugs to fix is quite complex and is based on many factors. We do not always go after the easiest bugs to fix, but rather bugs we feel will have the largest customer impact at any given time. But at the same time, we must consider the impact of any bug that while fixed, could have other implications (aka regressions). We factor in the severity of the bug combined with its frequency, as well as a ton of insider knowledge from people here on the team; and we work very closely across all roles and make these decisions together as a team.
We care A LOT about bug regressions, so if you see a new bug that didn't exist previously, then please pass along the information to us and we'll look into it ASAP. But remember, a change to how something works from one build to another is not necessarily a bug. We're in Early Access and we'll make changes to how things work at times to see how that goes and iterate on that over time.
How Long Does Fixing a Bug Take?
Investigating a bug takes time to get a precise scenario for the engineer to address (that's why the steps and info above can help). They will then do their own investigation on the fix itself (what it would take, what parts of the code would be affected, how risky of a fix it is, could it break other parts of the title, etc.). Once that's approved, there is a code review of the changes that were made. Then the change is put into a specific branch/build of KSP2 where testers will do a full investigation of the original bug and do halo testing around the areas that the code affected. Finally, it goes into a release candidate build along with a bunch of other fixes, and it gets tested again in a very deep regression suite of tests to ensure that other (supposedly unrelated areas of the product) still function as expected. There's actually even quite a bit more to it than that - but it's a good summary of how we do things here.
How Do You Test a Game as Complex as KSP2?
Kerbal Space Program 2 is...huge. I've owned the testing of products that ship to hundreds of millions of users that had a simpler test matrix than KSP2 does. There are A LOT of areas, processes, and stages of testing a product; and I'm not going to go into all of them here (it would be a doc 20x longer than this). So, this blog is mostly focused on end-user reported issues and how we deal with those.
But with regards to complexity, our KSP2 Test Lead, Josh, who has been playing KSP since 2013 and testing it for the past five years, put some information together.
"Talking about the complexity of construction and variables for potential issues, there is a consideration on why something may not be known, tracked, or reproduced before.
How unique is your vessel? It's straightforward to test parts in a vacuum (the "by itself" kind, not specifically the "no air" kind) and confirm that all the bits and pieces are functioning as designed. However, interactions between various parts are where we often see things go sideways. There is a hierarchical interaction that can cause problems, is compounded by where it was placed relative to other parts, and when it was placed (order of construction). This is further exacerbated by what was done before the vessel was made and how it's been flown.
Let's break down possible iteration numbers to give an example as to the potential complexities available in KSP2:
If you were to use every stack attach part that has a top and bottom stack attach node in every possible permutation without duplicates, it would be factorial 245, which translates to a number 481 digits long. For reference, the estimated number of atoms in the known universe is only about 10^80 (10 to the 80th power), or an 81 digit number. So, this is interesting, but not realistic. In normal circumstances, you are not likely to build a vessel using EVERY stack attach part.
An example of how configurations can have impact, we recently fixed an issue with a handful of small parts that would cause the entire vessel to fly apart at a certain point in flight, only when used in conjunction with other specific (similar) small parts in a specific hierarchy order. Not all combinations of a vessel using those parts caused this, only in specific permutation orders.
One of the best ways to ensure a bug you encounter in flight is tracked is to give us as much information as possible. A log file and save help a lot, but if you have a workspace file for your vessel, in some circumstances, that can be even better.
There is more to this game than parts, but the above is a math-heavy example of the complexity we are working with in test. This is by no means the only game to have this many potential variations to consider, and it won't be the last, I am sure. The one takeaway is this, the more information that can be provided with the circumstances something went wrong, the quicker we can identify the issue. Attempting to reproduce issues with just a list of the 20 parts used to create a vessel? That could take a VERY long time."
All that being said - someone on the team did the math and even with our entire product team testing on a particular build of KSP2...our total user base will pass that time spent testing within hours of release.
We use a matrix method that combines every feature with frequency of use across all hardware combinations and operating systems. This testing effort is what really adds to the time between patches, and then if we combine bug fixing alongside of new feature development, it's big. Automation helps of course, but as users of the product you can understand that the majority of testing needs to be hands on.
It's not all crazy matrixes and slogs of testing we have to do. We also have fun playtest events with themes (quite a few are ones we do just before the Community team sends them out as challenges):
From the recent playtest where a Designer on our team, Chris, is trying to branch out from rockets.
How Big Is the QA Team?
I've worked at both Microsoft and Amazon as well as a few smaller companies, and our QA to developer ratio is on par with just about any team I've ever been on. We have a dedicated QA team here at Intercept Games (Seattle) who follows the feature crews as new features are developed and a larger QA team within Private Division (Las Vegas) who owns regression passes and overall validation. We supplement needs (hardware testing, OS's, etc.) with some vendor testing from time-to-time. We even have a large amount of previous hardcore Kerbal players that joined our team and have been helping us out, no matter their role (and I don't mean just Nate!). We've got a ton of experience on the team going back to the early KSP1 days as well as others who have come during KSP2 and are now some of the best creators on the team.
Here are a couple pics from Lo - who is a member of the PD QA team in Las Vegas.
What Are You Currently Working On?
You can pretty much look at the roadmap and see all the stuff that's coming. And, we're involved in ALL of that. Lately we've been deeply involved in Patch 1 and Patch 2, while at the same time getting early looks at features that are still quite a ways out - something like Multiplayer (below) is something we'll be involved in for a very long time and looking at it while we test all the other new features that are coming.
Min/Recommended Hardware Questions
Every company handles minimum requirements a bit differently, but we use them as our bar of initial support (aka we don't officially support or test anything below minimum requirements). We set that bar based on the performance checks we've done in-house during our testing and evaluation process. Some users may choose to try to run KSP2 on a below-the-minimum bar computer even though we don't officially support it and we allow that (aka we don't do a check at launch to determine hardware and force a hard stop at that point). This choice is a tough one, because we want to allow users who might have some very specific or unique hardware to try to run KSP2 and this allows some specs clearly below the min bar to try to run even though that will likely cause issues.
And that's where things can get crazy - because we'll see someone post on the boards that the game is unplayable and that they have a good computer to play it on, but after drilling in - the majority of the time the computer is below the minimum requirements bar (and the telemetry we currently have tells us the same story).
Somewhere between our recommended settings and our minimum settings is where we do the majority of our testing. We have a large variety of hardware in-house and we supplement that with vendor testing, but there will always be cases where users will try hardware that we haven't and don't have access to. In these cases, we greatly value the input from the user base and will acquire hardware from time-to-time ourselves, when needed, based on that info.
Constructive feedback can provide positive results. There was a very large thread on our Discord and a subset of users who all had specs below the min bar - they all had integrated graphics cards and were having very similar results (KSP2 wouldn't load at all). I checked with our Senior Engineer, Mortoc, on this topic and he suggested a potential workaround by having them set their Windows resolution to 1024x768 - and now most of them are now able to play. No promises of course since it's below the minimum requirements, but it's worth a shot if you are also having that issue.
Our goal is to improve the minimum requirements over time, but we can't guarantee where it will go to, or what those requirements will be. We'll use the data that comes in from users, our automated benchmarks that we run as well as in-house testing to monitor performance over time.
Building functional complex ships is a goal on the team as well. Marc, a tester on the team since early KSP1 days (aka Technicalfool on the Discord) sent these to me when I asked for a ship to use for testing.
The Best Way to Get Your Specs Info:
The more spec information we can get, the better that we can help you solve issues. Typing it in is great, but even the best of us can have a memory lapse and think we have 16GB when maybe we only have 12GB. Same with video cards - it can get super confusing; and if someone on the team is investigating an issue for you only to find out the specs you listed were incorrect...it's wasted time. So a screenshot of your specs is best and here's how you can get it:
If you are running via Steam, click "Big Picture Mode" in the upper right corner of the Steam window. Then bring up the menu from the lower left and choose: Settings ➟ System. Scroll down to the Hardware section and then screenshot/use the Snipping Tool to get the info needed. To exit this mode, click in the bottom left of the window and then click Menu ➟ Power ➟ Exit Big Picture Mode.
Alternatively, if you want more info, in Windows - hit the Winkey (⊞ Win) to bring up the start menu and type in: dxdiag. This will bring up the DirectX Diagnostic Tool. The first tab (System) will show your system model, processor, and memory. Now, just click the "Save All Information" button at the bottom, and it'll put everything into a text file.
Nothing in that file is harmful to send, but if you don't want to share everything else on there, screenshot the important areas.
The other tabs will give you information about your displays and video cards, which is typically important if you're having performance issues. If you have multiple monitors or a laptop connecting to a monitor - then you might have to click on the last display tab to see the correct video card information. Again, if you don't want to share all your info, screenshot the important stuff.
We're Here For You
The good, the bad, and even the ugly. We like to hear what you have to say. Our community team keeps us in the loop (and coordinates us doing stuff like this dev blog and the AMAs) and we love to meet and chat with you all in person as well. We had the opportunity to chat with some of you at GDC (had quite a few Mun and Minmus landings) and we're looking forward to more in-person events in the future.
My name is Darrin, and I'm the new Director of QA here at Intercept Games. I'm new to the Intercept team (I joined a week before the KSP2 launch) but I'm not new to QA. I've been doing software testing since the early 90s and worked at Visio/Microsoft for 17 years and then at Amazon for the last several years (most recently as a founding member of the Luna game streaming service). I'm an old-school hardcore gamer - I've been playing since I had "The Bard's Tale" on my Commodore 64; my Xbox gamer score is 150,000+ and I don't pad that with those silly games to just farm achievements! I'm doing my best to learn KSP2 as fast as I can, and just so happen to sit directly to Nate; I've received the rarely given "high five" that I will cherish always.
I'm here to help as much as I'm able. People here in the office GREATLY appreciate the feedback you give. To that end, we need to help make the flow of bugs that you find as easy as possible for all of us to track in our systems (for all of us).
Please contact Private Division Customer Support for any game breaking issues such as hard crashes. But, if you are posting about an issue, the more data we have the better (aka in the Specs discussion in Discord, you'll want to post your detailed specs info!).
Bugs and Stuff
Running into an issue is frustrating; I feel your pain. Trust me when I say, bugs drive us just as crazy as they do you (honestly probably more, because we need to retry them over, and over, and over!). But when you find an issue that is important enough to post about - you can do it one of two ways:
- A. "This game doesn't work! I can't play!!" (end of message)
- B. "This game doesn't work, here is some info and specific steps of what I was doing - please fix it!!" (adds a bunch of information we can work with)
So, help us help you and please give us all the information we might need. Please submit your feedback on the KSP forums to ensure we see it. By giving us necessary information, this helps us move issues up the chain faster and keeps others from having to ask you for the same information over and over:
- Title: A sentence that summarizes the issue.
- Specs: See 'The Best Way to Get Your Specs Info' section for how to give us all the info we need here.
- Severity: High/Med/Low. This is your opinion - but it typically goes: High = crash, Med = feature not working as expected, Low = there is an issue, but has a workaround.
- Frequency: High/Med/Low. Does this happen a lot? Can you reproduce it consistently? Or was it a one off? (We still want to know about one-offs, but we'll categorize it as such).
- Description: Tell us what you were doing, what you expected to happen, and what actually happened, etc. The more information here the better, we want specifics, not generalizations.
Helping Us Test
I can hear some of you now: "Hey...! Why do we have to do the work for you? I'll be 100% honest - you don't. Some bugs that come from the community have already been found by our QA team here. But sometimes, bugs can seem to be a "one off" or very difficult to put together consistent repro steps.
The more information we have and the more we know people hit it, the less time it will take to turn around a meaningful fix.
Why Did You Fix Bug A and Not Bug B?
"Wait...if the QA team is finding all these bugs, why aren't they all fixed?"
The process of deciding what bugs to fix is quite complex and is based on many factors. We do not always go after the easiest bugs to fix, but rather bugs we feel will have the largest customer impact at any given time. But at the same time, we must consider the impact of any bug that while fixed, could have other implications (aka regressions). We factor in the severity of the bug combined with its frequency, as well as a ton of insider knowledge from people here on the team; and we work very closely across all roles and make these decisions together as a team.
We care A LOT about bug regressions, so if you see a new bug that didn't exist previously, then please pass along the information to us and we'll look into it ASAP. But remember, a change to how something works from one build to another is not necessarily a bug. We're in Early Access and we'll make changes to how things work at times to see how that goes and iterate on that over time.
How Long Does Fixing a Bug Take?
Investigating a bug takes time to get a precise scenario for the engineer to address (that's why the steps and info above can help). They will then do their own investigation on the fix itself (what it would take, what parts of the code would be affected, how risky of a fix it is, could it break other parts of the title, etc.). Once that's approved, there is a code review of the changes that were made. Then the change is put into a specific branch/build of KSP2 where testers will do a full investigation of the original bug and do halo testing around the areas that the code affected. Finally, it goes into a release candidate build along with a bunch of other fixes, and it gets tested again in a very deep regression suite of tests to ensure that other (supposedly unrelated areas of the product) still function as expected. There's actually even quite a bit more to it than that - but it's a good summary of how we do things here.
How Do You Test a Game as Complex as KSP2?
Kerbal Space Program 2 is...huge. I've owned the testing of products that ship to hundreds of millions of users that had a simpler test matrix than KSP2 does. There are A LOT of areas, processes, and stages of testing a product; and I'm not going to go into all of them here (it would be a doc 20x longer than this). So, this blog is mostly focused on end-user reported issues and how we deal with those.
But with regards to complexity, our KSP2 Test Lead, Josh, who has been playing KSP since 2013 and testing it for the past five years, put some information together.
"Talking about the complexity of construction and variables for potential issues, there is a consideration on why something may not be known, tracked, or reproduced before.
How unique is your vessel? It's straightforward to test parts in a vacuum (the "by itself" kind, not specifically the "no air" kind) and confirm that all the bits and pieces are functioning as designed. However, interactions between various parts are where we often see things go sideways. There is a hierarchical interaction that can cause problems, is compounded by where it was placed relative to other parts, and when it was placed (order of construction). This is further exacerbated by what was done before the vessel was made and how it's been flown.
Let's break down possible iteration numbers to give an example as to the potential complexities available in KSP2:
If you were to use every stack attach part that has a top and bottom stack attach node in every possible permutation without duplicates, it would be factorial 245, which translates to a number 481 digits long. For reference, the estimated number of atoms in the known universe is only about 10^80 (10 to the 80th power), or an 81 digit number. So, this is interesting, but not realistic. In normal circumstances, you are not likely to build a vessel using EVERY stack attach part.
- If you assume people are only using about 30 stack parts in a single vessel stack (so a non-repetitive permutation of 30 out of 245 possible stack parts) you still end up with 7.429002947 E+70, or a number about 71 digits long.
- That’s permutations, however. What about just using specific parts together in general in no particular order (combinations)? That has to be a significantly smaller number right? Well, even dropping this down to only combinations using 15 of the 245 potential stack attach parts with double (top/bottom) attach points still gives us a total of 3.396886498 E+23 possible combinations (or a 24 digit number). For comparison, the number of stars in the sky is estimated only about 200 sextillion (or a 2 followed by twenty-three 0’s, also 24 digits long in total).
- Parts with a single stack attach node
- Stack parts that are attached radially (and the surface attach-only parts)
- Subassemblies that can be inside fairings/cargo bays
- Parts stack attached to other radially attached parts connected to the center stack of the vessel
- Adapters that allow stack attachments in other directions
- Adapters that allow a single stack to diverge or converge (such as bi/tri adapters)
- Translate/rotate transform parts (which also add new orientations to branch off from)
An example of how configurations can have impact, we recently fixed an issue with a handful of small parts that would cause the entire vessel to fly apart at a certain point in flight, only when used in conjunction with other specific (similar) small parts in a specific hierarchy order. Not all combinations of a vessel using those parts caused this, only in specific permutation orders.
One of the best ways to ensure a bug you encounter in flight is tracked is to give us as much information as possible. A log file and save help a lot, but if you have a workspace file for your vessel, in some circumstances, that can be even better.
There is more to this game than parts, but the above is a math-heavy example of the complexity we are working with in test. This is by no means the only game to have this many potential variations to consider, and it won't be the last, I am sure. The one takeaway is this, the more information that can be provided with the circumstances something went wrong, the quicker we can identify the issue. Attempting to reproduce issues with just a list of the 20 parts used to create a vessel? That could take a VERY long time."
All that being said - someone on the team did the math and even with our entire product team testing on a particular build of KSP2...our total user base will pass that time spent testing within hours of release.
We use a matrix method that combines every feature with frequency of use across all hardware combinations and operating systems. This testing effort is what really adds to the time between patches, and then if we combine bug fixing alongside of new feature development, it's big. Automation helps of course, but as users of the product you can understand that the majority of testing needs to be hands on.
It's not all crazy matrixes and slogs of testing we have to do. We also have fun playtest events with themes (quite a few are ones we do just before the Community team sends them out as challenges):
From the recent playtest where a Designer on our team, Chris, is trying to branch out from rockets.
How Big Is the QA Team?
I've worked at both Microsoft and Amazon as well as a few smaller companies, and our QA to developer ratio is on par with just about any team I've ever been on. We have a dedicated QA team here at Intercept Games (Seattle) who follows the feature crews as new features are developed and a larger QA team within Private Division (Las Vegas) who owns regression passes and overall validation. We supplement needs (hardware testing, OS's, etc.) with some vendor testing from time-to-time. We even have a large amount of previous hardcore Kerbal players that joined our team and have been helping us out, no matter their role (and I don't mean just Nate!). We've got a ton of experience on the team going back to the early KSP1 days as well as others who have come during KSP2 and are now some of the best creators on the team.
Here are a couple pics from Lo - who is a member of the PD QA team in Las Vegas.
What Are You Currently Working On?
You can pretty much look at the roadmap and see all the stuff that's coming. And, we're involved in ALL of that. Lately we've been deeply involved in Patch 1 and Patch 2, while at the same time getting early looks at features that are still quite a ways out - something like Multiplayer (below) is something we'll be involved in for a very long time and looking at it while we test all the other new features that are coming.
Min/Recommended Hardware Questions
Every company handles minimum requirements a bit differently, but we use them as our bar of initial support (aka we don't officially support or test anything below minimum requirements). We set that bar based on the performance checks we've done in-house during our testing and evaluation process. Some users may choose to try to run KSP2 on a below-the-minimum bar computer even though we don't officially support it and we allow that (aka we don't do a check at launch to determine hardware and force a hard stop at that point). This choice is a tough one, because we want to allow users who might have some very specific or unique hardware to try to run KSP2 and this allows some specs clearly below the min bar to try to run even though that will likely cause issues.
And that's where things can get crazy - because we'll see someone post on the boards that the game is unplayable and that they have a good computer to play it on, but after drilling in - the majority of the time the computer is below the minimum requirements bar (and the telemetry we currently have tells us the same story).
Somewhere between our recommended settings and our minimum settings is where we do the majority of our testing. We have a large variety of hardware in-house and we supplement that with vendor testing, but there will always be cases where users will try hardware that we haven't and don't have access to. In these cases, we greatly value the input from the user base and will acquire hardware from time-to-time ourselves, when needed, based on that info.
Constructive feedback can provide positive results. There was a very large thread on our Discord and a subset of users who all had specs below the min bar - they all had integrated graphics cards and were having very similar results (KSP2 wouldn't load at all). I checked with our Senior Engineer, Mortoc, on this topic and he suggested a potential workaround by having them set their Windows resolution to 1024x768 - and now most of them are now able to play. No promises of course since it's below the minimum requirements, but it's worth a shot if you are also having that issue.
Our goal is to improve the minimum requirements over time, but we can't guarantee where it will go to, or what those requirements will be. We'll use the data that comes in from users, our automated benchmarks that we run as well as in-house testing to monitor performance over time.
Building functional complex ships is a goal on the team as well. Marc, a tester on the team since early KSP1 days (aka Technicalfool on the Discord) sent these to me when I asked for a ship to use for testing.
The Best Way to Get Your Specs Info:
The more spec information we can get, the better that we can help you solve issues. Typing it in is great, but even the best of us can have a memory lapse and think we have 16GB when maybe we only have 12GB. Same with video cards - it can get super confusing; and if someone on the team is investigating an issue for you only to find out the specs you listed were incorrect...it's wasted time. So a screenshot of your specs is best and here's how you can get it:
If you are running via Steam, click "Big Picture Mode" in the upper right corner of the Steam window. Then bring up the menu from the lower left and choose: Settings ➟ System. Scroll down to the Hardware section and then screenshot/use the Snipping Tool to get the info needed. To exit this mode, click in the bottom left of the window and then click Menu ➟ Power ➟ Exit Big Picture Mode.
Alternatively, if you want more info, in Windows - hit the Winkey (⊞ Win) to bring up the start menu and type in: dxdiag. This will bring up the DirectX Diagnostic Tool. The first tab (System) will show your system model, processor, and memory. Now, just click the "Save All Information" button at the bottom, and it'll put everything into a text file.
Nothing in that file is harmful to send, but if you don't want to share everything else on there, screenshot the important areas.
The other tabs will give you information about your displays and video cards, which is typically important if you're having performance issues. If you have multiple monitors or a laptop connecting to a monitor - then you might have to click on the last display tab to see the correct video card information. Again, if you don't want to share all your info, screenshot the important stuff.
We're Here For You
The good, the bad, and even the ugly. We like to hear what you have to say. Our community team keeps us in the loop (and coordinates us doing stuff like this dev blog and the AMAs) and we love to meet and chat with you all in person as well. We had the opportunity to chat with some of you at GDC (had quite a few Mun and Minmus landings) and we're looking forward to more in-person events in the future.
Hi Kerbonauts!
We sat down with Design Director Shana Markham for another Ask Me Anything on Discord. She's been working at Intercept Games for 3 years! The full AMA can be found here, complete with an audio version. As a reminder, we're in Early Access! Plans can change.
Questions are organized by topic and include who/where the question came from. And we've heard your feedback-the next AMA will be even more varied in source and topic. Be sure to check the Discussion Board for the next AMA callout (date TBD). Thank you to everyone who submitted questions and tuned into the AMA!
All About Shana!
What is a design director? (enjoyer, Discord)
Gameplay and Game Design
What has been the process of bringing a solid gameplay foundation to player progression in KSP2? (StarHawk, KSP Forums)
Accessibility and Tutorials
What was the most important change in design of KSP2 from KSP1 that you feel is overlooked by the community? (viccie211, Discord)
Resources
How will resources be distributed across so many planets to give the player a reason to explore every world? If resources aren't the catalyst for exploration, how else do you plan on motivating exploration? (Astr0Guy5, KSP Forums)
Parts
As KSP has many parts that aren't exact recreations of real rocket parts, or are future technologies that don't exist yet, determining what stats like thrust and specific impulse sounds more involved than looking it up. Could you give an overview of the process the team uses to determine the stats for, say, a metallic hydrogen engine? (pschlik, Discord)
Science Mode
Will previous science parts from KSP be in KSP2? (Krzysztof, Discord)
Colonies
Will colonies feature automation gameplay (within the colony, so not the delivery route system)? It can look something like this: resource extractor building mines a raw source, resource refinery building makes a useable material out of it, assembly. (Acid_Burn9, Discord)
Interstellar
With interstellar technologies and travel on the roadmap, is relatively a thing in KSP2? Will KSP2 handle time dilation effects when traveling at high velocities to the target star system? (Angelo Kerman, KSP Forums)
If you read all of this (or scrolled to the bottom hehe)...snacks for you! 🍬
We sat down with Design Director Shana Markham for another Ask Me Anything on Discord. She's been working at Intercept Games for 3 years! The full AMA can be found here, complete with an audio version. As a reminder, we're in Early Access! Plans can change.
Questions are organized by topic and include who/where the question came from. And we've heard your feedback-the next AMA will be even more varied in source and topic. Be sure to check the Discussion Board for the next AMA callout (date TBD). Thank you to everyone who submitted questions and tuned into the AMA!
All About Shana!
What is a design director? (enjoyer, Discord)
- A design director is someone who is responsible for standards, practices, and excellence of a particular discipline. I oversee all of the designers over here at Intercept Games. I also make sure the designers here can learn and grow and become better designers every day.
- The VAB. There's a lot of cool moments that help new players learn how to build and fly. Exploring that design space allows more expert players to learn shortcuts to make things faster. It's a win-win on both sides of players.
- Glumo!
- Easy - Eve. It's beautiful and haunting. Also once you're there, you're never going back.
Gameplay and Game Design
What has been the process of bringing a solid gameplay foundation to player progression in KSP2? (StarHawk, KSP Forums)
- We have to answer 'how does progression give implicit and explicit goals'. If you look at something like Science, that's implicit. No one is directly telling you to go do experiments. Implicit goals are a better space for Kerbal since we're based on exploration. Explicit goals though, are way better for newer players, because it helps them learn what the game is about and what they can do. It also helps some players explore different areas of the game they may not have explored before.
- There's a lot to this. We have a handful of subject matter experts including professors and other outside sources. Internally, we read whitepapers and dive deep into all different types of topics. When I initially came into the project, I first knew Nate as "that guy who has a whitepaper about metallic hydrogen taped to his wall". With this game, we're not always working just with game designers - we're working with people who are passionate about aerospace which is fantastic.
- Most Difficult: Establishing the roadmap. We started from an endpoint "here's the game as a whole", buy when you go into Early Access, it's not 50% of each feature, it's milestone on milestone - each building on top of each other. It took us months to sort out. There's still moments where we think about moving things around, but trying to take this absolute behemoth of a game and parse it out into a bunch of different phases.
- Easiest: Sorting parts by types as a default in the VAB. When we started, we just sorted by size - but it caused difficulty with finding parts. Once we added sorting by types, it made sense to make it the default.
- Depends! Depends on the part and so many other aspects. For some parts we're working on right now, it's a pretty quick turnaround. But for a lot of the parts, we think about "what's the reality of this part" and then we go through the "what's the gameplay elements that this part could add?". From there we move into "okay, we understand what the user story will be when a player uses this part". We'll then do whiteboxes and think about how the parts will impact other parts in the game. Ultimately it depends.
- We kept it to 1/6 size for gameplay reasons. There's not more really on this. Basically if we brought the size up, it would directly impact the game negatively when compared to KSP1.
- Yes, and I totally understand the current implementation makes long distance missions pretty hard to do. I can't say when a change might come, but I can say we're talking about it a lot.
- One of the first big propulsion fuels that will come in is nuclear-based. As it comes to resources and biomes, Kerbin isn't a hotbed for uranium - so for all of you who choose to play Exploration, that will be the first time you need to look past Kerbin for things you need.
Accessibility and Tutorials
What was the most important change in design of KSP2 from KSP1 that you feel is overlooked by the community? (viccie211, Discord)
- Approachability. All of the little things that lead to more people coming to the game and moving away from opaqueness. Moving away from "hope you remembered this!!". We want players to come in, learn, try, fail, and want to try again. That doesn't happen if the game doesn't provide players the information and guidance needed to make those decisions. Which is complicated when you're dealing with a game that includes rocketry and orbital mechanics. We can't simplify that stuff, so we have to guide players carefully.
- The tutorial suite currently in the game is the beginning. For every milestone, we ask ourselves "what else can we add?". So yes, more tutorials to teach more advanced topics! Certainly when colonies comes out, advanced landings will be extremely useful. One of our writers did a knowledge-share internally about precision landings, and that taught us a lot about how in-depth that topic can be - and we have to figure out how to distill that down to make it approachable for new players.
- Glad to hear the tutorials are helping you get up and flying. We definitely want to do that. Some things we're working on: landing, interplanetary travel, basic troubleshooting, planes, and docking. We want each tutorial to build on top of the previous one.
Resources
How will resources be distributed across so many planets to give the player a reason to explore every world? If resources aren't the catalyst for exploration, how else do you plan on motivating exploration? (Astr0Guy5, KSP Forums)
- We could put a different resource on each planet, but it gates players into "you must do X or you will not proceed". We don't want to force players to go to every single place if they don't want to. Also that's not really true to reality either. Instead, we want to look at the various resources on a planet and how it plays into your space program. Especially with colonies and exploration, you may want to build a mining colony - but perhaps it's really far away and it's annoying to get to. So instead you go somewhere else and build an additional orbital colony to build resource pathways.
- Yes, you will gather raw resources and then refine them into what you need. Chris Adderly had a lot of fun building a production chain graph which I hope we one day get to release since it's really helpful to understand how it all flows together.
- To give a specific number, I think we're looking at 14-15 specific resources throughout the universe. Focused on what you need for propulsion. Same resource may be present in multiple locations, but prevalence/proximity to existing infrastructure are factors we're thinking about as well.
Parts
As KSP has many parts that aren't exact recreations of real rocket parts, or are future technologies that don't exist yet, determining what stats like thrust and specific impulse sounds more involved than looking it up. Could you give an overview of the process the team uses to determine the stats for, say, a metallic hydrogen engine? (pschlik, Discord)
- Whenever we look at introducing new parts, we group parts into certain stories and goals. That helps us understand certain behaviors and gameplay elements. For example, we command parts. All of the individual types of parts have stories that help players reach particular goals. Once you understand that, you figure out what the variable is that we can tweak. Like "okay maybe command pods have a better heat tolerance than landers". You derive formulas from the guidelines and then compare the parts together and look into the real life data, and ultimately we see how the parts build on top of each other. It's a crazy number of variables.
- We've moved some variants out as their own parts. Certainly a topic, but also would likely not appear in the same form as KSP1.
- Not fully sure on the 1.875M parts, but for the larger part categories you'll see this come with Interstellar because those engines are gigantic!
- Yes, we call these procedural parts. I believe the next one will be radiators which will come when heat returns. We add procedural parts when we feel like "wow there's a lot of parts that are samey". Wings 100% were a priority for us in Early Access and now we want to build on top of that.
- Not using oxygen is something we want to put through its paces for authenticity and gameplay values, maybe it's something we could do but also what do we and the player get out of this? Does it open it up too much? That's the beginning part of the conversation. There's a lot of good things in the atmosphere, so expect in the future that the Kerbals will start to give them more attention.
- Sure. Folks are familiar with the PAW from KSP1 (individual windows). In KSP2, we unified this to the PAM, the list of parts. The heart of that decision was based in accessibility - it can be really hard for some players to click on specific parts. This is a frequent conversation for our UI/UX group.
- Underwater bases definitely scare me a little, but we 100% want to support boats. KSP1 has some awesome boat content and we want to continue to allow that. But also.....there are some celestial bodies that might have some challenges you might need a boat for...
Science Mode
Will previous science parts from KSP be in KSP2? (Krzysztof, Discord)
- Parts will be different between the two games. In this case, the design team really wants to hit on their own building and flying usage challenges. You'll see less "let me put a thermometer on my command pod" and more "I've got this weird bulbous thing that performs an experiment and I need to build a rocket around it".
- No, we want to focus on the core experience of Science before considering adding parts that break game flow.
Colonies
Will colonies feature automation gameplay (within the colony, so not the delivery route system)? It can look something like this: resource extractor building mines a raw source, resource refinery building makes a useable material out of it, assembly. (Acid_Burn9, Discord)
- There's a colony dev blog that I did a long time ago, which still has things to keep in mind like "KSP is a game about designing cool rockets". Like if a player wants to launch the game and fly a mission to Duna, we don't want the player to have to do 30 minutes of colony overhead to start working towards that goal. We want to make sure automation is implemented to make sure the part of the game that is really important to us, rockets, continues to stay the main gameplay loop.
- Orbital colonies would follow a similar flow to terrestrial colonies and have the same toolset.
Interstellar
With interstellar technologies and travel on the roadmap, is relatively a thing in KSP2? Will KSP2 handle time dilation effects when traveling at high velocities to the target star system? (Angelo Kerman, KSP Forums)
- Nate talks about this...and it's terrifying. No other comment...
If you read all of this (or scrolled to the bottom hehe)...snacks for you! 🍬
Happy Friday, brave Kerbonauts!
A little bit of a slow news day here at Intercept Games as we gather feedback and data from our latest update and continue to work on stability, performance, thermal, and new features. I’ve spent more time than usual over the last week building rockets in the v0.1.2.0 build, and I’m relieved to see that my own personal points of frustration are mirrored in the feedback we’re getting from the community. I know we may sometimes seem remote, or that it may feel like your feedback submissions are falling on deaf ears. Not only are we collecting and reviewing your feedback, but the frequency with which you’re reporting on certain issues is incredibly helpful to our goal of prioritizing fixes. As always, we appreciate your patience as we work down the list and shore things up for update v0.1.3.0.
On the subject of updates: our patch update cadence is going to slow down a little bit. This does not mean we are slowing down development, though!
There are a couple of reasons for this, not least of which is that every time we release an update, we divert resources that would otherwise be focused on continuing to improve the game. We are always balancing our desire to improve the current Early Access experience against long-term goals that involve more time investment. So because of this, our main focus shifts to major features that are in progress, while still working on bug fixes. This is a very personal issue for me, because as a fan I want the game to be perfect and awesome right now! But since genies don’t actually exist, that’s not how we’ll arrive at the best version of KSP2. We will continue to release updates prior to our big Science Feature update, and hopefully a slower update cadence will mean that when they do go out, they contain more robust improvements. We are still working out what that exact cadence looks like, and I’ll update you here when I know more.
Among the improvements that we’re seeing this week here at the studio, our planetshine system has taken a very big leap forward, and the next patch will feel quite different at night. Now, reflected light from planets and moons is much more apparent both in space and on the night side of a celestial body. A little sample of what Jool-light looks like on the surface of Laythe:
This week's challenge: we're building sci-fi spacecraft! There are already some impressive entrants appearing in the Intercept Games' Discord...check this out from @S_Coriolis (on the KSP forums).
That flux capacitor! MWAH!
Have a great weekend!
Keep up with all things Kerbal Space Program 🚀
KSP Forums
KSP Website
Intercept Games Discord
KSP YouTube
Good afternoon, Kerbonauts!
I’m back from Spring break and all charged up by the great feedback we’ve been getting since the release of Patch Two. Thanks to all who have taken the time to share their feedback about the update - as always, it’s been very helpful to know what’s gone well and what needs improvement.
By far the most controversial element of the patch has been a change made to maneuver nodes that prevents players from planning maneuvers beyond the fuel allotment currently aboard their vehicle. This change was made to prevent the maneuver node from lying to the player - because maneuver plans in KSP2 factor in the behavior of the vehicle under thrust (a necessity for planning future long-burn interstellar flights), and because this behavior is contingent on the changing mass of the vehicle as fuel is expended, any planning that takes place beyond what is achievable with the current fuel load must necessarily give an incorrect result. That said, there’s clearly a desire to be able to do aspirational maneuver planning beyond a vehicle’s current capacity, as was possible in KSP1. Our team is looking at our options now, and we’ll update you here when we have a good solution. Thanks again for highlighting this as a feature that could use some more time in the oven.
Right now, we’re full steam ahead on new feature development for the upcoming Science update (timing TBD), as well as continuing work on performance, stability, and thermal systems. We’re also working on a few new parts, which we expect to release prior to the Science update. Chris Adderley (AKA Nertea) has cooked up some lovely vacuum-optimized engines with extensible nozzles to help fill out the upper end of the methalox progression. Here’s a sneak peek at one of them, built by artist Pablo Ollervides:
On to business!
Yesterday morning, Shana Markham, our Design Director, did our second AMA and gave some very detailed answers to some challenging questions - and she did a much better job than I did of pulling those questions from lots of different sources, including the KSP forum.
We’ve posted the audio from that AMA here, for those who missed it. This one is definitely worth a listen!
Lots of amazing creations on view in this week’s Community Highlights. While only a few images make the cut every week, be sure to check out the ksp2_bestof Discord for more amazing community creations! I’ve really been enjoying how we've all been channeling our Starship excitement into the game - check out this one from Sciencedude37:
Congratulations to SpaceX on flying Starship as far as they did, and breaking a whole lot of records (and one parked car) in the process. Fingers crossed for the next launch!
Finally, here’s the next Weekly Challenge: make a dragon! No, not the spacecraft. A literal dragon. Now get out there and creatively misuse those procedural wings!
🚀 <-- This rocket denotes a fix that community members directly helped our dev team fix. Thanks to all of you who send in bug reports!
Bug Fixes
Flight & Map
Optimizations
Saving & Loading
Parts & Stock Vessels
UI / UX
Construction
Environments
FX & Audio
Tutorials
Localization
Submitting Bug Reports and Feedback
If you'd like to provide feedback about this build, there are many different ways to do so:
Submit Feedback through the Game Launcher
Suggest a Change on the KSP Forums
Join us on Discord to discuss potential changes
Bug reports should be shared to either:
Private Division Customer Support
Dedicated Bug Reports on the KSP Subforum
Bug Fixes
Flight & Map
- 🚀 Fixed deletion of vessels without control during game save
- 🚀 Recovered Kerbals are accessible again from the VAB
- 🚀 Maneuver plans are now constrained by available fuel and will no longer provide false projections that extend beyond vehicle's capacity. R.A.P.I.E.R. engines must be set to Closed Cycle mode to allow accurate orbital maneuver planning
- 🚀 Stopped light parts from consuming EC after they are switched off
- 🚀 Fixed parts attached to some physicsless parts falling at launch
- 🚀 Improved fuel flow priorities
- 🚀 Fixed spacebar sometimes not triggering staging
- Improved handling of hover and click targets in Map view when multiple objects overlap
- Removed the "Disable Crash Damage" difficulty setting. This setting could cause issues preventing vessels from entering a landed state. If crash damage was disabled in playthroughs, it will now be enabled
- Burn timer status icons are now accurate when the burn is completed at the correct time
- Fixed issue where engines in Part Manager displayed incorrect "Deactivate" or "Activate" state
- Fixed issue preventing switching between vehicles in atmospheric flight. This is now possible as long as both vehicles are inside the high-fidelity physics bubble surrounding the observer
- Fixed a bug that can cause certain vessel configurations to be destroyed at frame of reference updates in flight
- Fixed a bug that caused uncontrolled vessels to be tagged as debris in certain scenarios
- Fixed collision detection in map mode for trajectories with impacts on Bop. Collision icons should now be displayed map trajectories for Bop
- Fixed CommNet partial/no connection after decoupling/undocking a probe
- Fixed a bug that could cause trajectory lines to incorrectly display as a non-closed orbit/escape trajectory
- Fixed a bug that could cause highlight dot markers to appear on some vessel joint connectors in flight
- Fixed a bug that caused main menu screen elements to persist into gameplay
- Fixed a bug to prevent some abrupt Kerbal animation changes
- Fixed an issue with jet engines that could cause the wrong engine mode to be selected
- Fixed a bug where Tim C. Kerman's hair could clip through his helmet
Optimizations
- 🚀 Fixed a memory leak in tutorials
- 🚀 Changed Kerbal Crew Cam to paginated format
- Optimized cubemap rendering to reduce memory usage and improve CPU performance
- Optimized memory usage for clouds and corrected issue in which clouds on some Celestial Bodies did not match quality settings
- Reduced GPU memory usage for surface scatter meshes (especially grass) by scaling render buffers to currently visible content
- Applied CPU optimization to SetPixel behavior
- Deactivated underwater state detection when flight camera not active
- PQS disabled when flight camera is not active
- Optimized memory usage of tree scatter by reducing texture duplication
- Implemented Ground Shading Quality settings
- Anti-tile is now disabled when low quality is selected
- Improved cloud memory usage
- Performance improvements when using vessel configurations with lots of resource sources
- Optimization on Kerbal IVA cameras
- Improved low graphical setting visuals in some scenes
- Additional flight camera optimization
- Optimized orbital nodes in map by not processing non-visible ones
- Optimized and improved KSC night lighting
- Fixed memory leak in terrain code
- Fixed bug preventing instanced runway light levels of detail from being rendered. Also fixed memory leak due to accumulated rendering calls associated with runway light levels of detail
- Fixed bug where game loaded in an unresponsive state due to issue with modification of master texture limit while texture mipmap streaming is running
Saving & Loading
- 🚀 Camera now returns to saved position and orientation when game is reloaded
- Proper save names are retained when loaded on another computer
- Updates to save data for missing camera YAW information
- Updates to save data information to ensure accuracy of camera information
- Save data changes for better handling of vessel and agency information
- Fixed issue where reverting or loading results in disappearance of vehicle
- Fixed a bug where Kerbals loaded in incorrect locations from a save made while EVA
- Fixed visual errors associated with the Loading Screen transition when loading a game from the VAB or Training Center
Parts & Stock Vessels
- 🚀 Kerbals in passenger modules now have IVA portraits and can exit the vessel
- Aeris stock vehicle is now oriented horizontally by default
- Optimized geometry and updated textures for the Mk2 "Phoenix"
- Reliant engine small model updates
- Swivel engine small model updates
- Fixed misaligned attach points on the Mk2 Lander
- Mk2 Inline Cockpit small model updates
- The surface attach node visual is now appropriately sized for the Bobus ladder
- Removed additional, erroneous attach points from the Mk3 Engine Mount
- Added missing part sub-name for the FL-T100 Methalox Fuel tank
- Fixed a value that could cause a flash when loading vessels with procedural wings
- Fixed a text issue where the incorrect size was displayed for the Clamp-O-Tron Jr. in the part description (all languages)
UI / UX
- 🚀 Updated the frequency of game paused and unpaused messages to help prevent spamming
- 🚀 Improved Terms of Service flow, added "Next" button to seizure warning screen, and corrected issue where legal text did not default to system language settings
- 🚀 Added ESC button functionality to close screens at the main menu
- 🚀 Time warp bar no longer displays when HUD is toggled off using F2
- 🚀 Notifications now persist when game is paused to make them easier to read
- 🚀 Fixed a bug that made it difficult to close the color manager window
- Staging stack resource readouts containing two different resources now display correct amounts for both entries
- Corrected various errors in Credits
- Updated styling for the Burn Timer window
- Reduced scroll wheel sensitivity for menus, including Language Selection, Launchpad, and Save/Load dialogs
- Removed non-functional Filter/Overlay button from Tracking Station
- Added "Return to KSC" button to Flight Report and Tracking Station dialogs
- Font and styling fixes to save dialogue windows
- Minor scaling improvements in the part information overlay window
- Limit on passive notifications that can be displayed at once (three)
- The color picker window is now moveable via click/hold/drag on the top of the window
- Update to Kerbal manager and Resource manager icons
- Updating active icon visibility for the wing editor UI when editing procedural wings
- UI updates to the location bar at the top of the screen
- The staging stack is now hidden when there are no stages present in the VAB
- The expand/collapse stages button is hidden when only one stage is present (which will have it's fully details displayed as fully expanded automatically)
- Fixed engine part manager status text
- Fixed bug where player could not select "Filter Options" in Tracking Station
- Fixed a bug with save data sort by date orders
- Fixed an issue that could cause some UI menu's to not respond to a mouse scrollwheel
- Fixed a bug with the current location menu reading the wrong location in some instances after exiting the Training Center
- Fixed an issue in the load workspace menu that could cause multiple workspaces to be highlighted at once
- Fixed a bug that would cause the timewarp bar to disappear in the tracking station
- Fixed an issue causing the scrollbar to not appear in the resource manager when a vessel had a large part count
- Fixed object picker sometimes not expanding initially in the tracking station
- Fixed buttons cut off in the Tracking Station
- Fixed UI issue where toggle button width and campaign menu difficulty level button width were not expanding with text content
- Fixed bug where the only ship name visible on the KSC Launch Pad UI was the last ship sent to the launchpad
- Fixed issue in which temperature gauges persist on screen after they have been turned off in Settings
- Fixed issue where game switches to Fullscreen upon entering the Graphics tab in Settings
Construction
- 🚀 Stage groups now remain in their proper order when switching between multiple assemblies in the VAB
- 🚀 The Parts Manager can now be opened for subassemblies in the VAB
- 🚀 Added proper handling of nested symmetry sets
- 🚀 Fixed an issue that could cause staging order to change when reverting to VAB with complex, multi-vessel workspaces
- 🚀 Fixed vehicle-in-floor VAB bug
- Iconography updated in the VAB for fairing editor controls, assembly anchor markers, and launch assembly markers
- Fixed a bug that removed struts and fuel lines from duplicated subassemblies in the VAB
- Fixed an issue with deleting an assembly sometimes failing when dropping the assembly in the trashcan
- Fixed warning in the Engineer's Report about vessel not generating electricity
- Fixed multiple instances where "center of" tools behaved unexpectedly when there was no vessel data
- Fixed a bug that caused procedural editor icons to sometimes persist into other areas of the title
Environments
- 🚀 Added new building illumination to KSC that activates and deactivates based on time of day
- 🚀 Kerbals are now properly illuminated on the launchpad at night
- 🚀 Updated collision meshes and materials for KSC parking garage
- 🚀 Loading a game near Eeloo or Pol no longer causes SetPixels errors
- 🚀 Improved distribution of rock scatter objects on Kerbin's surface
- 🚀 Fixed fuzzy "scan lines" visible on clouds when using AMD Graphics Cards
- Height fog added to Kerbin, Duna, Eve, and Laythe
- Celestial body ground scatter updates on Minmus, Eve, Eeloo, Ike, Duna, Mun, Tylo, and Bop
- Terrain scatter updates for Moho, Vall, Gilly, Laythe, Pol, and Dres
- Terrain shadow accuracy improvements on Minmus
- Fixed terrain artifacts at Eve's north and south poles
- Removed texture seams from grass around launchpads
- Improved appearance and performance of underwater caustic effects
- Fixed global illumination contributing on lighting on the opposite side of objects
- Fixed memory leak caused by lighting while in the VAB
- Fixed plants on Kerbin rendering incorrectly
- Fixed an issue that could cause blurry, pixilated terrain when viewing from a distance
- Fixed fog transition so that it should no longer pop into view at 60km
- Scaling updates to make KSC signs more uniform. This should improve and prevent distortion in various graphical settings and view distances
- Adjusted bloom and brightness during daylight hours in the Vehicle Assembly Building
- Clouds updated to remove linear features that can make them appear unnatural
- Setting cloud quality to LOW in the graphic settings now renders low quality clouds instead of no clouds
- Fixed an issue where low-quality settings could cause some cloud shadows to appear on vessels above the cloud heights
- Fixed bug preventing decals from rendering at KSC while moving between loading screens and game states where KSC is disabled
- Fixed a bug where water (and some other visuals) were not displayed properly when observed through gaps in parachutes
- Fixed a bug that caused water to reflect the galaxy sky map instead of the atmosphere/planet sky
- Minor lighting fix in the Training Center
- Minor collision updates for the VAB roof
FX & Audio
- Vacuum exhaust updates for the R.A.P.I.E.R. engine
- Updates to the timing on the plant flag EVA animation
- Updates to the sphere of influence entry and exit VFX
- Tim C. Kerman now has appropriate RCS thruster VFX
- Removed "out of fuel" sound from Sepratrons
- Fixed Tracking Station audio cue firing too often
- Improved trailing particle emitters to reduce VFX bugs associated with frame of reference changes
- Fixed jet engine audio starting/stopping too quickly when engines were deactivated/re-activated in the part manager
- Fixed an edge case where jet engines could show engine start VFX during timewarp
- Fixed Terrier engine exhaust scaling
Tutorials
- 🚀 The user is now returned to the Training Center after exiting a tutorial instead of KSC
- Updated tutorial preview images
- Fixed issue where game progresses too quickly during Tutorial 1.5
- Fixed tutorial vessel loading in a player campaign after completing a tutorial
- Fixed tutorial menus appearing on the main menu
Localization
- 🚀 Improved translations in several video subtitles
- 🚀 Updated localized terms for new game creation (all languages)
- 🚀 Fixed various localization issues in the part manager for Pods, Coupling, Fuel Tanks, Engines, and Utility (all languages)
- 🚀 Fixed missing text in some scenarios where actions cannot be performed yet due to loading (all languages)
- 🚀 Fixed a bug that could cause the End User License Agreement, Terms of Service, and Privacy Policy text to remain in the previous language after languages are changed in game
- 🚀 Fixed mislabeled EVA keybindings in the settings menu (all languages)
- 🚀 Localized text updates in the settings menu (Polish, Russian, German and Korean)
- Tutorial updates for all languages
- Fixed localization issues for Part Picker, UI, and Settings
- Updated font atlases to properly display special characters
- Fixed unlocalized text in the open workspace window
- Improved font fallbacks to avoid different size characters
- Translation updates for "Statistics" in the part info (all languages)
- Menu text updates (all languages)
- Part manager/info text updates (all languages)
- Fixed missing text on the KR4-P3 reactor (all languages)
- Stock vessel text updates (Portuguese)
- Updated loading tips in the (Chinese languages)
- Fixed a text formatting issue in the Training Center (Italian, French, German, Japanese)
- Save data font adjustments (Korean)
- Fixed a minor language issue, where the confirmation box was displayed in the previous language after making a language change in settings
Submitting Bug Reports and Feedback
If you'd like to provide feedback about this build, there are many different ways to do so:
Submit Feedback through the Game Launcher
Suggest a Change on the KSP Forums
Join us on Discord to discuss potential changes
Bug reports should be shared to either:
Private Division Customer Support
Dedicated Bug Reports on the KSP Subforum
Hello fellow Kerbonauts!
Okay, we've got a date for the v0.1.2.0 patch - it'll arrive next Wednesday, April 12. We'll post patch notes on that day as well. There's a nice blend of performance, stability, UI, and visual improvements, and we think these add up to a significantly improved KSP2 experience. One unheralded improvement, in addition to the already announced fixes - the nighttime lighting at KSC has taken a big step forward:
Meanwhile, we're continuing to work on upcoming Science Mode features, re-entry and thermal systems, and of course ongoing improvements to performance and stability. We've also begun some investigations into improving the currently wobbly rocket situation, and we should have more to discuss on that subject soon.
For today's Weekly Challenge, we're going to Eve! Until the future arrival of re-entry heating, you've got a great opportunity to do a little low-risk sightseeing (and if you visit after next Wednesday, you'll get to experience Eve's stunning new height fog, as well):
Also, check out this week's burger-iffic Community Highlights post. So many amazing creations this week! There's also a new TikTok!
I'm heading out for a few days' rest in a place that has sunshine, which means next week's updates will be made by guest writers. Please be nice to them, but also don't be so nice to them that my bosses decide I shouldn't do the posts anymore. Please be medium nice to them.
See you in two weeks!
--
Keep up with all things Kerbal Space Program:
KSP Forums
KSP Website
Intercept Games Discord
KSP YouTube
Hello Kerbonauts!
While last week's AMA was great, it looks like I forgot to check my staging when lining up the questions - many have pointed out that a lot of Discord queries got answered, but questions submitted through Steam and the KSP Forums were neglected. I'll try to be more conscious of that when the next AMA rolls around, but in an effort to right a past injustice, I'll answer a few of the questions that got missed right now! Here we go:
First, from Filip Hudak, on the forums: When we'll see other exotic fuel types like metallic hydrogen? Will they be added alongside some big update like colonies or will they be added before?
- We will be bringing in new engine and fuel types across multiple updates, generally as they become instrumental to the progression. I suspect nuclear pulse will be next up, as it opens up the interplanetary progression quite nicely and is a good supplement to colony building. Chris Adderley has also cooked up a few new methalox engines that I think will be popping up sooner rather than later.
- This is a good example of an area that's being developed iteratively. I think the first goal is to give players the ability to rescale the flight HUD, but making it modular and giving both players and modders more control over how things look is a key priority for the UX/UI team.
- The game's price will certainly increase when 1.0 arrives, though if you purchased the game during Early Access, you'll get all Early Access updates and the 1.0 update for free. After 1.0, we expect to continue providing free updates to the game, just like KSP1 did.
- I need to do a better job of evangelizing our capture camera controls! If you hit V, you can cycle through camera modes. When you're in Capture Mode, the numpad offers a bunch of new camera controls that you can combine to do smooth, swoopy pans, dollies, zooms, etc. You can combine these with paused time warp to do some pretty fancy stuff. Here are those controls:
- Zoom in: Keypad +
- Zoom out: Keypad -
- Roll left: Keypad 7
- Roll right: Keypad 9
- Orbit up: Keypad 8
- Orbit down: Keypad 5
- Orbit left: Keypad 4
- Orbit right: Keypad 6
- Pan up: Keypad 2 (or up arrow)
- Pan down: Keypad 0 (or down arrow)
- Pan left: Keypad 1 (or left arrow)
- Pan right: Keypad 3 (or right arrow)
- Mouse toggle: Backslash
- Speed up camera movement: Keypad *
- Slow down camera movement: Keypad /
- There are no current plans to do this - as you can imagine, it has some brain-bending multiplayer implications, especially when time warp gets involved. But it would be incredibly cool and I'm not aware of any specific technical blockers. It's certainly come up in conversations with Mortoc, our senior graphics engineer. I mean, we have a game with nuclear pulse engines...the fact that you can't make craters with them feels like a missed opportunity. So yeah, we'll keep talking about this.
Onto business. We have knocked out a few more bugs for Patch Two, including that pesky issue where vehicles with more than 8 parts in a radial symmetry set were loading into the floor. We've just about wrapped up the cherry picking process and can say with confidence that it'll be out sometime in the next two weeks. We'll post an exact date for Patch Two as soon as we know it.
As we continue stabilizing and improving performance, we're also making progress on re-entry heating, new parts, and Science Mode. And just to highlight that other, bigger systems are always being worked on in parallel, here's some pictures of our QA team goofing off in multiplayer:
Yes, collision is working:
Last week's Duna-focused Weekly Challenge yielded some incredible creations! If you're in the mood to see highlights, the most-upvoted posts on both the ksp2_challenges and ksp2_screenshots Discord channels are now archived in the ksp2_bestof channel. There, you'll see stuff like this:
Those hydrogen tanks shine up real nice!
Finally, an apology: we've had some minor technical difficulties getting the next Weekly Challenge put together, but we hope to be bale to get something posted over the weekend. We regret the delay.
--
Keep up with all things Kerbal Space Program:
KSP Forums
KSP Website
Intercept Games Discord
KSP YouTube
Hi Kerbonauts!
Last week we sat down with Creative Director Nate Simpson for our first Ask Me Anything on Discord! We got over 600 questions, collected from Discord, Steam, and the KSP forums. Nate answered a ton of questions-the full AMA can be found here. As a reminder, we're in Early Access! Plans can change.
We've tried our best to organize the questions based on topic, happy reading! Thank you to everyone who submitted questions and tuned into the AMA. We can't wait to do this again in the future!
Development and Community Feedback
Has there been any piece of community feedback/content that you and the team find especially motivating?
Rockets and Parts
How much time and research goes into deciding what kind of rocket/space plane parts get into KSP2?
Science Mode
Are there going to be any significant changes to the science system in KSP2, or any changes that you feel are worth talking about?
Colonies
Will certain resources needed for colony construction be planet/biome specific?
Interstellar
When interstellar is implemented, are the different solar systems going to be stationary or are they going to orbit something (to simulate a galaxy)?
Multiplayer
Can we get anything in writing related to the planned structure/function of multiplayer within the game, and how you plan to work around certain speedbumps like timewarp or two-player craft docking (ie where is the processing for this done?)?
Modding
What is your favorite KSP2 mod so far?
Post 1.0 Launch
Once the game is "complete" with everything on the roadmap implemented and debugged, is it possible development will continue with new features?
KSP2 Miscellaneous
Any plans to have a solid planet that is about the size of Jool or perhaps larger?
General MiscellaneousWhat non-KSP game/piece of media has inspired you and the team the most?
If you read all of this (or scrolled to the bottom hehe)...snacks for you! 🍬
Last week we sat down with Creative Director Nate Simpson for our first Ask Me Anything on Discord! We got over 600 questions, collected from Discord, Steam, and the KSP forums. Nate answered a ton of questions-the full AMA can be found here. As a reminder, we're in Early Access! Plans can change.
We've tried our best to organize the questions based on topic, happy reading! Thank you to everyone who submitted questions and tuned into the AMA. We can't wait to do this again in the future!
Development and Community Feedback
Has there been any piece of community feedback/content that you and the team find especially motivating?
- Anytime I hear about someone who wasn't able to get into KSP1 get into KSP2, that's incredibly motivating. Especially when it's kids. Feels great to hear kudos that someone feels we're on the right track with things, whether it be UI, soundtrack, etc. Howard, our composer, has been showered with praise upon the EA release - and it's SO deserved. When we hear nice things, it energizes us.
- So, the debug controls were really only added for internal developer purposes, and we haven't really done any QA testing - or really created any design specs for it. Adding a debug menu could change a million variables that would really make it hard to investigate bugs. I want there to be a player-focused debug menu one-day.
- Stability, performance, new features, in the order. Obviously, I am eager to see heat be implemented. We've shared the visuals but there's also the actual heating system. Thermal kinda feels like the final pillar we need for the structural outline of KSP2 to be complete so we can start building on top of it with the EA milestones.
- It's more parallel. People are focused on different things at the same time.
- Favorite things: probably tutorials. Tapped into my own passions as a storyteller, especially visual storytelling. Learning how we can convey complex topics with amazing animations.
- Least favorite: probably tutorials. We iterated like CRAZY with them - redid them multiple times. Multiple scripts, multiple animations, lots of work. We eventually had breakthroughs on each one, but it was a process.
- For me: see above - tutorials.
- For the team: heavy technical stuff. Adapting architecture to interstellar scale, accelerating trajectories, multiplayer. These make almost everything hard to implement, but we're making progress!
- For the in-game tutorials, we have quite a few already made. The animations are already made for 9 or 10 of them. As new features are being added to the game, tutorials will come alongside them.
Rockets and Parts
How much time and research goes into deciding what kind of rocket/space plane parts get into KSP2?
- A LOT. Chris Adderley (Nertea) is an amazing researcher and has a ton of existing knowledge. We also work with subject matter experts like Dr. Uni Shumlak from the University of Washington. We hold ourselves to the standard of rooting everything in game to real life science. Even if it's not a perfect implementation, if you look it up on Wikipedia you discover our features are real. We spend a lot of time on the Atomic Rockets website as well!
- This game is unique because we basically never say "no" to things. We often "defer" things because there's more important things to work on. Like for example, Chris and I want to add a proper airliner cockpit, but it's going to take time and effort from our team. Hopefully we'll get to it someday!
- This is a really good example of how having something in Early Access helps us iterate and develop features forward. This is definitely a hot topic, so here's my two cents: If a rocket is skinny and made of many stacked parts, it should wobble. Larger scales, no. We're working on it; it will get better.
- We have some very big engines that will arrive with the Interstellar update. People have seen the Crucible which is MASSIVE. Big Engines Coming!
Science Mode
Are there going to be any significant changes to the science system in KSP2, or any changes that you feel are worth talking about?
- For context, the first of the progression modes that will be coming in a roadmap update will be science mode. It will be similar to the KSP1 experience. Gaining science points, redeeming them for parts. Differences would include: We don't want people to be able to gather huge amounts of science around the KSC. We want to push people to explore and visit all the other Celestial Bodies. There will be an opt-in mission system that gives you a reward for doing a particular thing.
Colonies
Will certain resources needed for colony construction be planet/biome specific?
- The diversity of resources is what's going to make exploration mode so fun. Compared to KSP1 which was very self-directed (take temperatures, etc.), when there is a unique resource somewhere that gates your access to some category of parts/features - wow it totally changes the game. It gives you something material, the interplanetary/interstellar progression will really POP once you're able to dig up a specific thing that gives you a specific ability.
- There's no plan for an enforced upper-size limit. It'll be smaller to vehicles: it's made of parts - we want people to make it as large as they want. Obviously not all computers can handle massive builds, so there will probably be a player-dependent FPS-based size limit.
Interstellar
When interstellar is implemented, are the different solar systems going to be stationary or are they going to orbit something (to simulate a galaxy)?
- One of the things I learned very early in the project is that the movement of stars around a galactic center is very unintuitive compared to normal movement. Especially when you're dealing with stuff like dark matter, it's unpredictable. Our current implementation is that thye do move relative to the galactic plane, but we want other stars to be moving targets that you'll still have to get an intercept for.
- Short answer: yes.
- We've committed to three star systems leading up to 1.0. I'd love to add more circumstances permitting. That's not an official plan, but that's what I personally want. We always come up with cool ideas for new celestial bodies - and we want to add new bodies that create new kinds of gameplay. When we have those ideas, we definitely want to get them into the game!
- Completely critical to interstellar progression. You can't make an interstellar vehicle in gravity well. Someone will definitely prove me wrong about that one day.
Multiplayer
Can we get anything in writing related to the planned structure/function of multiplayer within the game, and how you plan to work around certain speedbumps like timewarp or two-player craft docking (ie where is the processing for this done?)?
- Generally, we try to not talk much about multiplayer but let me give you something. People will have separate timelines and then there will be a reconciliation phase when the players interact with each other. That's the plan right now but I also can't speak directly to the details of this feature - future comms incoming!
- There's something about single-player KSP2 that can be very meditative. I don't always feel the need to share what I'm doing with everyone. I think single-player will always have a place.
Modding
What is your favorite KSP2 mod so far?
- We are IMPRESSED by how many exist already. Selfishly, it's one from LinuxGuruGamer, someone who if you're part of the modding community you're probably already familiar with. It's a script that automatically collects relevant logs for bug reports to send our way. Definitely awesome.
- Already in progress. Some models actually need those insane polygon counts, like th IVA cockpits. Somethings unusually high polygon-count models slip through and we'll look to optimize them as our schedule allows. Patch notes will include lines such as "mesh optimization' which would basically be that.
Post 1.0 Launch
Once the game is "complete" with everything on the roadmap implemented and debugged, is it possible development will continue with new features?
- KSP got updates for over a decade. We want to do the same thing.
- Probably not before 1.0. There's a lot of work leading up to the full 1.0 release. When we get to it, we want to make sure it's fully implemented, so after 1.0...one day.
- Yes, I want it badly. Conversation will happen after 1.0.
KSP2 Miscellaneous
Any plans to have a solid planet that is about the size of Jool or perhaps larger?
- We do have a super-Earth in the game: Ovin. It's not as big as Jool, I think it's 60% larger than Kerbin. It has its own rings. It's big enough to make landing hard. No plans for a Jool-sized terrestial planet. Should we do it, community?
- Different atmospheres probably have different colors of plasmas - different ionization attributes. Going back to that iterative development point, the first version of re-entry heating will be one color, but the spec definitely calls for multiple colors based on location and atmospheric composition.
- We do not have short-term plans for that. We have planets with tilt, so we could implement weather and seasons. But, we have a long runway ahead of us. Never say never, but yeah if we wanted to implement these features, we'd want it to affect gameplay in some way, so we'd need to figure that out. There's also the whole 'once we implement more modding capabilities' to the game, it's totally possible something like this is added by the community.
- Yes. Yes. Yes. We did that stuff in the past, and we're so excited about the things they're doing. It really just matters what those institutions are doing. If anyone knows people there, we're waiting by our phones...
General MiscellaneousWhat non-KSP game/piece of media has inspired you and the team the most?
- There's a video called "The Wanderers" by Eric Wernquist. It's a beautiful, very short video, that definitely feels like our 'north star' for what we want KSP2 to feel like. It has these beautiful-rendered scenes of humankind exploring the solar system. We watch it fairly frequently and show it to new hires.
If you read all of this (or scrolled to the bottom hehe)...snacks for you! 🍬
While it’ll be tough to beat the sheer number of fixes that went into Patch One, we’re seeing quite a few big ones go down in Patch Two. We are still pulling a couple of late-breaking improvements into that build - once we’ve got it in QA’s hands we should be able to give you a date, and of course full patch notes will be posted when the build goes public. Until that time, here are a few things that are already checked into Patch Two:
- Fixed loss of vehicle on reference frame change when physicsless parts present
- Fixed flamed-out engines not restarting properly
- Enabled switching between vehicles in atmospheric flight (within PhysX bubble)
- Recovered Kerbals now return to VAB Kerbal Manager
- Gave click priority to planets rather than moons when zoomed out in Map view
- Struts and fuel lines no longer broken after cloning subassembly in VAB
- Fixed bug: vessels with no control deleted during save
- Fixed flowers on Kerbin
- Added "next" button to seizure warning screen
- Height fog added to all atmospheres
- Updated parking garage collision (now possible to enter structures)
- Various CPU and GPU optimizations to improve performance
Here are a couple of screenshots to show our progress. We have pruned all the hovering flowers made of squares and replaced them with flowers made of flowers:
We’re also pretty excited about how nice the new height fog is looking. It’s a subtle change, but it adds a lot of depth to the landscape:
In other news, I did a Discord AMA this morning. Thank you for all your questions - we received literally thousands of them and did our best to include as wide a variety as possible. This was lots of fun, and we’ll be doing more AMAs in the future! We’ll do our best to choose different questions the next time around so that things don’t get too repetitive. If you’ve got thoughts about how we can improve our AMA process, please let us know!
A written version of the Discord AMA will be posted within the next week. Stay tuned!
We’ve also got another Community Highlights post on the forum - it’s very exciting to see how Patch One has unblocked some more ambitious missions! Please keep sharing your creations in the #ksp2_screenshots and #ksp2_challenges Discord channels- our team is fueled by your crashes achievements! We’ve also added an upvote system to both of those Discord channels. If you like something, add an :upvote: emoji. If an image in one of those channels gets fifteen or more upvotes, it’ll appear in a new channel called #ksp2_bestof. If you posted a screenshot you’re proud of that has now been lost in the mists of time, feel free to resubmit your creation so that the community can give it the upvotes it deserves!
And speaking of Weekly Challenges, we’ve got a new one: this week, we’re heading out to Duna!
Have a great weekend!
--
Keep up with all things Kerbal Space Program:
KSP Forums
KSP Website
Intercept Games Discord
KSP YouTube
The v0.1.1.0 Update for KSP2 is live!
The complete patch notes for this update can be found below. We've had a few busy weeks!
https://store.steampowered.com/news/app/954850/view/3677790625554628815
First, the fine print: while this patch contains a lot of big improvements, it does not fix every bug in the game! This update represents the first step in an ongoing process of improvement that will continue through Early Access. If a high-profile bug that is especially important to you has not been addressed in this patch, please keep in mind that the order in which fixes roll out is not just contingent on priority — it also depends on the complexity of the problem that's causing the bug. The KSP community has done a very good job communicating their priorities to us, and we’re working to resolve the highest-impact issues first.
Among the changes we're most excited about (and again, check out the patch notes for the approximately 300 changes contained in this update):
- Optimized fuel flow calculations to cut processing by up to 3x and reduce garbage by half
- Improved joint strength for engine plate floating stack attach nodes
- Fixed R.A.P.I.E.R. engine mode-changing issues
- Fixed an issue that prevented loading of a saved game within an existing Campaign, caused workspaces not to load properly, and prevented saving the game
- Fixed issue that could cause some environment objects to spawn on top of the active vessel, causing KSC and other objects to move to the origin
- Fix for engine thrust being deflected at too high of a value when a part obstructs an engine’s exhaust (the Kraken Drive bug)
- Fixed physics impulse occurring when an engine runs out of fuel
- Fixed issue where some parts remain connected to/follow vessel after detachment
- Fixed stack decouplers staying connected to the vessel when staged with certain engines that have fairings enabled
- Fixed trajectory intercept patch not showing when captured by a Celestial Body
- Fixed stack decouplers operating as if crossfeed is active even when PAM entry shows crossfeed disabled
A few minor adjustments have been made to terrain around certain areas of interest (for example, collision has been restored to the bottom of the Mohole). There is a very small (but non-zero) chance that this update could cause issues with landed vehicles near those locations. If you do encounter such an issue with a saved game, you can revert to an older build to move your vehicle to safer ground.
We are hard at work on Patch Two and have already committed some important new changes to that build (upcoming fixes in Patch Two will fix fuel line issues that prevent asparagus staging, stop the unexpected in-flight destruction of vehicles equipped with physicsless parts, and allow vessel switching in an atmosphere, among other improvements). We don’t yet have a release date for Patch Two, but it should arrive sometime in the next few weeks. We will update you here when we know more.
As always, thanks for your patience and continued support. As you know, this is a very big game, and the community’s ability to shine lights on every corner has given us much better visibility in a lot of critical areas. We hope that the performance improvements and bug fixes in today’s patch open up new opportunities for fun, and we look forward to making the game even better.
--
Keep up with all things Kerbal Space Program:
KSP Forums
KSP Website
Intercept Games Discord
KSP YouTube
🚀 <-- This rocket denotes a fix that community members directly helped our dev team fix. Thanks to all of you who send in bug reports!
Bug Fixes
Flight & Map
Optimizations
Saving & Loading
Parts & Stock Vessels
UI/UX
Construction
Environments
EVA
FX & Audio
Tutorials
Localization
Known Issues
KSC Runway Lights LOD Visual Regression
Description: Players can see runway lights up close, but they are not visible from far away. This was a result of a major optimization fix for the lights.
Status: We are aware of this issue and will be looking to address this in a future patch.
Submitting Bug Reports and Feedback
If you'd like to provide feedback about this build, there are many different ways to do so:
Submit Feedback through the Game Launcher
Suggest a Change on the KSP Forums
Join us on Discord to discuss potential changes
Bug reports should be shared to either:
Private Division Customer Support
Dedicated Bug Reports on the KSP Subforum
Bug Fixes
Flight & Map
- 🚀 Fixed disappearance of orbital trajectories after loading a saved game
- 🚀 Fixed trajectory intercept patch not showing when captured by a Celestial Body
- 🚀 Fixed issue where some parts remain connected to/follow vessel after detachment
- 🚀 Fixed stack decouplers staying connected to the vessel when staged with certain engines that have fairings enabled
- 🚀 Fixed physics impulse occurring when an engine runs out of fuel
- 🚀 Fixed dV incorrectly using reinforced joint part connections for fuel flow calculations
- 🚀 Fix for engine thrust being deflected at too high of a value when a part obstructs an engine’s exhaust (the Kraken Drive bug)
- 🚀 Fixed loss of vehicle control after undocking
- 🚀 Fixed bug for probe cores spinning when losing Commnet connection
- 🚀 Fixed stack decouplers operating as if crossfeed is active even when PAM entry shows crossfeed disabled
- 🚀 Fixed issue that could cause some environment objects to spawn on top of the active vessel, causing KSC and other objects to move to the origin
- Fixed orbital velocity being shown when looking at the context menu of a landed vessel in Map view
- Fixed maneuver burn timer countdown lights activating incorrectly
- Fixed context menu opening when panning the camera with right mouse button while zoomed in to a celestial body in Map mode
- Added camera collision with terrain and other colliders while in Flight view
- Added visual indicator when a marker is hovered and pinned in Map view
- Fixed offset of radially-attached parts when player switches away from and back to Flight view
- Fixed the sim-side Center of Mass not being correctly updated by view-side rigidbodies
- Fixed physics-less parts adding the mass of their host part to Center of Mass calculations
- Fixed orbit/rigidbody synchronization issues when transitioning to/from physics and on-rails
- Made debris targetable
- Fixed dV calculation breaking when new empty stages are added while building a vessel in the VAB
- Fixed dV amounts appearing on the wrong stage when rearranging stages in the staging stack
- Fixed outboard elements of compound wings exhibiting reversed control surface reaction to pitch inputs
- Fixed issue with orbital marker not properly resetting its state when collapsed
- Fixed orbital markers not being pinnable while manipulating a maneuver and not staying pinned upon maneuver gizmo activation
- Fixed navball/controls getting stuck after accelerating in timewarp
- Fixed persistence of active vessel’s timewarp restrictions when returning to KSC from Flight
- Fixed pitch, yaw, roll, and throttle adjustment being possible while in hibernation mode
- Fixed planned trajectories changing when switching between Flight view and Map view while engine is firing
- Fixed dV calculations for stages with multiple engines with different burn durations and propellant rates
- Fixed resource system processing when request needs are only partially met
- Improved buoyancy calculations to reduce vessel spinning when splashing down in the ocean
- Fixed burn duration displays 0 until it is time to start the burn
- Fixed ETA to maneuver display to show a value for “days”
- Fixed dV calculations with cross feed in active stage of flying vessel
- Fixed dV changing to zero when fuel crossfeed is disabled on Docking Ports
- Fixed a bug where debris trajectories were not immediately shown in Map view
- Fixed a bug with thrust limiters missing for solid fuel booster engines
- Removed incorrect fuel transferability for solid fuel parts in the Resource Manager in Flight view
- Single part vessels now come to a stop on low gravity celestial bodies after a crash
- Fixed intercept nodes being in wrong positions during timewarp
- Updated detection arguments for recognizing when an aircraft is landed
- Fixed an issue with Stability Assist that could cause the loss of Prograde and Retrograde targets on the launchpad
- Fixed vessel not restoring correctly when reverting to launch from the runway
- Fixed Chase Camera mode to make selected zoom state persist
- Fixed part action groups breaking when an invalid action is included
- Fixed errors on Game Shutdown during TimeWarp
- Fixed destroy command not destroying vessels in the Tracking Station
- Fixed some instances where the action group manager would not trigger correctly when additional part actions are added to reserved action groups
Optimizations
- Optimizations in the engine part module to reduce per-update “not out of fuel” messaging
- Optimized engine exhaust damage calculations to reduce CPU impact of high engine counts
- Optimized ThrottleVFXManager to reduce CPU impact of per-frame material property updates
- Optimizations on EVA code
- Optimized Center of Thrust and Center of Mass marker code and fixed null shortcut failure states
- Optimized Kerbal hair compression scripts
- Optimized loading times in PQS code
- Optimization of unneeded cameras during loading
- Optimizations on EVA code
- Optimized loading times for the main menu
- Loading optimization for scatter meshes
- Optimized fuel flow calculations to cut processing by up to 3x and reduce garbage by half
- Optimized runway light meshes
- Fixed various texture and mesh memory leaks
- Updated Training Center to use texture streaming
- Fixed performance-impacting error state triggered by Kerbin’s clouds after returning to Kerbal Space Center from another celestial body
- Removed unnecessary log entries to improve performance
- Removed unnecessary logs when loading a saved game
- Reduced light source count for multi-nozzle engine parts
Saving & Loading
- 🚀 Added feature: game autosaves when landing on a celestial body, when entering an SOI, and when entering or exiting an atmosphere
- 🚀 Fixed an issue that prevented loading of a saved game within an existing Campaign, caused workspaces not to load properly, and prevented saving the game
- Fixed issue where reloading a save made at KSC results in reloading to active vessel in flight
- Fixed string in the Save Workspace menu
- Fixed an issue that could prevent new workspace saves being created when a control part was removed
- Fixed an issue that can prevent workspace saves from appearing in the load menu
Parts & Stock Vessels
- 🚀 Fixed R.A.P.I.E.R. engine mode-changing issues
- 🚀 Set all reinforced joint connections to grandparent
- 🚀 Improved joint strength for engine plate floating stack attach nodes
- 🚀 Performed wheel balance pass, including adjustment of all steering and torque curves
- 🚀 Increased range and brightness for vehicle lights
- Re-tuned fairing and cargo part mass
- Tuned mass for structural parts, trusses, nosecones and tail sections
- Tuned crash tolerance for external Grumble Seat
- Re-tuned electrical systems, including adjustments to xenon engine electrical draw, xenon engine thrust, reactor fuel burn rate, and RTG lifetime
- Tuned crash tolerance for landing gear
- Tuned docking reacquisition ranges
- Updated Hammer solid fuel booster model to match with other parts in the same size category
- Adjusted mass for HECS2 probe
- Updated emissive texture and material for the MK3 “Skybus”
- Fixed frustum culling for the Bobus mobility enhancer (ladder disappeared when base at edge of screen)
- Updated geometry and textures for the MK1 “Peregrine”
- Updates to textures and geometry for the Mk1 “Raven”
- Fixed texture seams on the R.A.P.I.E.R. engine
- Fixed RCS not working on the Mk3-5 command pod
- Minor bug fix on the Kerbal K2 stock vessel to fix issues with decoupling
- Updated collider for MK1 Tin Can to improve surface attachment behavior for radially-attached parts
- Updated default orientation for some adapter parts
- Updated default orientation for small square trusses
- Updated part placement rules for the HS-500 Heat Shield
- Updated models for decouplers and separators to match other parts in their size categories
- Updated geometry for LV-N “NERV” engine
- Updated team colors masks for the SP-XL "Gigantor" and SP-XXL "Colossus" solar panels
- Updated team color masks for decouplers
- Updated team color mask on engine endcaps
- Added Crew Light module to Skybus cab
- Fixed the Symmetry mirror direction and rotation for the Grumble Seat
- Fixed wheel motor resource usage being too low
- Adjusted default orientation of the MK3 Cargo Ramp
- Fixed fuel-containing aerodynamic parts (Mk1 Divertless Supersonic Intake, Engine Nacelle, or Engine Precooler) not showing resource slider in the Part Action Manager
- Tuning changes made to reaction wheels in command modules
- Adjusted the surface attach node to be on the ventral surface of Mk2 parts
- Fixed a bug preventing lights from consuming resources
- Fixed a bug preventing the Blink option from working on lights
- Fixed a bug with the heading orientation of the Sparrow default craft
UI/UX
- 🚀 UI performance improvements, including elimination of unnecessary redraw for unchanged bar elements and removal of pixel perfect on main gameplay canvas
- 🚀 Added a graphical representation for probe cores in Kerbal Flight portraits
- 🚀 Updated Map iconography, including orbital markers, trajectory colors, maneuver gizmo, focus item, and scrub handle
- 🚀 Fixed error where clicking on “Exit” in Main Menu produces warning modal that has no accept or cancel buttons
- 🚀 Fixed graphics quality settings conflicting with one another after resetting settings
- 🚀 Removed “Apply” button from settings menus, updating settings when changed, settings now apply immediately
- Fixed parts bin UI height in Staging Stack
- Performed color and consistency pass on the staging stack and launch button UI
- UI improvements to avoid overlap of intercept nodes in map view
- Fixed info panel UI element remaining active when panel is hidden in the Tracking Station
- Updated UI indicators in some tutorials and first-time user experience information
- Updated Resource Manager UI to match new resource gauges in Staging Stack
- Improved ESC menu user experience
- Fixed dark box getting stuck in the VAB when dragging the dialog window
- Fixed Kerbal Manager portraits appearing empty
- Fixed non-stock vessel thumbnails not appearing in launchpad menu
- Minor updates to improve building selection experience at Kerbal Space Center view
- Updated the executable icon
- Updated background image for vessel thumbnails in the launchpad load menu
- Updated saved vessel thumbnail design
- Updated styling on the action button inside the Part Action Manager
- Updated the game credits
- Updated game splashscreens
- Updated titles in the Resource Manager
- Updated dialog windows to accommodate longer text
- Updated close button on the Part Manager
- Updated missing text on the launchpad menu
- Added notification for inactive vessel entering a new SOI
- Fixed runway 1 and 2 having the same name when hovering over them in the KSC
- Fixed tooltips for Trigger Action Groups 2-10 being numbered incorrectly within the input settings menu
- Fixed Center Camera in VAB being in the wrong section in the input settings
- Added warning when rebinding the same key twice in input settings
- Fixed difficulty settings being saved from one save file's difficulty settings and being applied to every normal difficulty game save made afterwards
- Fixed difficulty options showing in the main menu settings
- Fixed failure of difficulty settings to apply when changed inside a campaign
- Fixed shader compiler error when switching graphics settings to Low Quality
- Added laptop audio mode to settings
- Fixed a bug where the “hold to quickload” setting was not applied correctly
- Added audio keyboard shortcuts to input settings menu
- Fixed escape menu freezing vessel controls in last-held state
- Fixed dialog being non-clickable when recovering a vessel with ESC menu deployed
- Fixed overlapping text in the flag removal dialog
- Fixed throttle visuals not updating when throttle adjusted
- Updated Tracking Station control text
- Minor updates to global header information
- Fixed Recover Vessel button in the ESC menu pushing elements off screen
- Fixed notifications using real world time instead of UT
- Fixed input lock problems when the ESC menu is visible
- Removed placeholder image that appears when no parts are favorited
- Updated Center of Mass, Thrust, and Pressure/Lift indicators in the Vehicle Assembly Building to make them translucent
- Fixed text overruns in the Training Center
- Alt+Enter toggles fullscreen
- Fixed a bug blocking some agency flags from being selected when starting a new game
- Added additional loading screens
- Fixed missing physical characteristics in the info panel inside the Tracking Station
- Fixed issues with the toggles for Map and Tracking Station displaying an incorrect state, or being hidden unintentionally
- Fixed all CBs are described as "Terrestrial planets" when viewed in the tracking station
- Updated the text string displayed for engine disabling/enabling in the Part Manager
- Updated text for lights in the Part Manager
Construction
- 🚀 Middle mouse button pans in the Z axis when in horizontal workspace mode
- 🚀 Fixed fairing sides getting deleted after building a procedural fairing and attaching it to a launch assembly
- 🚀 Fixed errors related to procedural wings preventing launch from VAB
- 🚀 Fixed issue where pressing M in the VAB opens the Map view
- Fixed description for Kerbol capture and Kerbosationary orbit trip stages in trip planner
- Fixed engineer’s report warning vessels cannot generate electricity when vessels are equipped with generators
- Adjusted default VAB camera angle for horizontal workspace mode
- Fixed hit area for the launchpad selection button in the VAB
- Confirmation prompt added when saving over workspaces
- Fixed assembly anchor error alert persisting onscreen and blocking the user from placing additional parts after the tool is deselected in the VAB
- Fixed Center of Thrust appearing on the ground of the VAB and not updating when launch assembly is changed
- Fixed display issues in the text on the orientation cube in the VAB
- Updated favorites panel information in the Vehicle Assembly Building Favorites category
- Fixed a bug where surface attach nodes were misaligned on some engine parts
Environments
- 🚀 Fixed an issue where ground textures were projected onto vehicles at the margins of the KSC grounds
- 🚀 Fixed Kerbin atmosphere disappearing when viewed from Mun’s SOI
- 🚀 Fixed collision at bottom of Mohole
- Fixed terrain decal normals not rendering correctly
- Reduced scatter meshes floating above terrain
- Updates to terrain texture matching for some points of interest
- Updated placement, coloration, and collision for various celestial body landmarks
- Updated colliders and stretched textures in the parking garage at KSC
- Scatter adjustments around KSC mountains
- Updated material on VAB elevators
- Fixed VAB gantry crane geometry
- Updated material on VAB doors
- Adjusted atmosphere settings for main menu background planet
- Fixed atmosphere not showing in cubemaps under some circumstances
- Improved atmosphere clipping issues while in Map view
- Fixed Laythe’s atmosphere rendering incorrectly in Map view
- Fix a bug that caused lighting to darken on vessels when reentering atmospheres
- Updated clouds on Jool
- Minor road line placement adjustments at Kerbal Space Center
- Fixed collision and updated materials for some points of interest
- Updated local space shader to restore missing normals in some biomes
- Updated KSC Training Center roof and Tracking Station dish to fix gaps in geometry
- Updated colliders around launchpads
- Updated Kerbin foliage
- Fixed invisible water above ground to east of KSC lakes
- Fixed scaled space clouds not displaying in map view
- Fixed cloud transition dithering issues
- Improved cloud masking to clean up edges of clouds seen behind vehicle
- Fixed clouds in Map view not lighting from the correct sun direction for all planets
- Fixed warnings in cloud-related code
- Fixed decals sliding and floating on planets
- Fixed decals getting culled incorrectly after transitioning to low orbit
- Fixed Laythe's Ocean appearing jagged, pixelated, and jittery after splashing down
- Fixed ocean shoreline fade out transition at some camera angles
- Improved LOD transitions for KSC trees
- Fixed mismatch between high-detail KSC and far-distance LOD material
- Fixed shadow system to switch to surface shadow mode in KSC view
EVA
- 🚀 Fixed issue with game saves made after vehicle destruction, in which reloading causes EVA camera mode switch and missing flight information/flight report
- 🚀 Fixed Kerbals floating when idle while in EVA
- 🚀 Fixed Kerbals getting stuck when swimming
- 🚀 Fixed Kerbals getting stuck inside the Mk1 Command Pod when it's on a flat surface other than the launchpad
- 🚀 Improved Kerbal run/walk animation transitions
- Fixed Kerbal surface velocity resetting when disabling RCS in EVA mode
- Updated EVA code to remove frame-related discrepancy between collision result values and character state values
- Fixed ground and step detection being one frame late for Kerbals while in EVA
- Fixed EVA tooltip remaining active when the HUD is hidden during gameplay
- Fixed inability to recover Kerbals when on EVA
- Fixed a bug preventing EVA jetpack from firing even when it has enough fuel
- Kerbals now require 1x timewarp when transitioning to EVA
- Fixed Kerbals being able walk on the sides of objects with collision
- Fixed climb action not being present for Kelus Long ladder and Bobus Extra Long Telescopic Mobility Enhancer
- Fixed errors when toggling Jetpack while TimeWarp is active
FX & Audio
- 🚀 Improved Kerbol flare/bloom effects
- 🚀 Fixed post process FX lighting transition in low orbit
- 🚀 Fixed an issue where contrails jump positions during universe reference point transitions
- Fixed ground blast effect occurring at invalid location for the first few seconds of launch
- Fixed SFX for Panther in afterburning mode
- Fixed errors on explosion VFX for hydrogen tanks
- Fixed VFX not showing on RCS thrusters when precision mode is activated
- Minor updates for non-explosive water impact VFX
- Launch VFX updates
- Updated R.A.P.I.E.R. engine VFX
- Updated launch smoke material
- Updated explosion materials
- Fixed audio timing for several animations
- Game audio balance pass
- Fixed a bug where audio was muted when entering numpad values in text entry bars on some menus
- Added maneuver alert and end sounds
- Added drag and drop staging sounds
- Added hydrogen and xenon tank destruction sounds
- Fixed launchpad music not playing when loading a save
Tutorials
- 🚀 Fixed issue where flight report appears when the user crashes a vessel inside a tutorial
- 🚀 Added “Enter” as keyboard input to advance tutorial dialogs
- 🚀 Fixed a bug that could cause the first-time user experience windows to remain open on the main menu
- Text adjustments in tutorials
- Text adjustments to subtitles for video tutorials
- Fixed soft lock error when restarting Tutorial 2.2
- Fixed some audio elements on Tutorial 2.4
- Fixed tooltips not displaying in the Tutorial pause menu during tutorial videos
- Adding scroll bar indicator to the booster selection step in the “Missing the Ground” tutorial
- Added fail stage when deleting the engine in the “Space is the Place” tutorial
- Fixed tutorial orientation video getting stuck when clicking at the end of the video progress bar
- Fixed subtitles in several languages for the video tutorial on the “Space is the place” tutorial
- Fixed file paths in tutorial saves
- Minor gameplay updates to the “Missing the Ground” tutorial
- Updated text in the VAB First Time User Experience
- Updated first-time user experience: “Out of Electricity” linked to electricity level instead of production rate
- Fixed a bug with videos not closing at appropriate times
Localization
- Fixed title text overlapping at the Training Center when localized
- Fixed unlocalized tooltips in the Timewarp bar
- Added missing localization terms for stockvessels
- Localization reformatted for new game creation
- Adjustments to text sizing and placement in the launchpad selection in some languages
- Fixed crash when returning to main menu from VAB
- Font updates for special characters in certain languages
- KSC Menu
- Flight HUD
- VAB
- Training Center
- Launchpad Menu
- Part Manager
- Tracking Station
- Settings
- ESC Menu
- Dialog Titles
- Notifications
- Action Group Manager
- Campaign Load Screen
- Part Action Manager
- Time Warp UI
- Tutorial Pause
- Wing Editor
- Map View
- Part Info Tooltip
- Video tutorials
- Passive notifications
- Merging Workspace Tutorial
Known Issues
KSC Runway Lights LOD Visual Regression
Description: Players can see runway lights up close, but they are not visible from far away. This was a result of a major optimization fix for the lights.
Status: We are aware of this issue and will be looking to address this in a future patch.
Submitting Bug Reports and Feedback
If you'd like to provide feedback about this build, there are many different ways to do so:
Submit Feedback through the Game Launcher
Suggest a Change on the KSP Forums
Join us on Discord to discuss potential changes
Bug reports should be shared to either:
Private Division Customer Support
Dedicated Bug Reports on the KSP Subforum
Good afternoon, fellow Kerbonauts!
We continue to make good headway on performance improvements and bug squashing. In fact, we managed to sneak a few additional fixes into the first patch, including a fairly high-impact resource flow optimization. We also fixed the "Kraken drive" bug that created insane reverse thrust when an engine’s nozzle was obstructed - so if you’re working on a Kraken ship, the "unique" physics on which it depends are about to go away forever. We may not in fact have killed the Kraken yet, but we have definitely stubbed its tentacle.
As to the timing of Patch One... QA is thoroughly testing the build right now, and as soon as they give us a thumbs-up, we’ll release it. Right now, our goal is to release that patch next Thursday (March 16th). Provided QA does not uncover any show-stopping bugs over the next few days, that date should hold. If they do run into something unexpected that needs to be fixed, that date will slip. We have done a fair amount of hand-wringing around whether we should announce the target date for this patch when there is a non-zero chance of a delay, but we know this topic is very important to you all, so we're doing our best to keep you all in the loop. We’ve also already completed a nice queue of fixes to go into the second patch, but we’ll talk more about that after we’ve got the first one out the door.
To help tide you over until then, we’ve got a new performance-focused dev blog post from Mortoc, our senior graphics engineer. If you’ve been wondering how we test performance and what we’re doing to improve it, this one’s definitely worth a read.
Finally, I just wanted to give a holler of support to the many people who have undertaken the weekly challenges - last week’s air-launched rocket challenge was a sight to behold, and we’re on the edges of our seats to see what mayhem will take place during this week’s Minmus challenge. If you want to take part (or just bask in the ingenuity and/or madness of our community), check out the Weekly Challenge Discord channel. Our Community Team has also picked out a few choice gems from the last week and added them to a Community Highlights post here. Yes, the shopping cart is in there. The shopping cart that flies.
Hi y'all,
I'm Mortoc, the new graphics programmer on the team. I wanted to take some time to chat about KSP2's graphics and performance-where we are today and what our process is and what the team's goals are.
As many of you have noticed, KSP2's performance isn't amazing at the start of Early Access. In a game as complex as KSP2, there are a dizzying number of areas that we could spend our efforts on and the feedback we're receiving is invaluable for us to focus our time on the issues that affect the players the most.
There are different reasons that the framerate can suffer. If the CPU is asked to do too much during simulation or if the CPU is asked to send too much data to the GPU in an organized fashion, it can make the framerate drop without maxing out the GPU. In most cases the performance in KSP2 is bottlenecked by the GPU, and since I'm a graphics engineer, that's what we're going to investigate in this article. Other engineers are working hard on CPU-facing improvements that you'll see reflected in upcoming updates.
Deep Dive Warning: Numbers Ahead
Before we dig into the numbers, let's start with a primer on what we're looking for here. Game developers tend to think of framerate in terms of milliseconds rather than FPS because it's easier to budget out your frame time that way. Converting from FPS to ms is simple, you just use the formula 1,000 / FPS = ms (for example: 100FPS means it takes 10ms per frame, 1,000 / 100 = 10). This way we're talking about how long a system takes to run directly. We want to measure how many milliseconds each system in the game takes in order to figure out which are taking too much time and dropping the framerate.
We use a tool called RenderDoc for our automated performance testing (among other tools). RenderDoc allows us to get the ground-truth timings for every single command sent to the GPU. Our tooling can then pull out the slowest GPU events for us to investigate.
The machine I'm using here for performance analysis is a laptop with i7-8650U CPU, Mobile Nvidia GTX 1060 6GB GPU and 16GB RAM. It has a slower GPU than our current min spec, so we're not expecting it to make a playable framerate yet.
KSC Landing Screen - 11FPS
In this scene, eight of the ten worst-offenders are related to PQS+. PQS stands for Procedural Quad System and it's the algorithm used to generate planet terrains. KSP2 uses a modified version of PQS from KSP1, generally referred to as PQS+ after all the modifications made to it for KSP2.
That table starts with a draw call to PQSRENDERTEMP, which emits 229,248 vertices. Each other draw call that uses that specific number is doing some work on the PQS mesh. The two draw calls not related to PQS in that table are the ones with a 6 in the name and are related to the cloud system. From this report we can see that the terrain clearly takes the most GPU time in this scene; 29.94ms in total.
Let's try another vantage point.
LKO - Low Graphics - 8FPS
As you travel away from any Celestial Body, we swap out the complex Local shader with a Scaled version that's much more efficient. This scene is from Low Kerbin Orbit, but still close enough to the planet to be using the Local version of the shader. PQS+ is again 8 out of the top 10 worst calls (the line Dispatch(12, 240,1) which is Draw Call #1 is from at the start of the frame when we kick off a compute shader to generate the terrain mesh). That first PQS+ call that took over 10ms is especially dirty.
Staying Grounded
Clearly the PQS System and related shaders are a big performance problem. Let's talk about that, but first dig into some background. A core philosophy for the early part of KSP2's EA cycle is to make sure "it still feels like a KSP game". This means that for each feature we build, we want to start with what KSP1 did and then build a similar system that improves on it.
Following that goal, the team started with the PQS design from KSP1 and added modern graphics features for KSP2's PQS+. As development progressed on KSP2, more and more features were added to PQS+ to keep pushing the artistic envelope.
I might be biased, but from orbit, Kerbol's planets look incredible. Our art team did a fantastic job. From the surface the game is still quite pretty, but the terrain itself just doesn't have the consistent visual quality we want yet. While trying to build that ground up to our visual ambitions, we added more features than the previous PQS architecture can support. It wasn't until the ramp up to EA that it became understood just how far past the limits of the tech we had reached.
Future Trajectory
OK, so, clearly there's a problem, what are we going to do about it? A few things are being done simultaneously. First, we're prioritizing performance optimizations for this system over the next couple of patches. Particularly for when graphics settings are "LOW", we want this system to be eating far less GPU time. This takes two forms: one is pure engineering optimization that doesn't affect final graphics, the other is to disable certain visual features when the graphics are set to "LOW" or "MEDIUM". That first category, engineering-only fixes, was taken about as far as it could be with PQS+. Our short-term plans are currently focused on the second category, turning off features that don't provide enough bang for the buck.
Here's an example of an optimization that affects the visuals. Coming soon in a patch, we will be able to turn off the Anti-Tile system in the terrain. In a bunch of places, the effect is negligible, but you can see the Eve surface has a repetitive texture artifact without it. This visual polish comes at the cost of accessing each texture a few more times, putting strain on the memory bandwidth of the GPU. Disabling this effect can have a small-to-medium sized effect on the framerate, depending on the GPU in question.
Optimizations like that one are happening now and will arrive in the next few updates. The rest of this article deals with systems that are in progress, so we cannot make specific promises about timelines or features until further along in development. But here's where we're heading:
In the medium term, my first major project on this team is to design and build a next-generation terrain system - what we're calling the CBT system (it uses a Concurrent Binary Tree data structure, but it could also stand for Celestial Body Terrain). PQS+ has served us well, but nowadays video cards are much more flexible and there are more modern approaches that will give us better results in terms of performance and visual quality. Exciting new earth-shaking architectures are possible. The next-gen CBT system will be the topic of a future dev blog which will contain a much more detailed look at what we're building. While it's too early to share any details, I will say that I'm excited about the artistic expressiveness, potential terrain variety, and performance of the CBT system.
Another area that will see a major shift in visual quality and performance is bringing the game up to Unity's modern renderer, HDRP (read more about HDRP here if you're curious, it rocks). The main benefits we get from HDRP are a more optimized render engine, which means faster framerates, and a more flexible shader model, which means more effective dev team efforts. It'll also make it easier for visual mods to be built. As a sidenote, despite how much we love you modders, this change will definitely break most visual mods (sorry modders, sometimes we must hurt the ones we love).
These in-progress changes will allow us to build more scientifically grounded yet fantastical worlds for the Kerbals to explore for years to come.
--
Keep up with all things Kerbal Space Program:
KSP Forums
KSP Website
Facebook
Twitter
Instagram
Intercept Games Discord
KSP YouTube
I'm Mortoc, the new graphics programmer on the team. I wanted to take some time to chat about KSP2's graphics and performance-where we are today and what our process is and what the team's goals are.
As many of you have noticed, KSP2's performance isn't amazing at the start of Early Access. In a game as complex as KSP2, there are a dizzying number of areas that we could spend our efforts on and the feedback we're receiving is invaluable for us to focus our time on the issues that affect the players the most.
There are different reasons that the framerate can suffer. If the CPU is asked to do too much during simulation or if the CPU is asked to send too much data to the GPU in an organized fashion, it can make the framerate drop without maxing out the GPU. In most cases the performance in KSP2 is bottlenecked by the GPU, and since I'm a graphics engineer, that's what we're going to investigate in this article. Other engineers are working hard on CPU-facing improvements that you'll see reflected in upcoming updates.
Deep Dive Warning: Numbers Ahead
Before we dig into the numbers, let's start with a primer on what we're looking for here. Game developers tend to think of framerate in terms of milliseconds rather than FPS because it's easier to budget out your frame time that way. Converting from FPS to ms is simple, you just use the formula 1,000 / FPS = ms (for example: 100FPS means it takes 10ms per frame, 1,000 / 100 = 10). This way we're talking about how long a system takes to run directly. We want to measure how many milliseconds each system in the game takes in order to figure out which are taking too much time and dropping the framerate.
We use a tool called RenderDoc for our automated performance testing (among other tools). RenderDoc allows us to get the ground-truth timings for every single command sent to the GPU. Our tooling can then pull out the slowest GPU events for us to investigate.
The machine I'm using here for performance analysis is a laptop with i7-8650U CPU, Mobile Nvidia GTX 1060 6GB GPU and 16GB RAM. It has a slower GPU than our current min spec, so we're not expecting it to make a playable framerate yet.
KSC Landing Screen - 11FPS
In this scene, eight of the ten worst-offenders are related to PQS+. PQS stands for Procedural Quad System and it's the algorithm used to generate planet terrains. KSP2 uses a modified version of PQS from KSP1, generally referred to as PQS+ after all the modifications made to it for KSP2.
That table starts with a draw call to PQSRENDERTEMP, which emits 229,248 vertices. Each other draw call that uses that specific number is doing some work on the PQS mesh. The two draw calls not related to PQS in that table are the ones with a 6 in the name and are related to the cloud system. From this report we can see that the terrain clearly takes the most GPU time in this scene; 29.94ms in total.
Let's try another vantage point.
LKO - Low Graphics - 8FPS
As you travel away from any Celestial Body, we swap out the complex Local shader with a Scaled version that's much more efficient. This scene is from Low Kerbin Orbit, but still close enough to the planet to be using the Local version of the shader. PQS+ is again 8 out of the top 10 worst calls (the line Dispatch(12, 240,1) which is Draw Call #1 is from at the start of the frame when we kick off a compute shader to generate the terrain mesh). That first PQS+ call that took over 10ms is especially dirty.
Staying Grounded
Clearly the PQS System and related shaders are a big performance problem. Let's talk about that, but first dig into some background. A core philosophy for the early part of KSP2's EA cycle is to make sure "it still feels like a KSP game". This means that for each feature we build, we want to start with what KSP1 did and then build a similar system that improves on it.
Following that goal, the team started with the PQS design from KSP1 and added modern graphics features for KSP2's PQS+. As development progressed on KSP2, more and more features were added to PQS+ to keep pushing the artistic envelope.
I might be biased, but from orbit, Kerbol's planets look incredible. Our art team did a fantastic job. From the surface the game is still quite pretty, but the terrain itself just doesn't have the consistent visual quality we want yet. While trying to build that ground up to our visual ambitions, we added more features than the previous PQS architecture can support. It wasn't until the ramp up to EA that it became understood just how far past the limits of the tech we had reached.
Future Trajectory
OK, so, clearly there's a problem, what are we going to do about it? A few things are being done simultaneously. First, we're prioritizing performance optimizations for this system over the next couple of patches. Particularly for when graphics settings are "LOW", we want this system to be eating far less GPU time. This takes two forms: one is pure engineering optimization that doesn't affect final graphics, the other is to disable certain visual features when the graphics are set to "LOW" or "MEDIUM". That first category, engineering-only fixes, was taken about as far as it could be with PQS+. Our short-term plans are currently focused on the second category, turning off features that don't provide enough bang for the buck.
Here's an example of an optimization that affects the visuals. Coming soon in a patch, we will be able to turn off the Anti-Tile system in the terrain. In a bunch of places, the effect is negligible, but you can see the Eve surface has a repetitive texture artifact without it. This visual polish comes at the cost of accessing each texture a few more times, putting strain on the memory bandwidth of the GPU. Disabling this effect can have a small-to-medium sized effect on the framerate, depending on the GPU in question.
Optimizations like that one are happening now and will arrive in the next few updates. The rest of this article deals with systems that are in progress, so we cannot make specific promises about timelines or features until further along in development. But here's where we're heading:
In the medium term, my first major project on this team is to design and build a next-generation terrain system - what we're calling the CBT system (it uses a Concurrent Binary Tree data structure, but it could also stand for Celestial Body Terrain). PQS+ has served us well, but nowadays video cards are much more flexible and there are more modern approaches that will give us better results in terms of performance and visual quality. Exciting new earth-shaking architectures are possible. The next-gen CBT system will be the topic of a future dev blog which will contain a much more detailed look at what we're building. While it's too early to share any details, I will say that I'm excited about the artistic expressiveness, potential terrain variety, and performance of the CBT system.
Another area that will see a major shift in visual quality and performance is bringing the game up to Unity's modern renderer, HDRP (read more about HDRP here if you're curious, it rocks). The main benefits we get from HDRP are a more optimized render engine, which means faster framerates, and a more flexible shader model, which means more effective dev team efforts. It'll also make it easier for visual mods to be built. As a sidenote, despite how much we love you modders, this change will definitely break most visual mods (sorry modders, sometimes we must hurt the ones we love).
These in-progress changes will allow us to build more scientifically grounded yet fantastical worlds for the Kerbals to explore for years to come.
--
Keep up with all things Kerbal Space Program:
KSP Forums
KSP Website
Intercept Games Discord
KSP YouTube
Known Issues with Recommended Workarounds:
Known Issues Being Actively Worked On:
This list is not exhaustive-we are tracking and working on a number of additional issues. If you have non-bug feedback during Early Access, please submit that feedback through the form in the launcher. If you've run into a bug (or think you have) please go to Private Division Support.
- Graphics settings default to “high quality” on first playthrough. If you are having framerate issues on initial load, access Settings via the ESC menu and select alternate quality settings.
- Fuel flow and Delta-V calculations are currently undergoing optimization, but on day 1 of Early Access, high numbers of engines pulling from a common fuel source may impact framerate. If you’re having trouble achieving a desired framerate on your machine, consider using a smaller number of higher-performance engines on your vehicle. This issue is very high priority for us and will be addressed in an upcoming update.
- The center of lift indicator does not yet update dynamically when you adjust a wing in the editor - to see the effects of a wing modification, you must first exit the editor to update the center of lift.
- In KSP2, the arrow keys now pan the camera, rather than rotating it (right mouse button still rotates the camera). If you get the camera in an undesirable state, press the Home key on your keyboard to reset it to its default position.
Known Issues Being Actively Worked On:
- Some parts from the original KSP aren't available-a few parts won't carry over — for example, the increased flexibility of the new engine plate system has reduced the need for bespoke compound parts like the Twin Boar and Mammoth engines. Also, the old patchwork wing parts have been supplanted by procedural wings. Other parts (for example A.I.R.B.R.A.K.E.s) are still in development and will be added in future updates. And of course Science collection, future propulsion, and colony parts will be added alongside their respective feature updates.
- There are still a few issues with our serialization code, and very rarely (especially when building high-complexity vehicles) your vehicle may collapse into an unrecoverable pile of parts on the floor of the VAB. The undo key may also break your in-progress build. For now, it’s a good idea to save frequently.
- Trip planner – the trip planner occasionally displays inaccurate delta-v numbers for some destinations. All delta-v numbers in the VAB use vacuum specific impulse numbers, which affects their accuracy. This will be addressed in a future update. Delta-v numbers shown in the staging stack during flight dynamically reflect the current flight state.
- Re-entry heating and thermal systems are offline - you'll have a brief window here at the beginning of Early Access during which you can re-enter any atmosphere without a heat shield. We’re still buttoning down our heat transfer, ablation, and occlusion systems. Vapor cone visual effects are also still in-progress.
- No collision on trees or rocks - we're optimizing collision for these objects right now, and in the interest of maintaining good framerates we're going to complete that optimization work before letting you crash into these objects. For now, they're holograms. While KSC buildings ARE collideable, they are not yet destructible.
- Framerate stutters/lag - we're continuing to work down the list of performance optimizations, from highest to lowest impact. As we push processes out of the main thread and continue to improve the efficiency of our physics, resource flow, VFX, and graphics systems, framerates should improve for all players.
- Some UI elements can be challenging to interact with - we're still cleaning up the systems that give priority to different classes of information in the map view, and there are times when you need to click a few extra times to get a hold of the maneuver planner. Similarly, you may have some challenges associating selected parts with their data in the Part Manager. We’re making several changes to the current UI so you can expect this experience to improve over time.
This list is not exhaustive-we are tracking and working on a number of additional issues. If you have non-bug feedback during Early Access, please submit that feedback through the form in the launcher. If you've run into a bug (or think you have) please go to Private Division Support.
Kerbonauts, it’s finally time!
Kerbal Space Program 2 blasts off into Early Access today! Pioneer the game with us as we enter the deep space journey of Early Access. Your feedback and suggestions can help shape the future of the game. Make sure to join the Discord, Subreddit, and/or forums, and follow us on social media! We’ll be posting frequent game development updates, challenges, and much more across these channels. Don’t miss out!
For information on how to submit feedback, check here: Feedback FAQ.
Grab a snack and delve into Kerbal Space Program 2 Early Access! We can't wait to see what you build, discover, and accomplish.
From us at Intercept Games and Private Division, thank you for your support. Enjoy a new cinematic trailer to watch over and over! Happy launching!
https://store.steampowered.com/app/954850/Kerbal_Space_Program_2/
--
Keep up with all things Kerbal Space Program:
KSP Website
Facebook
Twitter
Instagram
Intercept Games Discord
KSP YouTube
Kerbal Space Program 2 blasts off into Early Access today! Pioneer the game with us as we enter the deep space journey of Early Access. Your feedback and suggestions can help shape the future of the game. Make sure to join the Discord, Subreddit, and/or forums, and follow us on social media! We’ll be posting frequent game development updates, challenges, and much more across these channels. Don’t miss out!
For information on how to submit feedback, check here: Feedback FAQ.
Grab a snack and delve into Kerbal Space Program 2 Early Access! We can't wait to see what you build, discover, and accomplish.
From us at Intercept Games and Private Division, thank you for your support. Enjoy a new cinematic trailer to watch over and over! Happy launching!
https://store.steampowered.com/app/954850/Kerbal_Space_Program_2/
--
Keep up with all things Kerbal Space Program:
KSP Website
Intercept Games Discord
KSP YouTube
Hey Kerbonauts, KSP Community Lead Michael Loreno here. I’ve connected with multiple teams within Intercept after ingesting feedback from the community and I’d like to address some of the concerns that are circulating regarding KSP 2 performance and min spec.
First and foremost, we need to apologize for how the initial rollout of the hardware specs communication went. It was confusing and distressful for many of you, and we’re here to provide clarity.
TLDR:
The game is certainly playable on machines below our min spec, but because no two people play the game exactly the same way (and because a physics sandbox game of this kind creates literally limitless potential for players to build anything and go anywhere), it’s very challenging to predict the experience that any particular player will have on day 1. We’ve chosen to be conservative for the time being, in order to manage player expectations. We will update these spec recommendations as the game evolves.
Below is an updated graphic for recommended hardware specs:
I’d like to provide some details here about how we arrived at those specs and what we’re currently doing to improve them.
To address those who are worried that this spec will never change: KSP2’s performance is not set in stone. The game is undergoing continuous optimization, and performance will improve over the course of Early Access. We’ll do our best to communicate when future updates contain meaningful performance improvements, so watch this space.
Our determination of minimum and recommended specs for day 1 is based on our best understanding of what machinery will provide the best experience across the widest possible range of gameplay scenarios.
In general, every feature goes through the following steps:
Get it working
Get it stable
Get it performant
Get it moddable
As you may have already gathered, different features are living in different stages on this list right now. We’re confident that the game is now fun and full-featured enough to share with the public, but we are entering Early Access with the expectation that the community understands that this is a game in active development. That means that some features may be present in non-optimized forms in order to unblock other features or areas of gameplay that we want people to be able to experience today. Over the course of Early Access, you will see many features make their way from step 1 through step 4.
Here's what our engineers are working on right now to improve performance during Early Access:
Terrain optimization. The current terrain implementation meets our main goal of displaying multiple octaves of detail at all altitudes, and across multiple biome types. We are now hard at work on a deep overhaul of this system that will not only further improve terrain fidelity and variety, but that will do so more efficiently.
Fuel flow/Resource system optimization. Some of you may have noticed that adding a high number of engines noticeably impacts framerate. This has to do with CPU-intensive fuel flow and Delta-V update calculations that are exacerbated when multiple engines are pulling from a common fuel source. The current system is both working and stable, but there is clearly room for performance improvement. We are re-evaluating this system to improve its scalability.
As we move forward into Early Access, we expect to receive lots of feedback from our players, not only about the overall quality of their play experiences, but about whether their goals are being served by our game as it runs on their hardware. This input will give us a much better picture of how we’re tracking relative to the needs of our community.
With that, keep sending over the feedback, and thanks for helping us make this game as great as it can be!
First and foremost, we need to apologize for how the initial rollout of the hardware specs communication went. It was confusing and distressful for many of you, and we’re here to provide clarity.
TLDR:
The game is certainly playable on machines below our min spec, but because no two people play the game exactly the same way (and because a physics sandbox game of this kind creates literally limitless potential for players to build anything and go anywhere), it’s very challenging to predict the experience that any particular player will have on day 1. We’ve chosen to be conservative for the time being, in order to manage player expectations. We will update these spec recommendations as the game evolves.
Below is an updated graphic for recommended hardware specs:
I’d like to provide some details here about how we arrived at those specs and what we’re currently doing to improve them.
To address those who are worried that this spec will never change: KSP2’s performance is not set in stone. The game is undergoing continuous optimization, and performance will improve over the course of Early Access. We’ll do our best to communicate when future updates contain meaningful performance improvements, so watch this space.
Our determination of minimum and recommended specs for day 1 is based on our best understanding of what machinery will provide the best experience across the widest possible range of gameplay scenarios.
In general, every feature goes through the following steps:
Get it working
Get it stable
Get it performant
Get it moddable
As you may have already gathered, different features are living in different stages on this list right now. We’re confident that the game is now fun and full-featured enough to share with the public, but we are entering Early Access with the expectation that the community understands that this is a game in active development. That means that some features may be present in non-optimized forms in order to unblock other features or areas of gameplay that we want people to be able to experience today. Over the course of Early Access, you will see many features make their way from step 1 through step 4.
Here's what our engineers are working on right now to improve performance during Early Access:
Terrain optimization. The current terrain implementation meets our main goal of displaying multiple octaves of detail at all altitudes, and across multiple biome types. We are now hard at work on a deep overhaul of this system that will not only further improve terrain fidelity and variety, but that will do so more efficiently.
Fuel flow/Resource system optimization. Some of you may have noticed that adding a high number of engines noticeably impacts framerate. This has to do with CPU-intensive fuel flow and Delta-V update calculations that are exacerbated when multiple engines are pulling from a common fuel source. The current system is both working and stable, but there is clearly room for performance improvement. We are re-evaluating this system to improve its scalability.
As we move forward into Early Access, we expect to receive lots of feedback from our players, not only about the overall quality of their play experiences, but about whether their goals are being served by our game as it runs on their hardware. This input will give us a much better picture of how we’re tracking relative to the needs of our community.
With that, keep sending over the feedback, and thanks for helping us make this game as great as it can be!