In aerospace, a recurring joke is that every discipline considers their part of the project the most critical to mission success. Propulsion – obviously without engines you’re getting nowhere! Mission analysis? Where will you go without an actual mission? How are you steering your rocket without guidance, navigation, and control? Electrical and life support – obviously key. Pulling off a successful space mission is really a massively interdisciplinary undertaking.

It's that way with KSP2 as well. Different community members have varied perspectives on what features we should add or improve next. As KSP1’s modding community proves, there are thousands of possible features, and dozens of possible approaches to each feature. That’s a lot to take in. One gameplay system that we have heard a lot of enthusiasm for is thermodynamics, and thermodynamics is very dear to my heart.

In this dev blog I’m going to go into the design of the thermal systems in KSP2. It is rather long, but it is a complex topic worthy of discussion, and the community deserves a good analysis of what we’re doing, where the core challenges are, and where we are making specific design choices for interesting gameplay.

In Kerbal Space Program 2, we try to introduce prospective rocketeers to the edges of various space disciplines. A lot of this skews towards mission planning and vehicle design but making sure we touch on many of the core spaceflight challenges is important. Heat management is one of the more underrepresented challenges in spaceflight, which is too bad, because it’s pretty…COOL.

We're aiming to have a much larger scope of thermal gameplay elements when compared KSP1 – we need to be able to surface new and exciting challenges that range from the mundane (don’t dunk a Kerbal in an active volcano) to the exotic (fitting a few thousand square meters of radiator to your interstellar vessel) to the really hardcore (building a functional mining colony in the shade of a mountain on a tidally locked planet really close to a star!). This all comes from the vastly increased set of environments we have under construction, parts you’ll use, and missions we want you to fly.

What this fundamentally means is that for KSP2, we have had to redesign the entire thermal system from scratch. This system needs to do a few things right that we felt couldn’t be accomplished by the KSP1 thermal model:

1. It must feel authentic and model the core challenges of heat for spaceflight, atmospheric flight and colony building.
   
2. At the same time, it should have an appropriate level of abstraction so that it is teachable in the same way that other KSP systems are, such as fuel and power flow.
   
3. It must be predictable, plannable, and stable enough so that players can feel confident planning missions and building vehicles or colonies in contexts that involve heat.
   
4. It needs to work at different scales – we need to handle a single heat producing part at 1x time warp, and we need to handle 50 heat producing parts at 10,000,000x time warp.

These are big challenges – and they don’t even include the technical challenges of making the system stable and performant throughout the whole game.

In designing a system for KSP2, we often want to get a sense of the physics and reality that relate to a system. These can inform the user stories we want players to grapple with when playing the game. There are three core areas of heat management we want to deal with:

• Generation and removal of heat using parts on a vessel or colony
  
• Reentry and atmospheric heating on planets with atmospheres
  
• Environmental heat sources and sinks (oceans, etc.) that can affect vessels and colonies

I'll start out by examining some of the physics and reality behind these three stories.

[h5]Avoiding Meltdowns[/h5]
In everyday life, almost every useful process generates some level of waste heat. Your computer generates waste heat when it plays KSP2, a nuclear reactor making electricity generates waste heat, and even your body generates excess heat. A good rule of thumb is that the more exciting the piece of tech you’re running is, the larger the waste heat generated, and there are some really cool pieces of technology we’re looking at for use in KSP2.

When things heat up, we need to get rid of the excess energy somehow. Not getting rid of it results in consequences, like nuclear meltdowns.

The three common processes that move heat around.

There are three processes that can do this: convection, conduction and radiation. Convection is a very effective way of dispersing heat, using atmospheric or fluid currents to move heat away from a heat object. Conduction is also efficient and relies on two objects touching – heat will flow from the hot to cold object. Radiation is the least effective way of dispersing heat and relies on the tendency of hot objects to emit photons, which carry away heat energy.

Heat in space is a real problem. You might think that it is cold in space – after all, it is very high up, and dark, which we associate with cold. Seems reasonable. Trekkies among the audience may be familiar with a famous line from Star Trek II – “it is very cold in space”, which reveals that though Khan has a great flair for the dramatic, his grasp of thermodynamics might not be all that great. Specifically, without air or another medium, the only way we can get rid of heat is through radiation, using heat radiators.

An astronaut servicing a thermal control radiator on the International Space Station and a large KSP2 interstellar vessel with several radiators in its midsection. Credit: NASA

For KSP2, we want to pull several specific user stories out of this idea of heat transfer:

• Parts on a vessel or a colony should be able to generate heat. These could include engines, drills, factories, and power generators.
  
• Players should be able to make use of the three processes of heat transfer to cool vessels. That could be by using radiation with radiator parts in space, using the local atmosphere's convective abilities on a planet, or possibly using conduction to treat an asteroid as a heat sink.

These stories are not completely unfamiliar to veteran KSP1 players – drills and ISRU units generated heat that needed to be removed with radiators, and our three heat processes were simulated with great accuracy for focused vessels. However, we need to expand this to handle much higher fluxes, expand the range of parts that can generate heat, and most importantly, improve how all of this is communicated to the player.

[h5]Slightly Singed Landings[/h5]
When spacecraft reenter the atmosphere, they travel at such a high velocity that the compression of the air in front of the spacecraft creates extreme heating and is liable to damage or destroy the spacecraft. Special flight paths can be used to reduce the heating, and special materials are used to withstand extreme temperatures – often through ablation, where the material burns up slowly during reentry events, and in doing so carries away the heat.

The ESA spacecraft Jules Verne burning up in reentry. Credit: NASA

This is an integral and important part of spaceflight, so definitely something we want to represent in KSP2. We can collect a few more smaller user stories from this.

• Travelling in atmospheres at high velocities should cause vessels to heat up
  
• Players should be able to use occlusion to protect parts on vessels from reentry heating
  
• Players should have access to specific parts that are more effective at mitigating heating than others

Reentry stories: you should really add a heat shield.

Again – this is a similar set of things to KSP1, but we go up in scale again. With more exoplanets, higher velocities and more varied types of atmospheres, we increase the scale of the challenge we need to consider.

[h5]Exoplanets? More Like Exothermic Planets![/h5]
Aside from reentry, we also need to think about environments. Traveling through the KSP2 universe will expose your Kerbals to everything from somewhat pedestrian to exotic environments, with situations like:

• Close proximity to a star
  
• Infernal, glacial, or "just right" atmospheres
  
• Heated or molten ground
  
• Icy or frozen planets

These are all things that, when sending probes or Kerbals to another planet, we would like the player to consider. We want to build interesting puzzles that require clever use of parts, innovative use of the environment, and clever mission design to solve. This means that all that heat transfer stuff from earlier should be influenced by environments. A cold planet might give you a useful bonus to run your mining drills. A lava planet should give an extra interesting colonial challenge.

We can extract another set of user stories from these environmental considerations:

• Parts exposed to strong solar illumination should heat up
  
• Immersion in atmospheres and oceans should heat up or cool down parts
  
• Proximity or contact with surface features should heat up or cool down parts

Environmental stories. I'm a designer, not an artist!

These user stories are another core expansion of KSP1. In particular, the interaction between the part 'layer' and the environment 'layer' is going to have a much larger effect. More on this later.

[h5]Smaller, Simpler Problems[/h5]
But wait – there’s more!

• Parts should have a variety of thermal parameters to make them easier or harder to use in select thermal situations (heat up at varying rates, explode at different points)
  
• Parts exposed to engine exhaust jets should heat up

We can’t neglect the little stuff. When designing this system for interesting gameplay, we need to think about how we'll represent the range of thermal properties we want for parts. So parts should have some different heat tolerances, some different heat limits. Oh, and we want engine exhaust jets to generate heat. Can’t have you pointing a torch drive at a colony with no consequences!

[h5]Putting It Together[/h5]
Let's recap. From the above set of thermal user stories, we want to have a thermal system in KSP2 that will let us:

• Create parts that generate and remove vast quantities of heat, via the three physical heat removal methods
  
