Aug 30, 2023

Kerbal Space Program 2 - mikey

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

Added input binding for toggling freecam in flight
Added NavBall texture color changes based on velocity state
🚀 Improved orbits decaying when vessels are not applying any thrust https://forum.kerbalspaceprogram.com/topic/212388-appe-are-dropping-orbital-decay-when-in-low-orbit-of-some-planetsmoons/
🚀 Fixed: Airbrakes respond to roll inputs https://forum.kerbalspaceprogram.com/topic/217891-airbrakes-deploy-when-performing-roll/
🚀 Fixed: Camera orientation flips 180 degrees after switching to flight from map https://forum.kerbalspaceprogram.com/topic/217818-camera-resets-position-every-time-you-enter-and-exit-map-view/
🚀 Fixed: Normal SAS orientation maneuver burn at periapsis is inaccurate https://forum.kerbalspaceprogram.com/topic/216619-incorrect-maneuver-on-inclination-change-normal-and-anti-normal/
🚀 Fixed: Kerbals eject with extra velocity when EVA'd from Grumble Seats while in space flight https://forum.kerbalspaceprogram.com/topic/217883-kerbals-still-flung-at-high-speeds-when-going-eva-in-space/#comment-4297898
Fixed: Dates don't start on Year 1 Day 1
Fixed: Activate/deactivate action button for engines gets out of sync
Fixed: Alternators produce power when engines are off
Fixed: Animated engine gimbal forces are incorrect after reverting
Fixed: Animated gimbals don't function when offscreen (when in map or offscreen during flight)
Fixed: AP and PE markers of inactive vehicle in orbit stay on screen after switching focus to a landed vehicle within the Tracking Station
Fixed: Action vessel can be controlled while in the Tracking Station
Fixed: Camera zooms in and out when scrolling in some flight apps
Fixed: Cargo bay aero shielding sometimes leaves contained parts out of collider checks
Fixed: Errors generated when launching a vessel with a fairing
Fixed: Hibernate in timewarp doesn't work properly for probes
Fixed: Mouse look does not stay active when pressing Tab in flight
Fixed: Probe cores stop consuming electricity after being decoupled
Fixed: RCS blocks don't work in fine control mode
Fixed: RCS thrusters remain on when switching away from a vessel
Fixed: SAS and throttle sometimes reset when decoupling stages
Fixed: SAS mode buttons do not always register clicks
Fixed: Timewarp overshoots when crossing SOI boundary, causing orbit to change

Optimizations

Added LODs to some KSC buildings
Added LODs to spotlight shadows at KSC
Cleaned up code and UI to improve performance of some windows
Improved performance when hovering over items in the parts picker UI
Improved UI performance when adding or removing stages in the VAB
Improved VAB framerate by optimizing part bounds calculations
Massively improved speed of PAM deployment/closure
Optimized code in the sonic boom system preventing unnecessary calls
Optimized terrain shader by removing expensive and infrequently-used features
Optimized undo and redo actions in the VAB to reduce update delays

Saving & Loading

Fixed: Error generated and failure to load when attempting to load a game with a crash-landed vessel
Fixed: Error spam while loading a game with a vessel orbiting Kerbol

Parts & Stock Vessels

Adjusted colliders for all landing gear parts so they are more accurately selectable/highlightable
Fixed: LY-60 landing gear sometimes flips when extended
Fixed: Rovemax M1 twitches back and forth at the suspension when off the ground in flight
Increased fairing maximum length for AE-FF000, AE-FF125, AE-FF250, AE-FF375, and AE-FF500 parts
Updated drag cube for the HS-I Deluxe Inflatable Heat Shield so that it properly changes when deployed and retracted
Updated the side count of the RF-AD-L 800 fuel tank to better match like-sized parts
Updated the side count of the RS-AD 800 fuel tank to better match like-sized parts

UI / UX

🚀 Fixed: Flight UI flickers when using an AMD GPU https://forum.kerbalspaceprogram.com/topic/217867-graphical-glitches-on-amd/
Adjusted interactable area on scrollbars
Improved how loading tips are displayed to show more of them
Updated fairing editor icons to improve legibility
Fixed: HUD issue that occurred when scaled to 50%
Fixed: Holding click and dragging some buttons can cause the wrong visual state to display
Fixed: Only one celestial body name can be pinned at a time in the Tracking Station
Fixed: Part description does not expand when pressing Shift in the part picker
Fixed: Save window in the VAB can be dragged horizontally
Fixed: Tracking Station load screen remains visible when transitioning from Training Center

