Kerbal Space Program 2 News

[h3]Who Are You?[/h3]
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!).

[h3]Bugs and Stuff[/h3]
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)

We will obviously do as much as we can about option B, but there is literally nothing we can do about option A. You bought the game so you are VERY entitled to go full rage-mode when you run into an issue. But, at the same time: we don't have to read it. So, if you are over the top and just trolling...we probably aren't reading that. But, if you are giving harsh but fair critiques, we take that to heart and bring that voice back to the greater team and do everything we can to ensure it gets taken care of.

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.
  

Screenshots are good, videos are good, save files, etc. HOW you were making something is very important here. Giving us a fully built rocket for us to load and try might not have the same results as giving us the steps of how you built that rocket. How you created it and the order you made it in is often far more important than the end result.

[h3]Helping Us Test[/h3]
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.

[h3]Why Did You Fix Bug A and Not Bug B?[/h3]
"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.

[h3]How Long Does Fixing a Bug Take?[/h3]
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.

[h3]How Do You Test a Game as Complex as KSP2?[/h3]
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).
  

Keep in mind, this is not counting variations using...

• 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)
  

This isn't to say we cannot infer certain configuration details. For example, it's likely after an engine that you probably aren't placing another engine, or even a fuel tank (usually it's a decoupler or separator). But what if, buried in your vessel somewhere, there were two engines stacked atop one another, and then that was vertically translated into a fuel tank and then hidden? A picture is worth a lot, but it wouldn't help reproduce your issue. A save would also not immediately make clear how this was built.

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.

[h3]How Big Is the QA Team?[/h3]
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.

[h3]What Are You Currently Working On?[/h3]
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.


[h3]Min/Recommended Hardware Questions[/h3]
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.

[h3]The Best Way to Get Your Specs Info:[/h3]
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.



[h3]We're Here For You[/h3]
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!

[h2]All About Shana![/h2]
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.
  

What has been your favorite thing to work on so far? (Epic, Discord)

• 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.
  

What planet are you most proud of that we have not seen yet? (ThatOneGuy, Discord)

• Glumo!
  

What is your favorite celestial body in the Kerbolar system? (Little908, KSP Forums)

• Easy - Eve. It's beautiful and haunting. Also once you're there, you're never going back.
  

[h2]Gameplay and Game Design[/h2]
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.
  

How do you and the team learn about and imitate real world rocket and spacecraft systems, to ensure the realism of the game? (LeroyJenkins, KSP Forums)

• 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.
  

What was the most difficult decision thus far with designing the game? Alternatively, what was the easiest? (bradtaniguichi, Discord)

• 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.
  

How long does it take to design a real-world technology for Kerbal technology and still be realistic? (the_tunnel, KSP Forums)

• 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.
  

Do new planets scale more scientifically accurate or have you kept the 1/6th size for gameplay reasons? (Spicat, Discord)

• 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.
  

At the moment in KSP2 (and KSP1), activating time warp halts all craft rotations. Was there any consideration given to making rotations persist through time warp? Is this something we'll see in a future update? (Colm, Discord)

• 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.
  

What new fuel types will be available throughout Early Access; and will different biomes on planets yield different fuel types? (PleySU, Discord)

• 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.
  

[h2]Accessibility and Tutorials[/h2]
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.
  

Most players don't know how reentry works and how to land precisely. How will you teach players to land precisely near colonies to deliver resources there, or will we get instruments to predict landing site for delivery paths? (Vortygont, Discord)

• 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.
  

Will there be slightly more advanced tutorials, like going to other planets? Because I'm pretty new, and so far, the tutorials for KSP2 are the easiest to understand. (NoKerbalSky08, KSP Forums)

• 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.
  

[h2]Resources[/h2]
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.
  

With resource management, are the resources we gather raw materials that we need to convert into useable resources? Will we need to build a refinery system? (CVUSMO, Discord)

• 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.
  

When it comes to resource systems, how many resources did you eventually decide to settle on (or are still working on settling on)? Should we expect something like one unique resource per celestial body? (Tyco, Discord)

• 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.
  

[h2]Parts[/h2]
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.
  

Are variants of engines and tanks like in KSP1 planned? (Spicat, Discord)

• 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.
  

Will we get part size categories larger than the 5M parts, like 7.5M? And will the 1.875M parts from the Making History DLC make a return? (Combatpigeon96, Reddit)

• 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!
  

Will there be scaling, like the wings now, for other parts? (o0King_Martin0o, Discord)

• 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.
  

Alternate atmospheric engines. Referring back to Eve, will we have engines that can run on other atmospheric gasses without a need for oxygen? Will we be able to collect gasses from an atmosphere as part of the resource harvesting system? (jclovis3, Discord)

• 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.
  

Is there a possibility we will see the PAW (part action windows) returning? (CheetahGamer587, Discord)

• 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.
  

Will there be dedicated parts for building boats and submarines? Underwater bases? (KCreate, Discord)

• 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...
  

[h2]Science Mode[/h2]
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".
  

Will there be an equivalent to the Mobile Processing Unit in Science Mode? (Master_of_Rodentia, Reddit)

• No, we want to focus on the core experience of Science before considering adding parts that break game flow.
  

[h2]Colonies[/h2]
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.
  

Will adding to orbital colonies be similar to how we already make space stations, etc., or how will that work differently? (SamBretro, Discord)

• Orbital colonies would follow a similar flow to terrestrial colonies and have the same toolset.
  

[h2]Interstellar[/h2] 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!

[hr][/hr]Keep up with all things Kerbal Space Program 🚀 KSP Forums KSP Website Facebook Twitter Instagram 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!

[h3]🚀 [/h3]

[h2]Bug Fixes[/h2]

[h3]Flight & Map[/h3]

• 🚀 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
  

[h3]Optimizations[/h3]

• 🚀 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
  

[h3]Saving & Loading[/h3]

• 🚀 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
  

[h3]Parts & Stock Vessels[/h3]

• 🚀 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)
  

[h3]UI / UX[/h3]

• 🚀 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
  

[h3]Construction[/h3]

• 🚀 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
  

[h3]Environments[/h3]

• 🚀 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
  

[h3]FX & Audio[/h3]

• 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
  

[h3]Tutorials[/h3]

• 🚀 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
  

[h3]Localization[/h3]

• 🚀 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
  

[h2]Submitting Bug Reports and Feedback[/h2]
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