• Simulate atmospheric entry and mitigate it with heat shields
  
• Model a vast set of environments from cold to hot and have those directly feed into the two previous bullets
  
• Provide appropriate variation in thermal part behaviors

We can check these stories against the four design pillars of KSP2 to make sure they fit well. Our thermal stories are strongly focused towards Realistic space flight and Exploring new planets, but I have to give a shoutout to Building cool and unique rockets, because I can't resist a bad joke.


In addition, the thermal system needs to be predictable and plannable. More on that in a bit.

Something I touched on earlier is that the KSP2 thermal system needs an appropriate level of simulation and detail. The level of detail we build into any system depends on the user stories. If the system is too detailed, we may build something that is difficult for a player to understand or too difficult for us to tune, creating undesirable edge cases and making it impossible to fill those user stories. If it is too simple, we might compromise our realistic spaceflight pillar and make things too easy for the advanced player.

I like the metaphor of a spherical cow in a vacuum – if we needed to analyze a cow for some reason, we could assume the cow was a sphere and assume it was in a vacuum. This is a fairly simple situation to analyze physically. This may however lead to an oversimplification of the problem. I can describe our search for a good thermal system as a search for the right geometric approximation and environmental context for our cow. Should it be cylindrical? Composed of several boxes? It probably shouldn’t model all the contours of a real cow in a grassy field because that would be very complex.

This cow is exchanging energy with its local environment!

The right thermal model for KSP2 has a good blend of realism, hits all our user stories, and is simple enough for players to understand and engage with. The right level of simplicity also allows us to build good intuitive tools to help players understand, in a nutshell, when their vessel or colony may overheat and how to solve it.

[h5]Determinism vs Simulation[/h5]
A common trade in simulation type games is the level of determinism versus simulation. The more simulation in a game, the more the game relies on lower-level rules to drive gameplay. A good example of this in our thermal context is a heat radiator. Determining how a radiator performs could be approached in a very simulation-centric fashion:

• Define the usable area of the radiator
  
• Determine the temperature of the radiator in response to various factors (each of which might also need to be simulated)
  
• Use physical relationships such as the Stefan-Boltzmann law to model the amount of heat removed by the radiator

A radiator with a few of the parameters that might be needed to physically simulate it.

This simulation approach provides a high precision approximation of radiator heat rejection. However, it does require more design and computational work, as we need to figure out that temperature value, and we now create additional challenges of teaching the players about the radiator’s area, the radiator’s temperature, and how the two combined feed into the physical relationship. The latter is harder if the relationship is complex (here it is somewhat complex – heat radiation is proportional to temperature raised to the power of 4). In addition, we may create simulation-level inconsistencies – is this too detailed compared to other things that are simulated in the game? That’s a lot to unpack.

Alternatively, a simpler deterministic method could be used. We might just define the amount of heat removed by the radiator:

A radiator with a single deterministic flux value, informed by physical relationships.

This is evidently a lot less complex for a designer to manage and a player to understand. Often, we can mix the two approaches – in this example we could use physical relationships to guide what value we set. For example, we make the values for heat removal chosen related to the surface area of the part and derive them from ‘typical’ temperature relationships but never directly show this to the player. This has some advantages – for example decoupling gameplay from visuals, so we have more flexibility to work on these separately.

KSP1 erred on the side of the simulation in this trade. In the KSP1 thermal model, all vessel parts calculated their own energy exchanges (via convection, conduction, and radiation) with the environment as well as other parts, calculated internal sources of heat, tracked up to three different temperatures, and required considerable frowning at KSPedia to start to understand in a way that you could engage with the system.

The KSP1 simulation-focused thermal model, as shown by the in-game KSPedia.

For KSP2, we’ve made the decision to rely on what I’ll call a 'reality-informed deterministic model' with fewer moving parts. This model is still complex enough to hit all the user stories I’ve defined earlier so as not to compromise our commitment to reality, but will use a reduction in complexity to achieve much better player comprehension.

[h5]What's Changed[/h5]
Given the above, where are we modifying the simulations?

• Simplifying temperature values: We want to avoid having a player interact with three different part temperatures when planning missions and playing the game. One is ideal.
  
• Part high resolution thermodynamics: We don't have a lot of user stories that benefit from simulating conduction between parts or intrinsic simulated thermal emission. A lot of the time this reduces to equilibrium in KSP1, particularly at high time warp factors. In addition, if we want this simulation to apply to vessels in the background, we need to simplify things. It’s hard enough computing thermodynamics for 500 parts on a vessel – imagine if we wanted to crunch fancy thermodynamics on 50,000 parts on 100 vessels! This has to scale effectively and be performant.
  
• Simplifying environmental interactions: Similar to the previous bullet, the level of interaction between the environment and a given part can be simplified. The ex-thermal physicist in me is pretty sad that we won’t be modeling the differences between longwave and shortwave radiative transfer in low Kerbin orbit - but I’ll get over it.

Given all the above, we have designed a rad system. More puns, yeah.

KSP2’s thermal system will use a model based around managing heat fluxes – the amount of energy applied to something over some amount of time. Every process we want to model boils down to applying a heat flux to a part. This flux can be positive, causing a part to increase in temperature, or it can be negative, causing a decrease. Here is a sampling of fluxes we care about from our user stories:

• Positive flux from things going on in a part, such as drilling, resource production, and powerful engine reactions
  
• Negative flux from things going on in a part, like heat radiators and other heat sinks
  
• Positive flux form stellar sources in sunlight
  
• Positive or negative fluxes from warm or cold atmospheres, fluid bodies, or surfaces
  
• Positive fluxes from high velocities in atmospheres (reentry)

Using this model, we can sum up all the fluxes affecting a part and communicate a single value to the player. If the sum of all fluxes is positive, the part heats up. If it is negative, the part cools down. In the absence of any fluxes, a part is stable. If the part’s temperature increases above its maximum, well, you get an explosion. I’ll illustrate with a few cases!

Thermal system in a reentry context.

Let’s look at a reentry case – a capsule with a heatshield travelling quickly into the atmosphere. Here, we have the presence of a Convection flux on both parts, as we have an atmosphere, and a Reentry flux, as we’re moving fast. The capsule is being occluded by the heatshield, and the heatshield is getting a positive flux. It is heating up and the capsule is not.

Thermal system in an orbital context, with a part.

Let’s look at another case of a 3-part spacecraft in orbit around Kerbin. In the first image, we have a idle spacecraft doing nothing. No fluxes. Nothing changes. In the second image, the engine is firing and generating a positive flux, so it is heating up. There are otherwise no fluxes. In the absence of anything else happening, the engine part will eventually explode.

A more complex ship makes for a more complex example.

Now, let’s add radiators to the mix. Here I haven’t labelled all the parts, but we have an ion drive spaceship with a nuclear reactor. In the first image, the radiators are not working and the reactor is on. The reactor part is heating up as it outputs 200 kW of heat flux and will eventually fail. In the second part, we’ve thankfully extended the radiators, and they’re each pulling 100 kW of heat flux from the reactor. Everything is balanced and nothing will explode.

A zoomed out example, with a colony!

As a last example, let’s make it complicated (I’ve simplified the doodle though). Here’s a colony in an atmosphere. The cooling tower is using 2 MW of heat flux, the reactor is making 2 MW, the factory is making 1 MW, and we’re using the water as a heat sink to dump 2 MW of flux. We have a nice little negative flux and our colony is happy because the engineers considered the environment. It’s a great story because it starts to show you where you might end up with advantages and disadvantages in terms of colony placement. If that water was lava, this would not be a good thermal situation 😉.

We can see how this system is plannable too. Although there are a lot of details, a player technically only needs to know what the net heat flux is on their whole vessel. No matter how many different parts are making heat, and no matter how the environment is configured, each part just contributes a single number to the situation. Add them all up – if it is positive, you have a problem. If it is zero or negative, you don’t.

The second part of this is how we define relevant fluxes. Instead of having a very complex environmental model where we specify every possible flux and simulate them for every possible source, KSP2 assumes that every part has some level of ability to self-regulate in an average thermal environment. Kerbals build tough!

