May 26, 2023

Kerbal Space Program 2 - mikey

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)

While there are bugs that live outside these four categories (and some end up getting sorted out during normal feature development), the four categories are the biggest fun-killers.

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)

Here's a new engine in action. The Tuba has individually-swiveling mini-nozzles that might be one of part designer Chris Adderley's coolest ideas yet (parts built by Alexander Martin):

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!

May 4, 2023

Developer Insights #19 - Try, Fail, Try Again...and Again

Kerbal Space Program 2 - mikey

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:

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.

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

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.

May 2, 2023

Ask Me Anything with Shana Markham

Kerbal Space Program 2 - mikey

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)

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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

Apr 12, 2023

v0.1.2.0 Patch Notes

Kerbal Space Program 2 - mb_pd

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

🚀 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

Mar 31, 2023

Ask Me A Few More Things

Kerbal Space Program 2 - mb_pd

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.

From Moons, on the forums: Adjustable UI/UX, legacy UI, scaling, modularity.

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.

From walkingwiki666, on Steam: Will the game's price increase as new features are added?

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.

From MARL_MK1, on the forums: It is cool that we can press 'F2' and take HUD-less screenshots, but given that it's the most basic way of taking screenshots, and that many of us players enjoy taking the best pictures possible of our crafts: Does KSP2 plan to implement a fully fleshed C?

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 /

From alphaprior, on the forums: Will it be possible to alter the surface on the planets? Like dig a pit or flatten an area for a colony?

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.

Thanks for your questions!

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
Facebook
Twitter
Instagram
Intercept Games Discord
KSP YouTube