Construction

🚀 Fixed: Center of Thrust, Center of Mass, and Center of Pressure markers appear when there's no vessel in the VAB https://forum.kerbalspaceprogram.com/topic/216597-centre-of-massthrustpressure-vectors-sitting-on-the-vab-floor/
🚀 Fixed: The player is unable to change symmetry modes while holding the first part of a strut or fuel line. It is now only locked when holding the second part. https://forum.kerbalspaceprogram.com/topic/217953-cannot-change-symmetry-while-holding-a-strut/
🚀 Fixed: When Alt-copying a subassembly with wings, the copy has one of the wings flipped upside down https://forum.kerbalspaceprogram.com/topic/217851-plane-wings-invert-on-copy-paste/
Fixed: Camera panning orientation does not update when toggling vehicle orientation modes in the VAB
Fixed: Engine shrouds are generated incorrectly when stack attaching a non-root engine above other parts
Fixed: Current anchor point and potential anchor points are not differentiated in the VAB
Fixed: Fuel bar is sometimes empty when loading a vessel in the VAB
Fixed: Undo removes the held part
Fixed: VAB and anchor points appear when they should not
Fixed: Parts Manager shows the pod icon for all categories
Reduced delay for disappearance of fairing and wing edit buttons when cursor has moved away from procedural part
Fixed: New workspace not resetting history snapshots for the Undo tool
Removed duplicate history snapshots for the Undo tool for compound parts
Fixed: Part of the LY-35 Landing Gear shakes uncontrollably when placed in the VAB
Fixed: Base size of TOOB-375 adjustable tube causes stacked tubes below to generate the wrong size fairing in the VAB
Fixed: RF-AD-B 400 does not create a copy of the part when node attaching a part

EVA

Fixed: Jetpack cannot be used on previously EVA'd Kerbals when EVAing a new Kerbal

FX & Audio

Adjusted timing of voiceover when reaching a maneuver in the burn timer
Fixed: Audio stopping under some circumstances
Fixed: Sounds based on time of day do not play correctly at KSC
Fixed: Vessel audio is not heard when throttling or staging the vessel while in map mode

Tutorials

Fixed: First time user experience confuses map view for tracking station view
Fixed: The player loses keyboard and camera control when pausing and resuming a tutorial mission while in map mode in the Training Center
Fixed: Training Center shows artifacts in the background when transitioning from VAB
Fixed: Tutorial "Deorbiting" does not detect a crash event correctly

Localization

Integrated: Localized strings for save gameplay menu

Modding

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

Known Issues

Orbital Decay: Improvements have been made to address the issue and we continue to work on eliminating it completely.

Performance Degradation: While we have seen improved performance in many ways as noted in the Optimizations section above, some players may see issues on GPU-bound setups while in orbit around Kerbin or on the surface of other planets. We are working to resolve this issue. If you see any changes in your performance, please fill out a bug report through the link below.

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

Jul 21, 2023

Developer Insights #21 - Rockets' Red Glare

Kerbal Space Program 2 - mikey

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.

Thermal Challenges

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:

It must feel authentic and model the core challenges of heat for spaceflight, atmospheric flight and colony building.
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.
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.
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.

Diving Core User Stories

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.

Consider a Spherical Cow in a Vacuum

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.

Shape of the Solution

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.

Development and Deployment

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.

Jun 30, 2023

Hot Fix Summer

Kerbal Space Program 2 - mikey

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.

Bugs: The Next Generation

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

Orbital Decay [25 votes]
Incorrect Maneuver on Inclination Change [10 votes]
Cannot Change Craft/Vessel Name in Tracking Station [9 votes]
AIRBRAKES Deploying on Roll [9 votes]
Camera Resets Position Map View [8 votes]
Graphic Glitches on AMD [8 votes]
Engine Sound Effects Not Playing [7 votes]
Cannot Change Symmetry While Holding Strut [7 votes]
Center of Mass/Thrust/Pressure Vectors Sitting on VAB Floor [6 votes]
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!

AMA with Kristina Ness, Art Director

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

KSP2 Steam Sale

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!

Weekly Challenge

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!

Summer Changes

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

Jun 23, 2023

Friday the v0.1.3.0th

Kerbal Space Program 2 - mikey

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.

What's Next

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

Steam Sale

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!

Upcoming AMA

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!

Weekly Challenge

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!