Positive fluxes will only start to appear in well defined abnormal situations that correspond to our user stories and the puzzles we want players to solve – the user stories from before:

• As your vessel approaches a star.
  
• When your vessel reenters the atmosphere at high speeds in a fiery plume.
  
• When a part is doing something that creates a large excess of heat. We're not considering small heat sources like cryocoolers and capsule life support systems.
  
• When you point your fusion drive at your orbital colony.

We’ll apply negative fluxes at times where you might expect useful temperature drops in response to intuitive situations:

• When your vessel is floating on an icy ocean or flying in a frigid atmosphere.
  
• When a part is doing something that removes heat, like running a heat radiator.

Using these two concepts, we can work through all the user stories we defined in the previous sections and reduce the things we need to communicate to a player to effectively two values: the net heat flux on a part and the temperature of a part. The former is something you want to make as close to zero as possible, and the latter is something that tells you how close you are to critical failure.

A word on temperatures and maximums – there is a relationship between the temperature of the environment and the temperature of a part. Typically, you simply can’t bring a part into an environment it hasn’t been designed for – if you try to take a part with a low heat tolerance (let’s say it breaks at 500 K) into a 600 K atmosphere, you’re going to be in trouble regardless of the local heat fluxes. In this case, you’ll need to use creative solutions, like cargo bays.

[h5]Timewarp and Loading[/h5]
A core requirement we have on this system is for it to work well in timewarp and provide consistent behavior at high and low timewarp levels. Similarly, we have to consider how the system behaves on vessels that are unloaded. This work supports colonies and interstellar vessels.

For interstellar vessels, or anything else on a long burn, we expect players to want to timewarp at very high levels during long burns using engines that generate a lot of waste heat. In short, we need to make sure that when you do this, there is consistent, stable performance from our thermal system. If your vessel can take the heat at 1x, it should take it at 10,000,000x – this may seem obvious but leverages very specific requirements on the technical solution.

For colonies, we also need to handle these timewarp levels but also bring a focus to things working in the background. In KSP1, a number of systems only worked on vessels you had loaded – things didn’t always calculate in the background (especially thermal), because there wasn’t a lot of need for them. To fit our user stories we need to have a strong picture of the concepts we want to present to players. Again, consistency is a requirement. If I want to produce resources at a colony, or run delivery routes, I want this to be seamless regardless of whether I am actively observing the colony or not. Resources should be produced while I’m doing other things. This again leverages requirements on thermal mechanics: since most complex colony functions like resource processing are going to produce heat, we need to account for that heat in production calculations and be able to do the math when we’re not observing the colony.

Our flux-based system fits these requirements very well. In the absence of any additional flux, temperatures don’t change, so we can simplify a lot of these calculations or ignore them completely. When flux is involved, we’ve specifically designed a mathematically simple system. I like to think of this in terms of timewarp. If your vessel’s giant interstellar engine produces 100 MW of heat, and you have 1000 MW of radiators, we can make some solid assumptions:

• As long as your radiators are running, your engine will never explode.
  
• If your radiators are not running, your engine will more or less instantly explode at any medium-to-high timewarp level.

Even so, making sure things are stable and comprehensible is a large technical challenge. Comprehensible means we also need player tools to enable system interaction though, so let's talk a bit about planning.

[h5]Planning for Success[/h5]
I mentioned before that a key improvement we absolutely need for KSP2’s thermal mechanics is plannability. The system that I’ve outlined here gives us an appropriate level of detail to do that. Just like you can check your vessel’s thrust-to-weight ratio and delta-V, you will want to check your vessel or colony’s thermal performance.

We have a number of tools and concepts that we’re investigating as part of this effort, from UI tools to part-based approaches. We’re excited to iteratively work through the final solution through Early Access and consider the best of the community’s feedback to make flying vessels into Kerbol as exciting and predictably awful for your Kerbals as possible.

Because we're in early access with a specific roadmap, it doesn’t make sense for us to try to cram a system of this complexity into a single update, particularly with the huge rash of user stories we want to cater to. We’re going to deliver functionality iteratively where it is most appropriate in the roadmap. Here’s how things are looking right now, though we will refine this roadmap dynamically so heat problems appear at the right times.

By the time we get to our first roadmap update, for example, the user stories around reentry heating become very relevant, because the puzzle of returning science experiments to Kerbin is much more interesting if they can burn up when returning. That means that reentry heating takes the first priority of all of our user stories, and you can expect that to arrive before or with this update.

Similarly, dealing with radiators and parts that generate heat isn’t something that becomes exciting until we introduce actual heat generating parts, likely as we move towards the second roadmap update. These start to show up when we introduce more advanced propulsion systems and power sources like nuclear reactors. There’s a nuclear reactor in the game right now, but you’ll notice it has integrated radiators – a nice sidestep to the problem. Larger reactors will be separate and need their own radiators! This is where we’ll also need to bring in a first cut at some planning tools.

By the time we introduce some of our exoplanets and Kerbals go Interstellar, we want those environmental heat user stories to be fully fleshed out. That’s when we can expect to deliver advanced environment heat and even more planning tools to help your build cooler colonies and vessels. Overall – if we have a lava planet, that lava planet should be a thermally bad place to be.


I hope you’ve found this writeup to be informative and indicative of the direction and challenges KSP2 needs to deal with when implementing thermodynamics – I’ve enjoyed writing it.

🚀 <-- This rocket denotes an issue or change that community members directly helped by sharing or suggesting it to our dev team. Thanks to all of you who send in bug reports and suggestions!

• 🚀 Fixed: Trajectory position changes when vehicle transitions between spheres of influence (SOI) [Original Bug Report]

• 🚀 Fixed: Navball markings are blurry [Original Bug Report]

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 (for game-breaking bugs)
Dedicated Bug Reports on the KSP Subforum

Good afternoon, intrepid Kerbonauts!

Lots of stuff to talk about today! As many of you know, a couple of new bugs were introduced with last week’s v0.1.3.0 patch. The most significant of these bugs relates to a loss of atmospheric drag (and physics in general) when capsules are decoupled. For the first time ever, we issued a hotfix to correct that issue yesterday morning.

Yesterday's v0.1.3.1 hotfix also contained a fix for a VAB bug in which fairing editor UI elements were drawing on top of one another.

We discovered after yesterday’s hotfix that people were unable to launch the game outside of the Private Division launcher. This was not intentional, and has been fixed — due to a configuration error on our end, we accidentally included Steam’s built-in DRM. KSP2 is DRM-free, just like KSP1. The fixed update was pushed to Steam this morning. Sorry for the headache!

We’re testing a second hotfix (timing TBD) that corrects the blurry navball issue. And because we’re sneaky little devils, we’re also doing some testing around a fix for the SOI transition trajectory bug. If these fixes prove stable and low-risk, we’ll release a second hotfix. Fingers crossed! The work that’s gone into the SOI transition issue — number 2 on our top-ten most wanted bugs list — deserves a special mention. Engineers David Tregoning, Mark Jones, and Shalma Wegsman put in colossal efforts to both track down the cause of the issue and to craft a solution. This one has been a long time coming, and it’s great to be able to knock such a big item off the list.

The credit for the fast turnaround on all the latest fixes goes to a well-coordinated joint effort between engineers, production, and QA. We’re still learning as we go, but things are feeling good.

Based on the Bug Reports subforum, these are the community's 10 most-upvoted bugs:

1. Orbital Decay [25 votes]
   
2. Incorrect Maneuver on Inclination Change [10 votes]
   
3. Cannot Change Craft/Vessel Name in Tracking Station [9 votes]
   
4. AIRBRAKES Deploying on Roll [9 votes]
   
5. Camera Resets Position Map View [8 votes]
   
6. Graphic Glitches on AMD [8 votes]
   
7. Engine Sound Effects Not Playing [7 votes]
   
8. Cannot Change Symmetry While Holding Strut [7 votes]
   
9. Center of Mass/Thrust/Pressure Vectors Sitting on VAB Floor [6 votes]
   
10. UI Artifacting [6 votes]

Note: Navball Blurry [18 votes] and SOI Trajectory Line Issues [18 votes] have been left out of the above list since we're considering them for the second hotfix.

Thank you to everyone who took the time to submit bugs in the subforum. Even if you don’t have a new issue to report, your upvotes help us determine the relative priority of the bugs that have already been posted. While we investigate the bugs above, two other non-feature items also feature in our top ten:

• Rockets are still too wobbly
  
• SAS causes runaway pitch oscillation for aircraft in flight

Lots to do! Thanks again for submitting such detailed and well-documented bug reports. It's going to be a busy month!

Did you catch our AMA with our Art Director yesterday? Kristina was asked a lot of interesting questions, many of which ranged well beyond the art domain. She gave fantastic and detailed answers! If you missed the stream, it's definitely worth watching on YouTube! With the help of streaming wizard Dakota, she even got to show off some visuals as well! You can find a transcript of the AMA here as well. Thanks, Ness!
https://www.youtube.com/watch?v=GTFcLtqtdfI

This is the second week that KSP2 is on sale for 20% off, which ends on July 13th at 1pm ET. If you've got any friends who you think might enjoy the last bit of heat-free reentry during Early Access, now's a great time to tell them about the sale!

Last week’s Jool 5 challenge produced some of the coolest, most ambitious craft designs we’ve seen in KSP2. Check out this absolute unit from DarlesChickens:


Or this beauty from Razorback:


And here’s a unique one from Tr1gonometry:


We know that in the Wobbly Rocket Era, missions of this kind can be extra challenging. Kudos to everybody who braved the bugs and slipped the surly bonds of Kerbin regardless!

This week’s challenge? You’re putting on an air show! Build a maneuverable stunt plane and show off your fancy flying skills. Buzz the tower! Under the bridge! Do some barrel rolls! To get specific:

• 🏆 Primary Goal: Fly an inside loop, an Immelmann turn, and a split-s turn.
  
• 🏆 Secondary Goal: Fly an outside loop, a barrel roll, and a hammerhead stall turn.
  
• 🏆 Jeb Level Goal: : Fly under the R&D bridge as fast as you can.
  
• 🏆 Val Level Goal: Fly through the parking garage bridges (from the water), under the R&D bridge, then back through the parking bridges as fast as you can.
  
• 🏆 Tim C Level Goal: Fly a loop around the R&D bridge so that you pass under it twice in one maneuver.

Don’t forget to wear your G-suit — you’re about generate some wing loads that’ll make your crew chief very grumpy! While your screenshots are always welcome, video capture will be the best way to show off your maneuvering prowess. Good luck!

Now that Summer's here, with all its vacation-related comings and goings, I'll be letting other parts of our team takeover these posts. In the coming month, you'll still see the following here:

• Bug report updates
  
• More AMAs
  
• Challenges

In addition, we'll be uploading more gameplay clips to our social channels.

We've got a lot of good momentum coming off the last update and we're already making great headway on the next one. Looking forward to sharing our progress with you soon!

---

Keep up with all things Kerbal Space Program 🚀
KSP Forums
KSP Website
Facebook
Twitter
Instagram
Intercept Games Discord
KSP YouTube

Hi Kerbonauts!

We sat down with Art Director Kristina Ness for another Ask Me Anything, this time live on Twitch! Thank you to everyone who submitted questions and tuned into the AMA. As a reminder, we're in Early Access! Plans can change.

For those who couldn't catch the stream, a YouTube version is now available. Check it out as Kristina talks about KSP2's art style, art processes, and more!

She may or may not have showed off some never-before-seen art...a peek may or may not be below...

Concept art of the new Kerbal suits.

Early idea sketches of the Early Access key art.

The sketch that would become the Early Access key art.

---

Keep up with all things Kerbal Space Program 🚀
KSP Forums
KSP Website
Facebook
Twitter
Instagram
Intercept Games Discord
KSP YouTube

🚀 <-- This rocket denotes an issue or change that community members directly helped by sharing or suggesting it to our dev team. Thanks to all of you who send in bug reports and suggestions!

• 🚀 Atmospheric drag not correctly applied to capsule after decoupling [Original Bug Report]

• 🚀 Procedural fairing editor buttons overlap one another in VAB [Original Bug Report]

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 (for game-breaking bugs)
Dedicated Bug Reports on the KSP Subforum

Thanks to Community Member Kavaeric for making the image!

Happy day-after-update, fellow Kerbonauts!

Many of you have had a few hours to experience the v0.1.3.0 update, and hopefully you have found the gameplay experience improved! Many players are reporting significantly better framerates, but there are more than just performance gains on the menu. Among the new fixes and features we’re most excited about for this update:

• New parts, including three new engines, new docking ports, and the A.I.R.B.R.A.K.E.
  
• The Flight HUD UI is now re-scalable via player settings
  
• Several decoupling-related flight bugs have been resolved
  
• We knocked out several of the vehicle-falls-through-terrain bugs
  
• We nailed that really annoying VAB bug that kept you from putting down procedural parts after picking them up
  
• We strengthened wing attachments with a new automatic multi-joint system
  
• We fixed the asymmetrical separation forces on radial decouplers, restoring the beauty of booster separations

There are many other fixes, big and small. Take a look at our patch notes to get the full rundown.

This update represents an incremental step in the ongoing Early Access process of addressing game-breaking bugs while moving toward our first Roadmap update, which will add Science collection, a new Mission system, and parts progression to the game. We still have quite a few game-breaking bugs at the moment, as well as aspects of gameplay that still need refinement (wobbly rockets, overactive control surfaces, strange SAS behavior). We will be posting our new top-ten most wanted bugs next week (three of which will be carrying over from our previous top-ten list). If you’re playing the latest update and you come across a bug that you’d like to report, please do so via the Bug Reports subforum on the KSP Forums; you can upvote existing reports, or if your issue isn't listed, you can submit a new report through the form. We will be following those threads very closely to track which issues are most important to the community as a whole.

We are aware that one of the decoupling fixes in this update has introduced a new issue that breaks aerodynamic drag after a decoupling action. Thanks to early reports from the community, we have been able to reproduce the bug and are working on a fix. If the fix proves stable and low risk, we will consider releasing a hot fix in a few days.

Some players have also correctly noted that the orbital decay and SOI transit trajectory bugs are still present in v0.1.3.0 - while we had high hopes for an eleventh-hour breakthrough, neither fix made it across the finish line in time. In the days after code lock, a new fix for the SOI transit issue was submitted and is being tested. Our engineers have also isolated the orbit decay issue and believe they have a good remedy on deck. With updates, there’s always the temptation to hold the build just a couple more days to sneak in additional fixes (which we actually did this week). Alas, at some point the train has to leave the station, but it’s at least comforting to know that these issues will be addressed in an upcoming update. We appreciate your patience, and we hope that the changes that did make it into this week’s update have improved the game for you.

Other questions that we've been asked:

Where's reentry and heating?
We are working hard on both. We expect reentry VFX to arrive earlier than thermal systems and heat-related part destruction, so there may be a short phase during which reentering vehicles look like they’re being heated, but really aren’t. We don’t want to reverse any of our recent framerate gains, so we’re taking the time needed to make sure reentry is both awesome-looking and performant. To give you better visibility into the work taking place in this area, we will be posting a new dev blog about the heat system soon!

What's going to be in v0.1.4.0?
As we continue to work through our critical bugs list, those that are fixed by the next update will be included. We are still targeting foundational bugs and playability issues. As we work down through the list, we’ll report on our progress.

When is the Science Update?
The first of the headline Roadmap updates - which will add Science, Missions, and an R+D Center, is still several months away. A lot of work is going into the "Dot Two" update — deep architecture work, bug fixing, new systems, and a lot of new content. We will continue to release incremental updates until that time, with the goal of eliminating the major game-breaking bugs prior to v0.2.0.0. We’ll provide a release date for that version as soon as we can

With summer upon us, Private Division is holding a 20% off sale for KSP2. This sale ends on July 13th. If you’ve got a friend who has an interest in participating in Early Access, now is a great time to hop on board!

On Thursday, June 29 at 10am PT, our Art Director Kristina Ness will be fielding your questions about KSP2, and this is a rare opportunity to get detailed answers about the game's art! You can submit questions for here on this post!

Last week's "Score a Goal" challenge was extra challenging, but those who conquered it created some very original vehicles!

First, there's this submission from Miss, which deserves special mention as it’s the only attempt that involves not only a ball, but a rocket-powered foot!


Squidplaz did some reaction wheel magic to get a ball under the R+D Center bridge:


User pyasupro posted this beauty on Twitter, and made goals on both the Mun and Moho:


This week's challenge: we're going to Jool! Here are the deets:

• 🏆 Primary Goal: Launch a single-Kerbaled mission (only 1 spacecraft may depart Kerbin's SOI, but it can be built in Kerbin orbit) that passes through the SOI of all 5 of Jool's moons at least once before returning to Kerbin.
  
• 🏆 Secondary Goal: Same as primary, but land a probe on each of Jool's moons (the probes don't have to return).
  
• 🏆 Jeb Level Goal: Same as secondary, but plant flags on Bop and Pol.
  
• 🏆 Val Level Goal: Plant flags on all 5 moons of Jool in one mission before returning safely to Kerbin.

Have a great weekend, everybody!

Happy Summer, Kerbonauts! 🔆

Kerbal Space Program 2 is at a discounted price of 20% off until July 13th at 1PM ET. Join us in the Early Access journey into the stars and experience exciting new features as they first-hand as they come online.

We also just released our latest patch v0.1.3.0 (today, fresh out the oven). Highlights from this patch include:

• New parts (A.I.R.B.R.A.K.E.S, Clamp-O-Tron Inline Docking Port, S3-28800 Methalox Fuel Tank, and more!)
  
• Bug fixes (major Flight, UI / UX, Saving & Loading fixes)
  
• Performance optimizations

Check out the full patch notes here:
https://store.steampowered.com/news/app/954850/view/3677798233178553358

Have you ever wanted your own Jeb or Val? Or wanted to rep KSP in a fashionable manner? You're in luck - KSP merch is also on sale for 40% off until July 1st!*


*Discount based on Private Division’s SRP. KSP merch offer ends: July 1st, 2023 at 11:59AM ET. Available while stocks last. See store.privatedivision.com for pricing and terms.

https://store.steampowered.com/app/954850/Kerbal_Space_Program_2/

---

Keep up with all things Kerbal Space Program 🚀
KSP Forums
KSP Website
Facebook
Twitter
Instagram
Intercept Games Discord
KSP YouTube

• Added ability to toggle visibility of some 3D map elements
  
• Added multi-joint system for wings that places a scalable array of four joints along the length of the wing root
  
• Added new IVA Kerbal animation to show reaction to and recovery from non-catastrophic impact events
  
• Added player setting to allow toggling of Navball in Map view
  
• Added settings for toggling tooltips and for setting default throttle
  
• Fixed: Activating or staging an engine causes decouplers and fairing shrouds below that engine to stage
  
• Fixed: Brake activation applies to multiple vessels simultaneously after undocking
  
• Fixed: Camera drifts away from recently-decoupled vehicles
  
• Fixed: Changes made to landing gear friction level settings in the VAB do not propagate to flight
  
• Fixed: Countdown does not pause when time warp is paused
  
• Fixed: Gantry positioning code produces errant event registrations
  
• Fixed: Imprecise cloud shadow masking causes aura when shadow appears behind vehicle
  
• Fixed: In-cockpit Kerbals sometimes show T-pose due to corrupted fidget animations
  
• 🚀 Fixed: Inline drag calculations use incorrect facing directions when calculating cross sectional area https://forum.kerbalspaceprogram.com/topic/213954-massive-drag-bug-with-basically-every-inline-auxiliary-part-tests-results-and-pictures/
  
• Fixed: XM-G50 Radial Air Intake intake drag cube oriented incorrectly
  
• 🚀 Fixed: Instances of decoupled sections remain linked when decoupling a non-command root part that is separated from a command part by an engine mount https://forum.kerbalspaceprogram.com/topic/216916-root-part-below-an-engineplate-and-decoupler-causes-major-issues-for-a-craft/
  
• Fixed: Kerbal flag-planting and flag object animation de-synchronize when time-warp is used
  
• 🚀 Fixed: Landed EVA Kerbals disappear when a vehicle time warps into their physics range
  
• Fixed: Inactive crash course warning is fired when vehicle is placed on the launchpad or when player returns to KSC from flight
  
• Fixed: Inactive crash course warning occurs when a Kerbal performs EVA at the launchpad
  
• Fixed: Landed vehicles cause torrent of VesselLandedAtRest spam
  
• Fixed: Launch gantry does not adjust position to accommodate wide vehicles on launchpad
  
• 🚀 Fixed: Launching "Jumping Flea" vehicle causes null states https://forum.kerbalspaceprogram.com/topic/216998-stock-flea-launched-from-launchpad-1-unlaunchable-with-silent-flames-shooting-out-of-the-engine/
  
• Fixed: NaN displayed in the drag/lift ratio value
  
• Fixed: NRE errors occur when parts get destroyed
  
• Fixed: Out of Electricity message event fails to trigger when EC depleted
  
• Fixed: Some docking ports fail to release when undocking
  
• Fixed: Structural tubes don't occlude aerodynamic drag
  
• Fixed: Strut joint is misclassified as "lingering" and automatically destroyed when loaded to launchpad
  
• 🚀 Fixed: Symmetrically-attached radial decouplers eject with different forces https://forum.kerbalspaceprogram.com/topic/216760-decouplers-are-applying-force-in-the-wrong-directions-causing-ruds-and-jettison-issues/
  
• Fixed: Thermal indicator generates log spam
  
• Fixed: Undocking docking port destroys vehicle if it has wheels or wings attached to it
  
• 🚀 Fixed: Undocking vehicle sections that are connected with struts fails to detach struts https://forum.kerbalspaceprogram.com/topic/215561-undocking-doesn%E2%80%99t-disconnect-struts/
  
• Fixed: Ground parts remain attached to the main assembly when their parent part is destroyed
  
• Fixed: Vehicle falls through terrain when returning it to focus after launching another vehicle outside its physics range
  
• 🚀 Fixed: Vehicle teleports inside Kerbin when partial fuel depletion event triggers during time-warp https://forum.kerbalspaceprogram.com/topic/217165-in-the-center-of-kerbol/
  
• Fixed: When loading a second vehicle to launchpad after first vehicle has been destroyed, launch button shows "No Stages" and is not clickable
  
• Fixed: Wingtip vortices display incorrectly due to incorrect case handling for contextual events
  
• Planetshine adjusted to improve reflected lighting on vehicles above the Mun, Minmus, and Eeloo

• Adjusted over-reflectivity of Kerbal eye materials
  
• Fixed: "Bobus" ladder does not provide seamless transition to adjacent ladders
  
• Fixed: Bill's and Bob's eyes have incorrect symmetry and color settings https://forum.kerbalspaceprogram.com/topic/213215-jeb-bill-and-bob-too-what-is-wrong-with-their-eyes/
  
• Fixed: Placeholder notification text displayed when Kerbal performs an EVA
  
• 🚀 Fixed: Time warp keyboard shortcuts are still active when typing in details for planted flags https://forum.kerbalspaceprogram.com/topic/214995-punctuation-in-flag-description-passes-to-time-warp-controls/ https://forum.kerbalspaceprogram.com/topic/212894-regular-keybindings-not-disabled-when-entering-text-when-planting-flag/ https://forum.kerbalspaceprogram.com/topic/215071-typing-while-editing-the-content-of-the-planted-flag-doesnt-lock-other-controls-outside-of-the-textbox-and-numbers-cannot-be-inputted/ [4]

• Added new compute kernel to improve terrain performance by reducing rendering of non-visible detail
  
• Optimized cloud shader algorithm to improve GPU performance
  
• Implemented job system to handle per-part water detection (for 150 part vehicle, CPU time reduced from 10ms to 1.5ms)
  
• Optimized and improved quality of lens flares by using a commandbuffer
  
• Optimized cloud rendering when camera is below cloud layer
  
• Optimized GPU and memory usage for water rendering by using stencil buffers and new shaders
  
• Optimized KSC instancing to reduce draw calls
  
• Optimized Part Manager by removing several layout groups
  
• Optimized per-engine point lights by turning off shadows
  
• Optimized PQS terrain textures to reduce memory usage
  
• Optimized rendering of 3D UI elements in VAB and flight
  
• Optimized scatter object performance by using more compact scatter spawn buffers to reduce GPU memory usage
  
• Optimized tesselation factor for medium and low quality water to improve GPU performance
  
• Optimized water tesselation factor for water viewed from high altitude
  
• Optimized runtime CPU performance for water rendering by updating some properties less than once per frame
  
• Reduced GPU memory used by local space shader by 75%
  
• Reduced low and medium quality cloud texture sizes for Kerbin, Duna, Eve, and Laythe
  
• Removed unnecessary logging for time warp interpolation
  
• Updated Eve's shorelines to reduce visual blockiness and improve CPU and memory usage
  
• Fixed: Cloud shadows are broken on Eve
  
• Fixed: Clouds have dark edges
  
• Fixed: Memory leaks triggered by loading saved games, loading tutorials, and reverting to VAB
  
• Fixed: The game crashes when attempting to view the EULA and Privacy Policy in Russian https://forum.kerbalspaceprogram.com/topic/217638-the-game-freezes-at-the-stage-of-accepting-the-license-agreement
  
• Fixed: Trees vanish before they are completely off-screen
  
• Fixed: Scatter objects render at first level of detail at all distances

• 🚀 Fixed: TravelLog Manager causes runaway save file inflation https://forum.kerbalspaceprogram.com/topic/213186-save-files-becoming-extremely-huge/
  
• Fixed: Vehicle spawns beneath terrain when loading saved game with EVA Kerbal in focus
  
• Fixed: Interstage fairing size does not persist correctly when loading a workspace
  
• Fixed: After launching a vessel, loading into a different game save with a flight in progress, and then reverting to the VAB, an incorrect vehicle from another game save is loaded
  
• Fixed: Descriptions disappear when making new workspace save from a stock vehicle workspace
  
• Fixed: Log fills with autosave spam
  
• Fixed: Autosave cooldown timers don't trigger
  
• Fixed: Thumbnails for saved games sometimes incorrectly display transparency

• Added A.I.R.B.R.A.K.E.S part
  
• Added Clamp-O-Tron Inline Docking Port, Clamp-O-Tron Shielded Docking Port, and Mk2 Clamp-O-Tron Docking Port parts
  
• Added Cornet, Trumpet, and Tuba engine parts
  
• Added S3-28800 Methalox fuel tank part
  
• Adjusted MEM-125 Engine Mount color mask and part size to match similar parts
  
• Added auto switching for multi-mode engines like the Rapier
  
• "Sustainer" descriptor added to appropriate engine subtitles
  
• Increased breaking force for wings, control surfaces, and stabilizers
  
• Methane engines are now surface-attachable
  
• Fixed: RTC "Rottweiler" truck chassis has incorrectly-oriented stack attach node and low texture resolution
  
• Fixed: "Statistics" header not properly localized in VAB
  
• Fixed: Air intake parts display unnecessary sliders in VAB Part Manager
  
• Fixed: Gimbal animation code causes log spam
  
• Fixed: Intake air listed as a transferrable resource in the Resource Manager
  
• Fixed: Mesh for SRB-KD25k "Kickback" Solid Fuel Booster is 7.5 degrees from correct rotation
  
• Fixed: Non-convex collision mesh for RF-AD 2000 Mk3 to Mk2 Methalox Adapter causes error message
  
• Fixed: Small nosecone base diameter does not match small stack parts
  
• Fixed: Stack node position on Mk1 "Explorer" Command Pod slightly misaligned

• 🚀 Added flight HUD UI scaling in player settings
  
• 🚀 Added player-controllable splash screen bypass ability
  
• Added description to the "Tab Away Audio" player setting
  
• Added notification when F5 is used to quicksave
  
• Added player setting to toggle visibility of Vessel/Object labels
  
• Added stock vessel filter to KSC launchpad menu
  
• Game View UI element is hidden when there is no active vessel
  
• Updated section names in input settings
  
• Updated settings menu user interface
  
• Updated UI for VAB header, launch assembly icon, fairing construction icons, procedural editing icon, fairing visibility icon, and root part icon
  
• Enabled configuration of unique spawn points for tutorial dialogs for each tutorial lesson
  
• Fixed: Code error in main menu when trying to access a deleted object
  
• Fixed: Implementation of localized File Date/Time is incorrect for regional formatting
  
• Fixed: In some languages, incorrect capitalization used in text for Pause Menu options
  
• Fixed: In wing editor, text has incorrect linebreak in some languages
  
• Fixed: Insufficient campaign save window height causes text overlap
  
• Fixed: Large values in the Tracking Station's Celestial Body Information panel are too long due to absence of large-magnitude unit conversions
  
• Fixed: Launchpad location button selection state does not change when deselected
  
• Fixed: Normal/anti-normal markers on Navball don't match SAS icons
  
• Fixed: Not possible to re-bind "E" key in input settings/controls
  
• Fixed: Part info tooltip text overlaps in some languages
  
• Fixed: Part tooltip appears behind part icon
  
• Fixed: Passive notifications remain visible when UI is toggled off using F2 https://forum.kerbalspaceprogram.com/topic/216500-f2-issues-pause-game-pop-up-still-visible-and-stage-scroll-bar-still-visible/
  
• Fixed: Stage numbering reverses after switching focus between decoupled vehicles
  
• Fixed: Staging stack drop line indicators appear in the middle of stages instead of between them
  
• 🚀 Fixed: Text layout for burn timer does not accommodate long text https://forum.kerbalspaceprogram.com/topic/216781-new-burn-timer-displays-time-incorrectly-when-the-node-is-above-99-days/
  
• Fixed: Trip planner layout does not allow longer localized text
  
• Fixed: Users cannot back out of the Privacy Policy window after exiting to the Main Menu from gameplay
  
• Fixed: VAB part module text extends beyond info panel bounds in some cases
  
• Fixed: When an vehicle is destroyed via the object picker in Tracking Station, parent celestial body list entry does not close

• 🚀 Fixed: Fairing editor button stays on the cursor when moving fairing in the VAB https://forum.kerbalspaceprogram.com/topic/216881-vab-fairing-editor-prevents-dragdrop-options/ https://forum.kerbalspaceprogram.com/topic/216434-cannot-let-go-of-a-part-in-vab-because-the-cursor-is-on-the-wrench-icon/
  
• 🚀 Fixed: Fairings don't properly get out of the way in the VAB internal/exploded mode https://forum.kerbalspaceprogram.com/topic/213001-trying-to-look-inside-fairings-visual-glitch
  
• Fixed: Fairing length slider gets stuck after reverting to the VAB from flight
  
• Fixed: Lower stage Delta-V displays 0 when adding an empty stage above an engine in the VAB
  
• Fixed: Changing radial symmetry count after placing the first part of a strut causes the strut to break
  Fixed: Log error in some situations when selecting the visibility mode icon on an interstage fairing
  
• 🚀 Fixed: Toggling control surface in wing editor fails to remove control surface when editing multiple wings
  
• Fixed: VAB becomes unresponsive after clicking the fairing edit button and doing an unrelated action
  
• Fixed: When holding ALT and hovering over part in the VAB, part asset name shows instead of part name
  
• Fixed: Wrench icon appears before placement of procedural wing

• Adjusted PQS transition range for Vall
  
• Integrated KSC trees into mesh scatter system, reducing lines of code and improving performance
  
• Added level of detail to aviation lights at KSC
  
• 🚀 Fixed: Some lights have missing textures when viewed at KSC https://forum.kerbalspaceprogram.com/topic/216413-ksc-lights-and-windows-appear-pink/

• Adjusted VFX for launch clamps
  
• Adjusted VFX positioning for procedural engine plate shrouds and interstage fairings
  
• Fixed: Log spam every frame when air intake makes contact with the ground
  
• Replaced raycast-based lens flare occlusion with depth-based occlusion
  
• Added pixel-count solution to correlate lens flare intensity with nearest star's visible area
  
• Updated VFX for stack separators and decouplers

• Enabled dragging tutorial windows by headers
  
• Fixed: Fail state dialog does not properly display when failing some tutorials
  
• Fixed: Feature image for "Orbital Transfers" tutorial is incorrect
  
• Fixed: Player-adjusted position of tutorial message box does not persist
  
• Fixed: Subtitles missing from various sections of Orbits are Weird tutorial

• Fixed: "Go" button text field too small for some translated text
  
• Fixed: Bold text illegible in some Asian languages
  
• Fixed: For some languages, anti-aliasing settings have incorrect localization
  
• Fixed: For some languages, non-localized celestial body name appears on SOI entry
  
• Fixed: In some languages, "Fly Safe" placeholder vehicle name not translated
  
• Fixed: Incorrect word order on burn timer UI
  
• Fixed: Localization missing from Kerbal EVA controls window
  
• Fixed: Orientation cube text obscures 3D vehicle icon in some languages
  
• Fixed: Pre-made vehicle information in Save/Load window is incorrectly localized
  
• Fixed: Some text in Settings menu not localized
  
• Fixed: Part description for HFT ""Spherotron"" Hydrogen Fuel Tank not localized"
  
• Fixed: The Enter Text text box for the Campaign Name is displayed in English while creating a new game in a foreign language
  
• Fixed: The Velocity tab's 'Target' text is not translated when observed in any language other than English
  
• Fixed: Tutorial dialogues have minor bugs in some languages
  
• Fixed: Unlocalized strings appear in staging stack

• Fixed: LoadByLabel not properly respecting assets in addressables in mod asset bundles. Labelled addressables should load properly now

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 (for game-breaking bugs)
Dedicated Bug Reports on the KSP Subforum

Credit to Kavaeric for this week’s update graphic remix, thank you!

Good afternoon, fellow Kerbonauts.

The release date for the v0.1.3.0 update has been revised to June 22 (a two-day delay, from next Tuesday to next Thursday). We have a couple of critical bugs that we think will significantly affect the quality of the update, so we’re giving our team a couple of extra days to knock them out and test the changes.

As always, we will post detailed patch notes when the update goes live. The list of fixed items is significant for this one, but major bugs still remain (to give just one example, we still have not completed our fix for the orbital decay issue, which is number one on our priority list). Once the update is live, we will reset the upvote counters on the Bug Reports subforum on the KSP Forums and re-assess our internal priority list based on both community feedback and our own internal testing. On the following dev update, I’ll post our new top-ten most wanted list based on that information. In the interest of avoiding repetition, I will not re-post the current top-ten list here, as all relevant fixes will officially continue to be in QA review until the update goes live.

Our team shares the community view that overly-wobbly rockets are a major issue in KSP2 (it is number 10 on our top-ten issues list). We have introduced a number of mitigations to address aspects of that issue (altering inertia tensor values to decrease joint issues that emerge when high-mass and low-mass parts are connected, introducing various bespoke multi-joint augmentations to areas of known over-flexibility), but we still see this as an area where major improvement is needed. For the record, this is our official view on what a successful implementation would look like, and against which we continue to measure the effectiveness of ongoing mitigation work:

• For inline parts that are connected serially, in most applications there should be little to no flexing. This is especially true when neighboring inline parts are the same core size.
  
• For radially-attached boosters or cantilevered subassemblies with single-point radial connections, some flexibility is expected. There are some applications for which manually-applied struts should be required.
  
• Wings should not require struts to stay rigid.
  
• Docking two vessels in orbit should result in a strong, non-wobbly connection that doesn’t fold on itself as soon as the player tries to move the resulting vehicle.
  
• Wobbly rockets are sometimes fun and funny. A big part of what originally got many of us hooked on the original KSP was the silliness and emergent problem solving that came from playing "World of Goo" with rocket parts. Broadly, we see this as part of the Kerbal DNA, and want to preserve it in some form. Whether that means limiting wobbliness to certain types or sizes of parts, or relegating certain behaviors to player settings, is the subject of ongoing internal discussion. We of course are following community conversations with keen interest, and this is an area where Early Access participants can have a significant impact on the 1.0 version of KSP2.
  
• Joint physics impact CPU performance, and as we progress through the Colony and Interstellar roadmap milestones the part counts will increase dramatically. Any solutions we arrive at for the above requirements must accommodate this reality.
  
• We would like to move away from autostrut, or any other band-aid solution that involves hidden settings that automatically apply additional joints to make a vehicle more rigid. Whatever solution we arrive at, we’d like it to be predictable and transparent to all users. If over the course of Early Access we find that some form of autostrut is still necessary to allow the creation of ambitious vehicles, we’ll revisit this requirement.

As a person who has dive-bombed more than one physics meeting with an exasperated "can’t we just make the joints stiffer" comment, let me assure you that in true KSP fashion, this is not a problem with a simple remedy. We’ve got very capable people on the case, and we will arrive at a good solution.

As our architecture-facing teams chase down critical bugs, the content-focused feature teams have continued to work on features for the Science update, which will introduce the first major suite of new features to KSP2 since the beginning of Early Access. While we don’t have anything to share yet on timing, the following areas have seen significant progress:

• An all-new Science collection and transmission system, along with the assignment of Science biomes to all Kerbolar celestial bodies.
  
• A new Mission system that provides compelling player goals and tracks flight events to determine the achievement of those goals, along with the activation of the Mission Control building to access those functions.
  
• New Science parts that are distinctive enough from one another that they provide interesting vehicle design choices to the player.
  
• An all-new tech tree that provides an interesting part progression that will later expand to accommodate the arrival of future interstellar-grade and colony parts.

And of course, there are some new Kerbal animations for sample collection:


For an HD render, check it out here.

Yesterday, we posted a new dev blog entry from Senior Designer Chris Adderley that goes into some detail on the aero occlusion bug that we fixed this month. It’s a nice example of how certain bugs can not only be tricky to detect (it was in fact a community member who first identified the problem), but how bugs within interdependent systems can compound on one another in ways that make tracking them down especially complicated. It’s a cool detective story, and now that we’re through it, I’m glad that Chris has broken it all down for the rest of us.

Last week’s Build a Base challenge generated some amazing results. Kerman_von_Braun’s achievement appears to have involved the use of a time machine, as it was submitted to YouTube a week before the challenge was announced! But it’s so great, I have to give it a shout-out anyway:


And then there’s Banana Base, by Suppise (some kind of signal noise appears to be corrupting some of these images - we’ll ask somebody to look into it):


We also really liked this Duna tower and rover by Hammo1603:


Congratulations to all who conquered this one!

This week’s challenge: Score a Goal! That’s right, those big spherical hydrogen tanks are about to be kicked, dunked, and spiked across the Kerbolar system! There will be extra (imaginary) points for style.

We are counting on you to perform some ludicrous displays. We don’t want to see anybody walk it in.

Cheers!

---

Keep up with all things Kerbal Space Program 🚀
KSP Forums
KSP Website
Facebook
Twitter
Instagram
Intercept Games Discord
KSP YouTube

Hello everyone!

My name is Chris Adderley, a designer on the KSP2 team. If you've been around the community for a while, you may recognize my alias Nertea, from a few mods for KSP1 that I've made.

At Nate's request, I wrote up a description of how we tracked down a frustratingly resilient community-reported drag bug from KSP Forum user FlazeTheDragon for one of our Friday updates. It became slightly long, so we decided to make it a dedicated dev blog entry. It's long because, well, this was a complex bug to track down!

To describe the bug, how it was found, and how it was sorted, I have to give a little primer on the KSP2 drag model and how it works with respect to parts and aerodynamic occlusion - so buckle up.

Our drag model is very similar to KSP1's, where a part's aerodynamic properties depend on what we call the drag cube. This is a representation of what a part looks like to airflow from 6 orthogonal directions - front, back, top, bottom, left, and right. Hence, a cube! We can project the direction of airflow onto this cube to get an approximation of what the air would 'see' are, therefore, what drag to apply. Drag cubes are calculated by rendering the parts' visuals using special shaders - they give us information about the part's area (white), bumpiness (green), and depth (red), for each of these directions.


Drag cube renderings for the Size M conical command pod.

We can aggregate these views to create three sets of six values - the drag cube itself. This is a very computationally efficient way to store a lot of information about the part. It's a versatile dataset. Besides aerodynamics, we can use this to get things like the dimensions of the pod, the displacement of the pod, etc.

Drag cube data for the Size M conical command pod.

So, a single drag cube is good for a part in isolation, but for a part that's attached to other parts, we need to determine how much of the part is actually exposed to the air (and eventually, the airflow). That's truly the relevant part for calculating drag. Parts that are fully occluded by another part should effectively be invisible to airflow from that direction. You can think of this if you consider a fuel tank behind a cockpit traveling towards the pointy end of the vessel. If that assembly of parts is flying through the air, there should be no drag from the surfaces that connect the two parts.

Schematic examples of how we'd expect a vessel made of 3 parts to behave with respect to the occlusion of each of its faces.

To calculate this occlusion, we use the area component of both parts' drag cubes, which can give use the area of parts from various directions. Take two parts from the above image, Part 1 (the fuel tank) and Part 2 (the command pod), that are connected. We look at the connection direction and modify each part's drag cube areas. We subtract the area of Part 1 in the +Y direction from the area of Part 2 in the -Y direction. We do the same in the opposite direction - subtract the area of Part 2 in the -Y direction from the area of Part 1 in the +Y direction. This gives us a very simply way of approximating occlusion. If both parts are Size S, for example, the area through the connection becomes zero. If one part is Size S and one part is Size M, the Size S part will be completely shielded by the Size M part, but the reverse is not true.

Schematic example of subtracting drag cube Y+ and Y- faces for same-size parts, in two airflow directions.

Schematic example of subtracting drag cube Y+ and Y- faces for different-size parts, in two airflow directions.

I think that's what you need to know about the basics of drag and occlusion. Onto the bug!

We had community reports that were replicated by internal QA that some parts, like stacked decouplers, were affecting the aerodynamic performance of planes and creating too much drag. Planes that seemed like they should go fast went...slow. Exciting stuff - it's time for a bug hunt.

If adding a part to a plane creates too much drag, maybe that part itself has too much drag. We have tools to automatically create drag cubes, and sometimes we tune them manually. That's the first point of investigation for the team. Looking specifically at per-part drag readouts, we didn't find that the parts described in the bugs had any kind of anomalous drag values in isolation. Things looked in-line with what we'd expect. In addition, we couldn't reproduce these issues with rockets. This issue only really showed up when looking at planes. Planes are frustrating for me as a developer as I'm a garbage pilot and reproducing airspeed/velocity conditions reported in bugs takes me quite a while! That KSP2 pause button sure is useful...

So, eliminating general drag as a problem was a good first step. The next step would be identifying whether something was wrong with the occlusion system - but only for very specific parts. Hmm. Some of the specific parts identified were visually hollow tubes. Hollow tubes are a challenge for the drag occlusion system. Reading through my quick description of occlusion above, you might be able to see why, but let's get into that.

How a hollow part behaves by default in the KSP2 drag model to show how it doesn't appropriately occlude the part below it.

The drag cubes for hollow parts are, well, hollow by default! When we go to subtract the cross-sectional areas in a connection, the hollow part has a tiny cross-sectional area, and so won't appropriately shield the next part in the stack. This is fine if the hollow part is first, but if it is in a stack with something else atop it, we want it to occlude properly.

"Filling in" hollow parts to allow them to shield parts behind them.

We solve this in KSP2 by manually adjusting the drag cube areas of hollow parts: they appear opaque in cross section and so subtract appropriately. It's a dirty fix, but it works.

So, decouplers are hollow. Some of the other parts reported with this bug are hollow. IDEA. Perhaps it's our process for manually adjusting this for those specific parts that is causing the problem. This caused a multi-day wild goose chase of frustration and tweaking tiny numbers to no real solution. A clever reader might also realize something form the initial report that makes this avenue of investigation kinda silly in hindsight - if this was the problem, we should have seen this with rockets too, not just planes.

Eventually while examining the results of the wild goose chase, we looked specifically at the cross-sectional areas used for calculating occlusion and noticed an "interesting" discrepancy when considering certain parts. Let's look at this closely:

In this image you get to experience some internally famous 'Chris paint-overs', terrible MS paint scrawls trying desperately to get a point across.

In the above image, I debugged the cross-sectional area for all the part connections on a demo 'plane'. I noticed that the cross-sectional areas for the green and red highlighted parts were a little off. When looking at the green part, the game things that it has a cross-sectional area of 1.19m^2. This is...close to what it should be. But these parts have a radius of 0.625m^2. That number should be closer to 1.23m^2. Suspicious. The real problem is evident by looking at the blue part. The game thinks it has a cross-sectional area of 2.38m^2. That is far too much area - again, it should be 1.23m^2. This provided a reasonable area of investigation. I tried the same approach but with one of the problematic parts from the bug report - the Size S decoupler.

More live occlusion values.

Well, this is just plain wrong. The game thinks this connection between the decoupler and tank (in red) has a cross-sectional area of 0.191m^2. Jackpot! If this area is wrong, then the fuel tank 'behind' the decoupler will not be correctly shielded at all from airflow - the game thinks there's only 0.191m^2 occluding the tank's cross-sectional area of 1.23m^2. If this 'planes' flies forward, the game will act like there's a 1.03m^2 blunt front-fuel tank surface into the airstream and create significantly more drag.

Drag Cube areas for the Size S decoupler.

Ok, great. So where's the problem? Well, let's look at the drag cube for the Size S decoupler. Any of those elements look familiar? The first two and last two numbers are the area from the top, bottom, right, and left of the part, respectively. The middle two entries (front and back, respectively) should be the ones we're using for the decoupler - but we're actually using the bottom two. Nailed it down, that's the core of the bug.

What we'd expect for post-occlusion drag (left) versus what we were getting (right).

It turns out that when we calculate cross-sectional areas in craft orientations that aren't purely vertical (like planes) we calculate drag occlusion incorrectly - we use the wrong face of the attached part's drag cube. This has pretty strong implications that depend on the length and size of the parts you'd use in a plane's stack.

If a long part was in front of a short part, everything would appear fine. We'd be using the 'side view' of the long part with a large area, and that would be pretty good at occluding stuff (though actually TOO good). However, if you had a short part in front, additional drag would be introduced - not only because you'd not be occluding properly, but because the un-occluded area would be very un-aerodynamic!

A silly example of what we'd see (left) versus what the occlusion model would see (right). In this case you get too much drag, because there's not enough occlusion.

A second example of what we'd see (left) versus what the occlusion model would see (right). In this case you actually don't get much drag, because that Mk2 tank is occluding the Mk3 tank too much.

That's enough information for an engineer to develop a fix. In this case, the fix for the issue only needed two lines of code, which was great. Identifying the issue and narrowing down the exact cause was the harder part of this bug.

Now, this isn't to say that drag issues are all solved in KSP2. But hopefully this provides a nice little tidy look at the somewhat messy process of going from a bug spotted by an eagle-eyed community member all the way to something we can fix.

---

Keep up with all things Kerbal Space Program 🚀
KSP Forums
KSP Website
Facebook
Twitter
Instagram
Intercept Games Discord
KSP YouTube