Intercept Games

KSP2 Update v0.1.4.0 Release Notes <-- 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! Bug Fixes Construction Fixed: Center of Thrust, Center of Mass and Center of Pressure markers appear when there's no vessel in the VAB [1] 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 [1] Fixed: when Alt-copying a subassembly with wings, the copy has one of the wings flipped upside down [1] 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, 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 Vehicle Assembly Building 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 doesn't 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 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 [1] Fixed: airbrakes respond to roll inputs [1] Fixed: camera orientation flips 180 degrees after switching to flight from map [1] Fixed: Normal SAS orientation maneuver burn at periapsis is inaccurate [1] Fixed: Kerbals eject with extra velocity when EVA'd from Grumble Seats while in space flight [1] 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: active 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 Time Warp 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 don't always register clicks Fixed: Timewarp overshoots when crossing SOI boundary, causing orbit to change FX and 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 don't play correctly at KSC Fixed: vessel audio is not heard when throttling or staging the vessel while in map mode 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 Optimization 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 Parts and 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 Saving and 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 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 UI/UX Fixed: Flight UI flickers when using an AMD GPU [1] Adjusted interactable area on scrollbars Improved how loading tips are displayed to show more of them Updated fairing editor icons to improve legibility Fixed a 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 to Tracking Station 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 Optimization 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 and if you see any change 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 Forums Join us on Discord to discuss potential changes Bug reports should be shared to: KSP Forums Bug Reports

Hi all! Welcome back to another K.E.R.B (Kerbal End-users Report Bugs) check-in! Major progress has been made on many of the community's top issues, including a two big ones: orbital decay and AMD Graphics Glitches. We'll be soon sharing an interview Nate had with David Tregoning who was the go-to guy on investigating the Orbital Decay bug. That interview also dives deep into the Wobbly Rockets issue and discusses some potential short-term and long-term solutions. Keep an eye out on our socials for that one! We're excited to share that many of these fixes and more will be included in Patch v0.1.4 which is due out August 22nd. As always, thank you again for your contributions to the bug reports subforum! The quality of bug reports have gone up significantly and being able to quickly reproduce issues gives our team more time to actually implement fixes, we truly appreciate it! Current Top Issues: # Bug Status 1 Wobbly Rockets Investigating short-term and long-term solutions 2 Orbital Decay Some instances resolved [See Nestor's Note Below] 3 Undock/Decouple/Physicsless Parts causing Crafts to Fall Apart Some instances resolved [See Nestor's Note Below] 4 Graphic Glitches on AMD Hardware Fix implemented and verified 5 Incorrect Maneuver on Inclination Change Fix implemented and verified 6 Cannot Change Craft/Vessel Name in Tracking Station- Fix implemented and verified 7 Camera Resets Position Map View Two issues, one fixed and verified 8 Velocity of Target Not Displayed as Relative to Target Trying to reproduce, pushed to future patch 9 Cannot Change Symmetry While Holding Strut Fix implemented and verified 10 Engine Sound Effects Not Playing Fix implemented and verified 11 Active Vessel Pulls Craft Close when in Timewarp Fix implemented and verified 12 Wobbly navball pro/retrograde markers at low relative velocities Pushed to future patch 13 Undocking on pause causes vehicle to disintegrate Pushed to future patch 14 AIRBRAKES Deploying on Roll Fix implemented and verified 15 EC is not consumed or is produced infinitely Fix implemented and verified 16 Parts Manager Scroll Wheel Fix implemented and verified 17 Prograde/Retrograde buttons not clickable Fix implemented and verified 18 Center of Mass/Thrust/Pressure Vectors sitting on VAB Floo Fix implemented and verified 19 Control Surface Oscillation in Atmosphere Investigating short-term and long-term solutions 20 Plane Wings Invert on Copy Paste Fix implemented and verified Note: this report is not fully representative of the work our team is focused on. This is just to provide insight into our progress on the most concerning issues to our community. Additionally, the lack of a status update does not imply a lack of importance or general progress - we just do not have anything to share at this time. Thank you!

Hi all! Welcome back to another K.E.R.B (Kerbal End-users Report Bugs) check-in! We're making great progress towards v0.1.4 with many of the community's top issues being addressed alongside many other smaller issues. We do not have a timeline to share just yet, but we hope that these status updates provide some insight into what you can look forward to being included. Thank you again for your contributions to the bug reports subforum. We truly do value your feedback as it has been critical in helping us reproduce and investigate some of the trickiest issues we've encountered thus far. Current Top Issues: # Bug Status 1 Wobbly Rockets Investigating 2 Orbital Decay Working on a fix 3 Undock/Decouple/Physicsless Parts causing Crafts to Fall Apart Investigating most common reports 4 Incorrect Maneuver on Inclination Change Fix implemented 5 Graphic Glitches on AMD Hardware Investigating 6 Cannot Change Craft/Vessel Name in Tracking Station- Fix implemented and verified 7 Velocity of Target Not Displayed as Relative to Target Investigating 8 Camera Resets Position Map View Working on a fix 9 Cannot Change Symmetry While Holding Strut Fix implemented and verified 10 Engine Sound Effects Not Playing Partial fix 11 Active Vessel Pulls Craft Close when in Timewarp Fix implemented and verified 12 Wobbly navball pro/retrograde markers at low relative velocities - 13 Undocking on pause causes vehicle to disintegrate Investigating, similar to #3 14 AIRBRAKES Deploying on Roll Fix implemented and verified 15 EC is not consumed or is produced infinitely Fix implemented and verified 16 Parts Manager Scroll Wheel Verifying fix 17 Prograde/Retrograde buttons not clickable Fix implemented 18 Center of Mass/Thrust/Pressure Vectors sitting on VAB Floo Fix implemented 19 Control Surface Oscillation in Atmosphere - 20 Plane Wings Invert on Copy Paste Fix implemented Note: this report is not fully representative of the work our team is focused on. This is just to provide insight into our progress on the most concerning issues to our community. Additionally, the lack of a status update does not imply a lack of importance or general progress - we just do not have anything to share at this time. Thank you!

Hey everyone! Chris Adderley here, one of the designers on the KSP2 team here at Intercept Games. If you've been around for a bit, you might also know me as Nertea! 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 are 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. Divining 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. Avoiding Meltdowns 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. 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 using radiation, with radiator parts in space, or by using the local atmosphere’s convective abilities on a planet, or possibly by 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. Slightly Singed Landings 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 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. Exoplanets? More Like Exothermic Planets! 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. Damnit Jim, 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. Smaller, Simpler Problems 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 will 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! Putting It Together 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 or other, 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 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. Determinism vs. Simulation 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 useable 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. Alternately 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 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. What's Changed 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 50000 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 fluxes from things going on in a part, like heat radiators and other heat sinks. Positive flux from 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 a reentry context 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 engines is firing, 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 is 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. Timewarp and Loading 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. Planning for Success 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 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 enjoyed writing it. Until next time, Chris Adderly Senior Mechanical Concept Designer

A New Opportunity: Our QA Team is looking to bring on a new full-time QA Tester who will collaborate with our team on K.E.R.B. and work directly with you all on your bug reports. Passionate about games and got an eye for detail? Apply here.

Hi all! Welcome to the first official check-in on our new bug reporting system: K.E.R.B (Kerbal End-users Report Bugs!) We rolled out the new subforum with the release of KSP2 v0.1.3 and we're so thankful for the engagement with the system thus far. We still are looking to make improvements in the workflow, but we think overall the visibility of bugs has increased tremendously - leading to more users contributing to existing bug reports, and our QA team being able to quickly understand and replicate issues. Ultimately, this has led to reduced workload on our team so we can 100% focus on implementing fixes, as seen with the recent v0.1.3.1 and v0.1.3.2 hotfixes. Again - thank you all for your contributions! Big shoutout as well to our Bug Hunters @Anth12 and @linuxgurugamer who have massively assisted with the organization of the reports. Current Top Issues: # Bug Status 1 Wobbly Rockets Investigating bug reports. Internal discussions happening surrounding design implementation. 2 Orbital Decay Fix in-progress 3 Undock/Decouple/Physicsless Parts causing Crafts to Fall Apart - 4 Incorrect Maneuver on Inclination Change - 5 Graphic Glitches on AMD Hardware Investigating. Working closely with external partners. 6 Engine Sound Effects Not Playing - 7 Cannot Change Craft/Vessel Name in Tracking Station Fix in-progress 8 Camera Resets Position Map View Fix in-progress 9 AIRBRAKES Deploying on Roll Fix implemented, now testing 10 Cannot Change Symmetry While Holding Strut Investigating 11 Wobbly navball pro/retrograde markers at low relative velocities - 12 Active Vessel Pulls Craft Close when in Timewarp Fix in-progress 13 FPS Issues past clouds - 14 EC is not consumed or is produced infinitely Fixed for probe cores. Investigating other EC drain reports 15 Velocity of Target Not Displayed as Relative to Target - 16 Plane Wings Invert on Copy Paste - 17 Center of Mass/Thrust/Pressure Vectors sitting on VAB Floor - 18 Prograde/Retrograde buttons not clickable - 19 Parts Manager Scroll Wheel - 20 Control Surface Oscillation in Atmosphere - Note: this report is not fully representative of the work our team is focused on. This is just to provide insight into our progress on the most concerning issues to our community. Additionally, the lack of a status update does not imply a lack of importance or general progress - we just do not have anything to share at this time. Thank you all!

Last updated: 12/18/2023 See notes below.

KSP2 v0.1.3.2 Hotfix Release Notes Bug Fixes Map & Tracking Station Fixed: trajectory position changes when vehicle transitions between Spheres of Influence [Original Bug Report] UI/UX Fixed: Navball markings are blurry [Original Bug Report] 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 Forums Join us on Discord to discuss potential changes Bug reports should be shared to: KSP Forums Bug Reports <-- 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!

KSP2 v0.1.3.1 Hotfix Release Notes Bug Fixes Flight Atmospheric Drag not correctly applied to capsule after decoupling [Original Bug Report] UI/UX Procedural fairing editor buttons overlap one another in VAB [Original Bug Report] 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 Forums Join us on Discord to discuss potential changes Bug reports should be shared to: KSP Forums Bug Reports <-- 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!

Thanks to these forum members (and many more!) for submitting bug reports that directly led to many of the fixes included in this patch: @Fermentation, @NoobAlike, @axxessdenied, @supertiefighter, @FlazeTheDragon, @boolybooly, @jclovis3, @mdkendall, @VecTorr, @Anth12, @Koddra, @markyy, @Gaberz, @Davidian1024, @Sivako Aerospace, @Jatwaa, @Suppise, @schlosrat, @Damon, @vianna77, @Greyflex A big thank you to everyone who has submitted bug reports so far. We appreciate everyone's contributions to helping us reach new heights for KSP2.

KSP2 Update v0.1.3.0 Release Notes <-- 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! Bug Fixes Construction Fixed: fairing editor button stays on the cursor when moving fairing in the VAB [1] [2] Fixed: fairings don't properly get out of the way in the VAB internal/exploded mode [1] 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 Environments 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 [1] EVA 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 [1] 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 [1] [2] [3] [4] Flight & Map Added ability to toggle visibility of some 3D map elements Added multijoint 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 [1] 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 [1] 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 launcpad Fixed: Launching "Jumping Flea" vehicle causes null states [1] Fixed: NaN displayed in the drag/lift ratio value. Still future work to do here. 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 [1] 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 [1] 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 [1] 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 FX and Audio 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 Localization 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" [1] 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 Modding Fixed: LoadByLabel not properly respecting assets in addressables in mod asset bundles. Labelled addressables should load properly now Optimization 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 [1] Fixed: trees vanish before they are completely off-screen Fixed: scatter objects render at first level of detail at all distances" Parts and Stock Vessels 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 in-flight 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 [1] Saving and Loading Fixed: TravelLog Manager causes runaway save file inflation [1] 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 Tutorials 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 UI/UX 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 [1] 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 [1] Fixed: stage numbering reverses after switching focus between decoupled vehicles [1] 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 [1] 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 [1] Fixed: VAB part module text extends beyond info panel bounds in some cases Fixed: when a vehicle is destroyed via the object picker in Tracking Station, parent celestial body list entry does not close 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 Forums Join us on Discord to discuss potential changes Bug reports should be shared to: KSP Forums Bug Reports

Hello! 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 of Nertea from a few mods for KSP1 I have 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 in terms of aerodynamics 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' and, 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 the truly 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 example 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 us 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. 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 simple 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. On to 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 Chris wild goose chase of frustration and tweaking tiny numbers to no real solution. A clever reader might also realize something from 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 paintovers’, 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 thinks that it has a cross sectional area of 1.19m2. This is… close to what it should be. But these parts have a radius of 0.625m2. That number should be closer to 1.23m2. Suspicious. The real problem is evident by looking at the blue part. The game thinks it has a cross sectional area of 2.38m2. That is far too much area - again, it should be 1.23m2. 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.191 m2. 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.191m2 occluding the tank's cross-sectional area of 1.23m2. If this 'plane' flies forward, the game will act like there's a 1.03m2 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. The middle two entries (front/back) 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 area 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 that 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 as 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 2 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.

Developer Insights #19 - Try, Fail, Try Again...and Again The QA Dev blog Who are you?? My name is Darrin, and I’m the new Director of QA here at Intercept Games. I’m new to the Intercept team (I joined a week before the KSP2 launch…) but I’m not new to QA. I’ve been doing software testing since the early 90s and I worked at Visio/Microsoft for 17 years and then at Amazon for the last several years (most recently as a founding member of the Luna game streaming service). I’m an old-school hardcore gamer - I’ve been playing since I had Bards Tale on my Commodore 64, and my Xbox gamer score is 150,000+ and I don’t pad that with those silly games to just farm achievements! I’m doing my best to learn KSP2 as fast as I can, and just so happen to sit directly next to Nate, and I’ve received the rarely given “high five” that I will cherish always. Please contact Private Division Customer Support for any game breaking issues such as hard crashes: Submit a request – Private Division Support . But, if you are posting about an issue on the Discord, the Forums, or even on Reddit, on the more data we have the better (aka in the Specs discussion in Discord, you’ll want to post your detailed specs info!) Bugs and Stuff Running into an issue is frustrating; I feel your pain. Trust me when I say, bugs drive us just as crazy as they do you (honestly probably more, because we need to retry them over, and over, and over!) But when you find an issue that is important enough to post about – you can do it one of 2 ways: A. “This game doesn’t work! I can’t play!!” (end of message) Or B. “This game doesn’t work, here is some info and specific steps of what I was doing – please fix it!!” (adds a bunch of information we can work with) We will obviously do as much as we can about B, but there is literally nothing we can do about A. I’ve chatted with Dakota and the others on the Community team… and they don’t ban people for hitting us with hard criticism. You bought the game, and you are VERY entitled go full rage-mode on the boards when you run into an issue. But, at the same time: we don’t have to read it. So, if you are over the top and just trolling the boards… we probably aren’t reading that. But, if you are giving harsh but fair critiques – we take that to heart and bring that voice back to the greater team and do everything we can to ensure it gets taken care of. So, help us help you and please give us all the info we might need. This helps us move issues up the chain faster and keeps others from having to ask you for the same information over and over: Title: (a sentence that summarizes the issue) Specs: (see further below for how to give us all the info we need here) Severity: (high/med/low). This is your opinion – but it typically goes (High = crash, Med = feature not working as expected, Low = there is an issue, but has a work around) Frequency: (high/med/low). Does this happen a lot? Can you reproduce it consistently? Or was it a one off? (still want to know about it, but we’ll categorize it as such) Description: Tell us what you were doing, what you expected to happen and what actually happened, etc. More information here the better, but we want specifics not generalizations. Screenshots are good, videos are good, save files, etc. HOW you were making something is very important here. Giving us a fully built rocket for us to load and try…. might not have the same results has giving us the steps of how you built that rocket. How you created it and the order you made it in is often far more important than the end result. Helping us Test I can hear some of you now: “Hey…! Why do we have to do the work for you???” I’ll be 100% honest – you don’t. Very few bugs that come from the community are not already found by a fantastic QA team here. But sometimes bugs can seem to be a “one off” or very difficult to put together consistent repro steps. The more information we have and the more we know people hit it, the less time it will take to turn-around a meaningful fix. We watch the forums… I personally spend a lot of time looking over the Discord and I know a Senior Engineer who keeps a close eye on the official Forum here. And no, Dakota didn’t mute me as punishment… I just don’t trust myself to chat in most channels (but I do read and react) - but for some important areas/issues, I’ll get directly involved. Most of us don’t respond a lot, but we see the conversations, take notes, and use that information when we can. Why did you fix bug A and not bug B? “Wait… if the QA team is finding all these bugs, why aren’t they all fixed?” The process of deciding what bugs to fix is quite complex and is based on many factors. We do not always go after the easiest bugs to fix, but rather bugs we feel will have the largest customer impact at any given time. But at the same time, we must consider the impact of any bug that while fixed could have other implications (aka regressions). We factor in the severity of the bug combined with the frequency as well as a ton of insider knowledge from people here on the team and we work very closely across all roles and make these decisions together as a team. We care a LOT about bug regressions… so if you see a new bug that didn’t exist previously, then please pass along the information to us and we’ll look into it asap. But, remember… a change to how something works from one build to another is not necessarily a bug. We’re in Early Access and we’ll make changes to how things work at times to see how that goes and iterate on that over time. How long does fixing a bug take? Investigating a bug takes time to get a precise scenario for the engineer to address (that’s why the steps and info above can help). They will then do their own investigation on the fix itself (what it would take, what parts of the code would be affected, how risky of a fix it is, could it break other parts of the title, etc). Once that’s approved there is a code review of the changes that were made. Then the change is put into a specific branch/build of KSP2 where testers will do full investigation of the original bug and do halo testing around the areas that the code affected. Then, finally it goes into a release candidate build along with a bunch of other fixes and it gets tested again in a very deep regression suite of tests to ensure that other (supposedly unrelated areas of the product) still function as expected. There’s actually even quite a bit more to it than that - but it’s a good summary of how we do things here. How do you test a game as complex as KSP2? Kerbal Space Program is….. huge. I’ve owned the testing of products that ship to hundreds of millions of users that had a simpler test matrix than KSP2 does. There are a LOT of areas, processes and stages of testing a product, and I’m not going to go into all of them here (it would be a doc 20x longer than this). So, this blog is mostly focused on end-user reported issues and how we deal with those. But with regards to complexity our KSP2 Test Lead Josh who’s been playing KSP since 2013 & testing it for the past 5 years, put some information together: "Talking about the complexity of construction, and variables for potential issues, there is a consideration on why something may not be known, tracked, or reproduced before. How unique is your vessel? It’s straightforward to test parts in a vacuum (the “by itself” kind, not specifically the “no air” kind) and confirm that all the bits and pieces are functioning as designed. However, interactions between various parts are where we often see things go sideways. There is a hierarchical interaction that can cause problems, and compounded by where it was placed relative other parts, when it was placed (order of construction), which is further exacerbated by what was done before the vessel was made and how it’s been flown. Let’s break down possible iteration numbers to give an example as to the potential complexities available in KSP 2: If you were to use every stack attach part that has a top and bottom stack attach node in every possible permutation without duplicates, it would be factorial 245, which translates to a number 481 digits long. For reference, the estimated number of atoms in the known universe is only about 10^80, or an 81 digit number. So… The above is interesting, but not realistic. In normal circumstances, you are not likely to build a vessel using EVERY stack attach part. If you assume people are only using about 30 stack parts in a single vessel stack (so a non-repetitive permutation of 30 out of 245 possible stack parts) you still end up with 7.429002947 E+70, or a number about 71 digits long. That’s permutations, however. What about just using specific parts together in general in no particular order (combinations)? That has to be a significantly smaller number right? Well, even dropping this down to only combinations using 15 of the 245 potential stack attach parts with double (top/bottom) attach points still gives us a total of 3.396886498 E+23 possible combinations (or a 24 digit number).For comparison, the number of Stars in the sky is estimated only about 200 Sextillion (or a 2 followed by twenty-three 0’s, also 24 digits long in total). Keep in mind, this is not counting variations using... Parts with a single stack attach node Stack parts that are attached radially (and the surface attach only parts) Subassemblies that can be inside fairings/cargo bays Parts stack attached to other radially attached parts connected to the center stack of the vessel Adapters that allow stack attachments in other directions Adapters that allow a single stack to diverge or converge (such as bi/tri adapters) Translate/rotate transform parts (which also add new orientations to branch off from) This isn’t to say we cannot infer certain configuration details. For example, it’s likely after an engine you probably are not placing another engine, or even a fuel tank (usually it’s a decoupler or separator). But what if, buried in your vessel somewhere, there were 2 engines stacked atop one another, and then that was vertically translated into a fuel tank and then hidden? A picture is worth a lot, but it wouldn’t help reproduce your issue. A save also would also not immediately make clear how this was built. An example of how configurations can have impact, we recently fixed an issue with a handful of small parts that would cause the entire vessel to fly apart at a certain point in flight, only when used in conjunction with other specific (similar) small parts in a specific hierarchy order. Not all combinations of a vessel using those parts caused this, only in specific permutation orders. One of the best ways to ensure a bug you encounter in flight is tracked is to give us as much information as possible. A log file and save help a lot, but if you have a workspace file for your vessel, in some circumstances, that can be even better. There is more to this game than parts, but the above is a math heavy example of the complexity we are working with in test. This is by no means the only game to have this many potential variations to consider, and it won’t be the last, I am sure. The one take away is this, the more information that can be provided with the circumstances something went wrong, the quicker we can identify the issue. Attempting to reproduce issues with just a list of the 20 parts used to create a vessel? That could take a VERY long time." All that being said - someone on the team did the math and even with our entire product team testing on a particular build of KSP2… our total user base will pass that time spent testing within hours of release. We use a matrix method that combines every feature with frequency of use across all hardware combinations and operating systems. This testing effort is what really adds to the time between patches, and then if we combine bug fixing alongside of new feature development… it’s big. Automation helps of course, but as users of the product you can understand that the majority of testing needs to be hands on. It’s not all crazy matrixes and slogs of testing we have to do. We also have fun playtest events with themes (quite a few are ones we do just before the community team sends them out as challenges): From a recent playtest where a Designer on our team Chris is trying to branch out from rockets. How big is the QA team? I’ve worked at both Microsoft and Amazon as well as a few smaller companies, and our QA to Dev ratio is on par with just about any team I’ve ever been on. We have a dedicated QA team here at Intercept (Seattle) who follows the feature crews as new features are developed and a larger QA team within Private Division (Las Vegas) who owns regression passes and overall validation. We supplement needs (hardware testing, OS’s, etc) with some vendor testing from time-to-time. We even have a large amount of previous hardcore Kerbal players that joined our team and have been helping us out, no matter their role (and I don’t mean just Nate!). We’ve got a ton of experience on the team going back to the early KSP1 days as well as others who have come during KSP2 and are now some of the best creators on the team. Here are a couple pics from Lo - who is a member of the PD QA team in Las Vegas. What are you currently working on? You can pretty much look at the roadmap and see all the stuff that’s coming. And… we’re involved in ALL of that. Lately we’ve been deeply involved in Patch 1 and Patch 2, while at the same time getting early looks at features that are still quite a ways out - something like Multiplayer (below) is something we’ll be involved in for a very long time and looking at it while we test all the other new features that are coming. Min/Recommended Hardware questions Every company handles minimum requirements a bit differently, but we use them as our bar of initial support. (aka we don’t officially support or test anything below minimum requirements.) We set that bar based on the performance checks we’ve done in-house during our testing & evaluation process. Some users may choose to try to run KSP2 on a below the minimum bar computer even though we don’t officially support it and we allow that (aka we don’t do a check at launch to determine hardware and force a hard stop at that point). This choice is a tough one, because we want to allow users who might have some very specific or unique hardware to try to run KSP2 and this allows some specs clearly below the min bar to try to run even though that will likely cause issues. And that’s where things can get crazy – because we’ll see someone post on the boards that the game is unplayable and that they have a good computer to play it on, but after drilling in – the majority of the time the computer is below the minimum requirements bar (and the telemetry we currently have tells us the same story). Somewhere between our recommended settings and our minimum settings is where we do the majority of our testing. We have a large variety of hardware in-house and we supplement that with vendor testing, but there will always be cases where users will try hardware that we haven’t and don’t have access to. In these cases, we greatly value the input from the user base and will acquire hardware from time-to-time ourselves, when needed, based on that info. Constructive feedback can provide positive results: There was a very large thread on our Discord and a subset of users who all had specs below the min bar - they all had integrated graphics cards and were having very similar results (KSP2 wouldn’t load - at all). I checked in with our Senior Engineer, Mortoc, on this topic and he suggested a potential workaround by having them set their Windows resolution to 1024x768 - and now most of them are now able to play. No promises of course since it’s below the minimum requirements, but it’s worth a shot if you are also having that issue. Our goal is to slowly decrease the minimum requirements over time, but we can’t guarantee where it will go to, or what those requirements will be. We’ll use the data that comes in from users, our automated benchmarks that we run as well as in-house testing to monitor performance over time. Building functional complex ships is a goal on the team as well. Marc, a tester on the team since early KSP1 days (aka Technicalfool on the Discord) sent these to me when I asked for a ship to use for testing. Best way to get your Specs info: The more spec information we can get, the better that we can help you solve issues. Typing it in is great, but even the best of us can have a memory lapse and think we have 16GB when maybe we only have 12GB. Same with video cards…. It can get super confusing - and if someone on the team is investigating an issue for you only to find out the specs you listed were incorrect… it’s wasted time. So, a screenshot of your specs is best and here’s how you can get it: IF you are running via Steam: Click “Big Picture Mode” in the upper right corner of the Steam window. Then bring up the menu from the lower left and choose: Settings → System. Scroll down to the Hardware section and then use the Snipping Tool to get the info needed. (To exit this mode - click in the bottom left of the window and then click Menu - Power - Exit Big Picture mode) Alternatively, if you don’t have Steam or want a lot more info: In Windows – hit the Winkey (⊞ Win) to bring up the start menu and type in: dxdiag This will bring up the DirectX Diagnostic Tool. The first tab (System) will show your system model, processor, and memory. Now, just click the “Save All Information” button at the bottom, and it’ll put everything into a text file. Nothing in that file should be harmful to send, but if you don’t want to share everything else on there, just do a screenshot of the important areas (the snipping tool works great for this): The other tabs will give you information about your displays and video cards (which is typically more important if you are having performance issues). If you have multiple monitors or a laptop connecting to a monitor – then you might have to click on the last display tab to see the correct video card information. Again, if you don’t want to share all your info – just get a screenshot of the important stuff: We’re here for you. The good, the bad and even the ugly. We like to hear what you have to say. Our fantastic community team keeps us in the loop (and coordinates us doing stuff like this doc and the AMAs) and we love to meet and chat with you all in person as well. We had the opportunity to chat with some of you at GDC (had quite a few Mun and Minmus landings) and we’re looking forward to more in-person events in the future. How can I join the QA team or other roles at Intercept Games? All our open roles are listed at Intercept Games Most of the KSP team are previous players and there are more than a few former mod designers (and a writer) who are now a part of our Kerbal team. We love the game and for many it’s the dream job… I know it is for me. So, if you love KSP and want to be a part of the team- check out our reqs listed above. But no matter what is currently listed – we are always on the lookout for great people. Even without an open req, we keep our eyes open here on the boards and other places that we interact with the users. And for QA specifically… keep an eye out, because one (or 2) might show up on that list above very soon… Thanks everyone from the KSP2 QA team! This isn’t the entire QA team, but I did get a chance to meet with a lot of them last week. I’m the super tired looking one on the far left (it’s Vegas - what can I say??). Mike is the professional wrestler in the middle (that’s not a joke btw). Safety Note: Public Postings If you share personal information, post an image or video, or provide other content in public forums such as on a message board, chat room, comment field, or profile page, other people can view, collect, and use that information. If your user name or ID contains your name, your name will be publicly available on leaderboards and elsewhere as described in this Privacy Policy. Users of such public forums may be able to identify you, use the information to send you messages, or copy any of the images, video, or content you have shared. There is no expectation of privacy or confidentiality on any of these public forums. Please do not share your personal information in public forums or in your user name or ID. You are responsible for any information or content you publicly post using our Services.

KSP2 Update v0.1.2.0 Release Notes <-- This rocket denotes an issue or change that community members directly helped by sharing it with our dev team. Thanks to all of you who send in bug reports and suggestions! Bug Fixes Construction Stage groups now remain in their proper order when switching between multiple assemblies in the VAB The Parts Manager can now be opened for subassemblies in the VAB Added proper handling of nested symmetry sets Fixed an issue that could cause staging order to change when reverting to VAB with complex, multi-vessel workspaces. Fixed vehicle-in-floor VAB bug Iconography updated in the VAB for fairing editor controls, assembly anchor markers, and launch assembly markers Fixed a bug that removed struts and fuel lines from duplicated subassemblies in the VAB Fixed an issue with deleting an assembly sometimes failing when dropping the assembly in the trashcan Fixed warning in the Engineer's Report about vessel not generating electricity Fixed multiple instances where "center of" tools behaved unexpectedly when there was no vessel data Fixed a bug that caused procedural editor icons to sometimes persist into other areas of the title Environments Added new building illumination to KSC that activates and deactivates based on time of day Kerbals are now properly illuminated on the launchpad at night Updated collision meshes and materials for KSC parking garage Loading a game near Eeloo or Pol no longer causes SetPixels errors Improved distribution of rock scatter objects on Kerbin's surface Fixed fuzzy "scan lines" visible on clouds when using AMD Graphics Cards Height fog added to Kerbin, Duna, Eve, and Laythe Celestial body ground scatter updates on Minmus, Eve, Eeloo, Ike, Duna, Mun, Tylo, and Bop Terrain scatter updates for Moho, Vall, Gilly, Laythe, Pol, and Dres Terrain shadow accuracy improvements on Minmus Fixed terrain artifacts at Eve's north and south poles Removed texture seams from grass around launchpads Improved appearance and performance of underwater caustic effects Fixed global illumination contributing on lighting on the opposite side of objects Fixed memory leak caused by lighting while in the VAB Fixed plants on Kerbin rendering incorrectly Fixed an issue that could cause blurry, pixilated terrain when viewing from a distance Fixed fog transition so that it should no longer pop into view at 60 km Scaling updates to make KSC signs more uniform. This should improve and prevent distortion in various graphical settings and view distances Adjusted bloom and brightness during daylight hours in the Vehicle Assembly Building Clouds updated to remove linear features that can make them appear unnatural Setting cloud quality to LOW in the graphic settings now renders low quality clouds instead of no clouds Fixed an issue where low-quality settings could cause some cloud shadows to appear on vessels above the cloud heights Fixed bug preventing decals from rendering at KSC while moving between loading screens and game states where KSC is disabled Fixed a bug where water (and some other visuals) were not displayed properly when observed through gaps in parachutes Fixed a bug that caused water to reflect the galaxy sky map instead of the atmosphere/planet sky Minor lighting fix in the Training Center Minor collision updates for the VAB roof Flight & Map Fixed deletion of vessels without control during game save Recovered Kerbals are accessible again from the VAB Maneuver plans are now constrained by available fuel and will no longer provide false projections that extend beyond vehicle's capacity. R.A.P.I.E.R. engines must be set to Closed Cycle mode to allow accurate orbital maneuver planning. Stopped light parts from consuming EC after they are switched off Fixed parts attached to some physicsless parts falling at launch Fixed spacebar sometimes not triggering staging Improved fuel flow priorities Improved handling of hover and click targets in Map view when multiple objects overlap Removed the "Disable Crash Damage" difficulty setting. This setting could cause issues preventing vessels from entering a landed state. If crash damage was disabled in playthroughs, it will now be enabled Burn timer status icons are now accurate when the burn is completed at the correct time Fixed issue where engines in Part Manager displayed incorrect "Deactivate" or "Activate" state Fixed issue preventing switching between vehicles in atmospheric flight. This is now possible as long as both vehicles are inside the high-fidelity physics bubble surrounding the observer Fixed a bug that can cause certain vessel configurations to be destroyed at frame of reference updates in flight Fixed a bug that caused uncontrolled vessels to be tagged as debris in certain scenarios Fixed collision detection in map mode for trajectories with impacts on Bop. Collision icons should now be displayed map trajectories for Bop Fixed CommNet partial/no connection after decoupling/undocking a probe Fixed a bug that could cause trajectory lines to incorrectly display as a non-closed orbit/escape trajectory. Fixed a bug that could cause highlight dot markers to appear on some vessel joint connectors in flight Fixed a bug that caused main menu screen elements to persist into gameplay Fixed a bug to prevent some abrupt Kerbal animation changes Fixed an issue with jet engines that could cause the wrong engine mode to be selected. Fixed a bug where Tim C. Kerman's hair could clip through his helmet FX and Audio Vacuum exhaust updates for the R.A.P.I.E.R. engine Updates to the timing on the plant flag EVA animation Updates to the sphere of influence entry and exit VFX Tim C. Kerman now has appropriate RCS thruster VFX Removed "out of fuel" sound from Sepratrons Fixed Tracking Station audio cue firing too often Improved trailing particle emitters to reduce VFX bugs associated with frame of reference changes Fixed jet engine audio starting/stopping too quickly when engines were deactivated/re-activated in the part manager Fixed an edge case where jet engines could show engine start VFX during timewarp Fixed Terrier engine exhaust scaling Localization Improved translations in several video subtitles Updated localized terms for new game creation (all languages). Fixed various localization issues in the part manager for Pods, Coupling, Fuel Tanks, Engines, and Utility (all languages). Fixed missing text in some scenarios where actions cannot be performed yet due to loading (all languages). Fixed a bug that could cause the End User License Agreement, Terms of Service, and Privacy Policy text to remain in the previous language after languages are changed in game. Fixed mislabeled EVA keybindings in the settings menu (all languages). Localized text updates in the settings menu (Polish, Russian, German and Korean). Tutorial updates for all languages Fixed localization issues for Part Picker, UI, and Settings Updated font atlases to properly display special characters Fixed unlocalized text in the open workspace window Improved font fallbacks to avoid different size characters Translation updates for "Statistics" in the part info (all languages) Menu text updates (all languages) Part manager/info text updates (all languages) Fixed missing text on the KR4-P3 reactor (All languages) Stock vessel text updates (Portuguese) Updated loading tips in the (Chinese languages) Fixed a text formatting issue in the Training Center (Italian, French, German, Japanese) Save data font adjustments (Korean) Fixed a minor language issue, where the confirmation box was displayed in the previous language after making a language change in settings Optimization Fixed a memory leak in tutorials Changed Kerbal Crew Cam to paginated format Optimized cubemap rendering to reduce memory usage and improve CPU performance Optimized memory usage for clouds and corrected issue in which clouds on some Celestial Bodies did not match quality settings Reduced GPU memory usage for surface scatter meshes (especially grass) by scaling render buffers to currently visible content Applied CPU optimization to SetPixel behavior Deactivated underwater state detection when flight camera not active PQS disabled when flight camera is not active Optimized memory usage of tree scatter by reducing texture duplication Implemented Ground Shading Quality settings Anti-tile is now disabled when low quality is selected Improved cloud memory usage Performance improvements when using vessel configurations with lots of resource sources Optimization on Kerbal IVA cameras Improved low graphical setting visuals in some scenes Additional flight camera optimization Optimized orbital nodes in map by not processing non-visible ones Optimized and Improved KSC night lighting Fixed memory leak in terrain code Fixed bug preventing instanced runway light levels of detail from being rendered. Also fixed memory leak due to accumulated rendering calls associated with runway light levels of detail Fixed bug where game loaded in an unresponsive state due to issue with modification of master texture limit while texture mipmap streaming is running Parts and Stock Vessels Kerbals in passenger modules now have IVA portraits and can exit the vessel Aeris stock vehicle is now oriented horizontally by default Optimized geometry and updated textures for the Mk2 "Phoenix" Reliant engine small model updates. Swivel engine small model updates Fixed misaligned attach points on the Mk2 Lander. Mk2 Inline Cockpit small model updates The surface attach node visual is now appropriately sized for the Bobus ladder. Removed additional, erroneous attach points from the Mk3 Engine Mount Added missing part sub-name for the FL-T100 Methalox Fuel tank Fixed a value that could cause a flash when loading vessels with procedural wings Fixed a text issue where the incorrect size was displayed for the Clamp-O-Tron Jr. in the part description (all languages) Saving and Loading Camera now returns to saved position and orientation when game is reloaded Proper save names are retained when loaded on another computer Updates to save data for missing camera YAW information Updates to save data information to ensure accuracy of camera information Save data changes for better handling of vessel and agency information Fixed issue where reverting or loading results in disappearance of vehicle Fixed a bug where Kerbals loaded in incorrect locations from a save made while EVA Fixed visual errors associated with the Loading Screen transition when loading a game from the VAB or Training Center. Tutorials The user is now returned to the Training Center after exiting a tutorial instead of KSC Updated tutorial preview images Fixed issue where game progresses too quickly during Tutorial 1.5 Fixed tutorial vessel loading in a player campaign after completing a tutorial Fixed tutorial menus appearing on the main menu UI/UX Updated the frequency of game paused and unpaused messages to help prevent spamming Improved Terms of Service flow, added "Next" button to seizure warning screen, and corrected issue where legal text did not default to system language settings Added ESC button functionality to close screens at the main menu Time warp bar no longer displays when HUD is toggled off using F2 Notifications now persist when game is paused to make them easier to read Fixed a bug that made it difficult to close the color manager window Staging stack resource readouts containing two different resources now display correct amounts for both entries Corrected various errors in Credits Updated styling for the Burn Timer window Reduced scroll wheel sensitivity for menus, including Language Selection, Launchpad, and Save/Load dialogs Removed non-functional Filter/Overlay button from Tracking Station Added "Return to KSC" button to Flight Report and Tracking Station dialogs Font and styling fixes to save dialogue windows Minor scaling improvements in the part information overlay window Limit on passive notifications that can be displayed at once (three) The color picker window is now moveable via click/hold/drag on the top of the window Update to Kerbal manager and Resource manager icons Updating active icon visibility for the wing editor UI when editing procedural wings UI updates to the location bar at the top of the screen The staging stack is now hidden when there are no stages present in the VAB The expand/collapse stages button is hidden when only one stage is present (which will have it's fully details displayed as fully expanded automatically) Fixed engine part manager status text Fixed bug where player could not select "Filter Options" in Tracking Station Fixed a bug with save data sort by date orders Fixed an issue that could cause some UI menu's to not respond to a mouse scrollwheel Fixed a bug with the current location menu reading the wrong location in some instances after exiting the Training Center Fixed an issue in the load workspace menu that could cause multiple workspaces to be highlighted at once Fixed a bug that would cause the timewarp bar to disappear in the tracking station Fixed an issue causing the scrollbar to not appear in the resource manager when a vessel had a large part count Fixed object picker sometimes not expanding initially in the tracking station Fixed buttons cut off in the Tracking Station Fixed UI issue where toggle button width and campaign menu difficulty level button width were not expanding with text content Fixed bug where the only ship name visible on the KSC Launch Pad UI was the last ship sent to the launchpad Fixed issue in which temperature gauges persist on screen after they have been turned off in Settings Fixed issue where game switches to Fullscreen upon entering the Graphics tab in Settings Other Removed Kapybaras 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 Forums Join us on Discord to discuss potential changes Bug reports should be shared to either: Private Division Customer Support Dedicated Bug Reports Subforum

Hello Kapynauts! It's been in the works for months but we're finally excited to share some news about the new direction we'll be taking KSP2. Due to overwhelming feedback, the team has decided to swap out a core fundamental piece of the gameplay experience with a new fuzzy one. Moving forward, Kerbals will no longer be the main characters of our game - and instead we'd like to introduce you to our new quadrupedal friends: KAPYBARAS! KSP2 will now be known as Kapybara Space Program 2. Detailed below are a host of new features and changes to the game that we're absolutely sure the community is going to love. Welcome to the rebranded world of Kapybara Space Program, where our favorite furry friends embark on an epic journey through the cosmos, driven by their unending obsession with cheese and melons. The Kapybara Space Program Universe In Kapybara Space Program, players take control of the Kapybara Space Agency, a group of ambitious rotund rodents determined to explore the Kapolar system and beyond in search of the finest cheese and sweetest melons. The game retains the core mechanics of the original Kerbal Space Program, such as building spacecraft, managing resources, and planning missions. However, the addition of Kapybaras and their culinary quests inject a delightful twist, adding a fresh layer of fun to our already engaging gameplay. Redesigned from the Ground Up Many features and parts in Kapybara Space Program have been redesigned to accommodate the furry rotund figure of the Kapybaras. Our artists and engineers have spent a lot of time rethinking everything from core pillars of gameplay to the smallest of features. Below is an early sketch and some final concept art which should be similar to what you finally see in game: Additional smaller changes: Please keep in mind that Kapybaras do not have opposable thumbs, so controls may be affected by these changes. Command Modules have been updated to accommodate four legged fuzzy bodies such as bucket seats and larger buttons and switches. Added refrigerated melon and cheese storage Added bathtubs Adjusted levers so you can only pull up Tightened up the graphics on level three. Changes to our Early Access Roadmap As you can see, our team has worked hard to revamp the entirety of KSP2 to include our new main characters. In fact, we've even looked ahead in Early Access as well: In addition to science resource gathering and tech tree progression, the Science Update will now allow you to dive deep into Kapybara Culinary Arts for assist you with the new KapyLife Support feature! By collecting fine delicacies and using our in-game UI to design the most exquisite charcuterie boards, you can ensure that your Kapybara crew has enough food to sustain them during their arduous journeys amongst the stars. The Colonies Update will now also feature colorful pipes for transversal across the colony for the fuzzy little kapys. Enjoy building colorful tunnel mazes and brightly designed colonies on any celestial body in the Kapolar system! Once we make the jump to the Interstellar Update, new challenges and milestones for players to conquer will be added. Completing these milestones rewards players with new technologies, materials, and resources, enabling them to build more advanced spacecraft and explore even deeper into the cosmos. The ultimate goal? To find the legendary Cosmic Cheese and Infinite Melon, believed to grant Kapybaras eternal happiness and satisfaction. Looking to dig deep into the Kapybaras' past though? The Exploration Update will allow you to turn your focus back to Kapybin with our new archaeology feature! New parts will allow you to build new excavation crafts so you can discover the mysteries below the surface of the Kapybara homeworld and beyond! Lastly, the Multiplayer Update will introduce something we're super excited about: hat-making. Stand out from the rest of your crew by giving your Kapybaras the most fabulous hats. This will tie back to Science and Archaeology as well, as you'll only be able to find the rarest hat patterns by finishing archaeology projects on non-Kerbin celestial bodies! Hat Rarities: Common - Ball Cap Rare - Fedora Epic - Chef Hat Legendary - Fez (they're cool) Kapybara Film We have yet to share details about our plans after the 1.0 release but we're happy to announce today that at that point a large portion of our team will be shifting focus to make a Kapybara Space Program movie featuring motion capture from our community managers, and squeaky voice-acting from our engineers. We don't have any other details to share at this time, but we're so excited to bring the Kapybaras to the silver-screen sometime in 2048! Kapybara Merch To support the development of Kapybara Space Program 2, we'll be bringing you all limited-time drops of Kapybara-focused merch including new flags, plushies, and more! Stay tuned for more information on these exciting new collectables! A New Challenge In anticipation of these sweeping changes, we challenge you to create your own Capybara Craft! Primary: Design and launch a capybara into orbit. Stretch: Design and launch a capybara and land on the Mun Keb Level: Design a capybara rover and take it for a spin Kal Level: Build a capybara with the Cosmic Cheese and Infinite Melon Conclusion Thank you all for joining us on this exciting new direction that we're taking KSP2. We hope you have enjoyed this insight into our future plans and we'll be sure to share more information as things are finalized. Hope you're all looking forward to guiding your Kapybara crew into the stars in search of the universe's most delicious treasures. <3 Intercept Games

KSP2 Update v0.1.1.0 Release Notes <-- This rocket denotes a fix that community members directly helped our dev team fix. Thanks to all of you who send in bug reports! Bug Fixes Flight & Map Fixed disappearance of orbital trajectories after loading a saved game Fixed trajectory intercept patch not showing when captured by a Celestial Body Fixed issue where some parts remain connected to/follow vessel after detachment Fixed stack decouplers staying connected to the vessel when staged with certain engines that have fairings enabled Fixed physics impulse occurring when an engine runs out of fuel Fixed dV incorrectly using reinforced joint part connections for fuel flow calculations Fix for engine thrust being deflected at too high of a value when a part obstructs an engine’s exhaust (the Kraken Drive bug) Fixed loss of vehicle control after undocking Fixed bug for probe cores spinning when losing Commnet connection Fixed stack decouplers operating as if crossfeed is active even when PAM entry shows crossfeed disabled Fixed issue that could cause some environment objects to spawn on top of the active vessel, causing KSC and other objects to move to the origin Fixed orbital velocity being shown when looking at the context menu of a landed vessel in Map view Fixed maneuver burn timer countdown lights activating incorrectly Fixed context menu opening when panning the camera with right mouse button while zoomed in to a celestial body in Map mode Added camera collision with terrain and other colliders while in Flight view Added visual indicator when a marker is hovered and pinned in Map view Fixed offset of radially-attached parts when player switches away from and back to Flight view Fixed the sim-side Center of Mass not being correctly updated by view-side rigidbodies Fixed physics-less parts adding the mass of their host part to Center of Mass calculations Fixed orbit/rigidbody synchronization issues when transitioning to/from physics and on-rails Made debris targetable Fixed dV calculation breaking when new empty stages are added while building a vessel in the VAB Fixed dV amounts appearing on the wrong stage when rearranging stages in the staging stack Fixed outboard elements of compound wings exhibiting reversed control surface reaction to pitch inputs Fixed issue with orbital marker not properly resetting its state when collapsed Fixed orbital markers not being pinnable while manipulating a maneuver and not staying pinned upon maneuver gizmo activation Fixed navball/controls getting stuck after accelerating in timewarp Fixed persistence of active vessel’s timewarp restrictions when returning to KSC from Flight Fixed pitch, yaw, roll, and throttle adjustment being possible while in hibernation mode Fixed planned trajectories changing when switching between Flight view and Map view while engine is firing Fixed dV calculations for stages with multiple engines with different burn durations and propellant rates Fixed resource system processing when request needs are only partially met Improved buoyancy calculations to reduce vessel spinning when splashing down in the ocean Fixed burn duration displays 0 until it is time to start the burn Fixed ETA to maneuver display to show a value for “days” Fixed dV calculations with cross feed in active stage of flying vessel Fixed dV changing to zero when fuel crossfeed is disabled on Docking Ports Fixed a bug where debris trajectories were not immediately shown in Map view Fixed a bug with thrust limiters missing for solid fuel booster engines Removed incorrect fuel transferability for solid fuel parts in the Resource Manager in Flight view Single part vessels now come to a stop on low gravity celestial bodies after a crash Fixed intercept nodes being in wrong positions during timewarp Updated detection arguments for recognizing when an aircraft is landed Fixed an issue with Stability Assist that could cause the loss of Prograde and Retrograde targets on the launchpad. Fixed vessel not restoring correctly when reverting to launch from the runway Fixed Chase Camera mode to make selected zoom state persist Fixed part action groups breaking when an invalid action is included Fixed errors on Game Shutdown during TimeWarp Fixed destroy command not destroying vessels in the Tracking Station Fixed some instances where the action group manager would not trigger correctly when additional part actions are added to reserved action groups Optimizations Optimizations in the engine part module to reduce per-update “not out of fuel” messaging Optimized engine exhaust damage calculations to reduce CPU impact of high engine counts Optimized ThrottleVFXManager to reduce CPU impact of per-frame material property updates Optimizations on EVA code Optimized Center of Thrust and Center of Mass marker code and fixed null shortcut failure states Optimized kerbal hair compression scripts Optimized loading times in PQS code Optimization of unneeded cameras during loading Optimized loading times for the main menu Loading optimization for scatter meshes Optimized fuel flow calculations to cut processing by up to 3x and reduce garbage by half Optimized runway light meshes Fixed various texture and mesh memory leaks Updated Training Center to use texture streaming Fixed performance-impacting error state triggered by Kerbin’s clouds after returning to Kerbal Space Center from another celestial body Removed unnecessary log entries to improve performance Removed unnecessary logs when loading a saved game Reduced light source count for multi-nozzle engine parts Saving & Loading Added feature: game autosaves when landing on a celestial body, when entering an SOI, and when entering or exiting an atmosphere Fixed an issue that prevented loading of a saved game within an existing Campaign, caused workspaces not to load properly, and prevented saving the game Fixed issue where reloading a save made at KSC results in reloading to active vessel in flight Fixed string in the Save Workspace menu Fixed an issue that could prevent new workspace saves being created when a control part was removed Fixed an issue that can prevent workspace saves from appearing in the load menu Parts & Stock Vessels Fixed R.A.P.I.E.R. engine mode-changing issues Set all reinforced joint connections to grandparent Improved joint strength for engine plate floating stack attach nodes Performed wheel balance pass, including adjustment of all steering and torque curves Increased range and brightness for vehicle lights Re-tuned fairing and cargo part mass Tuned mass for structural parts, trusses, nosecones and tail sections Tuned crash tolerance for external Grumble Seat Re-tuned electrical systems, including adjustments to xenon engine electrical draw, xenon engine thrust, reactor fuel burn rate, and RTG lifetime Tuned crash tolerance for landing gear Tuned docking reacquisition ranges Updated Hammer solid fuel booster model to match with other parts in the same size category Adjusted mass for HECS2 probe Updated emissive texture and material for the MK3 “Skybus” Fixed frustum culling for the Bobus mobility enhancer (ladder disappeared when base at edge of screen) Updated geometry and textures for the MK1 “Peregrine” Updates to textures and geometry for the Mk1 “Raven” Fixed texture seams on the R.A.P.I.E.R. engine Fixed RCS not working on the Mk3-5 command pod Minor bug fix on the Kerbal K2 stock vessel to fix issues with decoupling Updated collider for MK1 Tin Can to improve surface attachment behavior for radially-attached parts Updated default orientation for some adapter parts Updated default orientation for small square trusses Updated part placement rules for the HS-500 Heat Shield Updated models for decouplers and separators to match other parts in their size categories Updated geometry for LV-N “NERV” engine Updated team colors masks for the SP-XL "Gigantor" and SP-XXL "Colossus" solar panels Updated team color masks for decouplers Updated team color mask on engine endcaps Added Crew Light module to Skybus cab Fixed the Symmetry mirror direction and rotation for the Grumble Seat Fixed wheel motor resource usage being too low Adjusted default orientation of the MK3 Cargo Ramp Fixed fuel-containing aerodynamic parts (Mk1 Divertless Supersonic Intake, Engine Nacelle, or Engine Precooler) not showing resource slider in the Part Action Manager Tuning changes made to reaction wheels in command modules Adjusted the surface attach node to be on the ventral surface of Mk2 parts Fixed a bug preventing lights from consuming resources Fixed a bug preventing the Blink option from working on lights Fixed a bug with the heading orientation of the Sparrow default craft UI/UX UI performance improvements, including elimination of unnecessary redraw for unchanged bar elements and removal of pixel perfect on main gameplay canvas Added a graphical representation for probe cores in Kerbal Flight portraits Updated Map iconography, including orbital markers, trajectory colors, maneuver gizmo, focus item, and scrub handle Fixed error where clicking on “Exit” in Main Menu produces warning modal that has no accept or cancel buttons Fixed graphics quality settings conflicting with one another after resetting settings Removed “Apply” button from settings menus, updating settings when changed, settings now apply immediately Fixed parts bin UI height in Staging Stack Performed color and consistency pass on the staging stack and launch button UI UI improvements to avoid overlap of intercept nodes in map view Fixed info panel UI element remaining active when panel is hidden in the Tracking Station Updated UI indicators in some tutorials and first time user experience information Updated Resource Manager UI to match new resource gauges in Staging Stack Improved ESC menu user experience Fixed dark box getting stuck in the VAB when dragging the dialog window Fixed Kerbal Manager portraits appearing empty Fixed non-stock vessel thumbnails not appearing in launchpad menu Minor updates to improve building selection experience at Kerbal Space Center view Updated the executable icon Updated background image for vessel thumbnails in the launchpad load menu Updated saved vessel thumbnail design Updated styling on the action button inside the Part Action Manager Updated the game credits Updated game splashscreens Updated titles in the Resource Manager Updated dialog windows to accommodate longer text Updated close button on the Part Manager Updated missing text on the launchpad menu Added notification for inactive vessel entering a new SOI Fixed runway 1 and 2 having the same name when hovering over them in the KSC Fixed tooltips for Trigger Action Groups 2-10 being numbered incorrectly within the input settings menu Fixed Center Camera in VAB being in the wrong section in the input settings Added warning when rebinding the same key twice in input settings Fixed difficulty settings being saved from one save file's difficulty settings and being applied to every normal difficulty game save made afterwards Fixed difficulty options showing in the main menu settings Fixed failure of difficulty settings to apply when changed inside a campaign Fixed shader compiler error when switching graphics settings to Low Quality Added laptop audio mode to settings Fixed a bug where the “hold to quickload” setting was not applied correctly Added audio keyboard shortcuts to input settings menu Fixed escape menu freezing vessel controls in last-held state Fixed dialog being non-clickable when recovering a vessel with ESC menu deployed Fixed overlapping text in the flag removal dialog Fixed throttle visuals not updating when throttle adjusted Updated Tracking Station control text Minor updates to global header information Fixed Recover Vessel button in the ESC menu pushing elements off screen Fixed notifications using real world time instead of UT Fixed input lock problems when the ESC menu is visible Removed placeholder image that appears when no parts are favorited Updated Center of Mass, Thrust, and Pressure/Lift indicators in the Vehicle Assembly Building to make them translucent Fixed text overruns in the Training Center Alt+Enter toggles fullscreen Fixed a bug blocking some agency flags from being selected when starting a new game Added additional loading screens Fixed missing physical characteristics in the info panel inside the Tracking Station Fixed issues with the toggles for Map and Tracking Station displaying an incorrect state, or being hidden unintentionally Fixed all CBs are described as "Terrestrial planets" when viewed in the tracking station Updated the text string displayed for engine disabling/enabling in the Part Manager Updated text for lights in the Part Manager Construction Middle mouse button pans in the Z axis when in horizontal workspace mode Fixed fairing sides getting deleted after building a procedural fairing and attaching it to a launch assembly Fixed errors related to procedural wings preventing launch from VAB Fixed issue where pressing M in the VAB opens the Map view Fixed description for Kerbol capture and Kerbosationary orbit trip stages in trip planner Fixed engineer’s report warning vessels cannot generate electricity when vessels are equipped with generators Adjusted default VAB camera angle for horizontal workspace mode Fixed hit area for the launchpad selection button in the VAB Confirmation prompt added when saving over workspaces Fixed assembly anchor error alert persisting onscreen and blocking the user from placing additional parts after the tool is deselected in the VAB Fixed Center of Thrust appearing on the ground of the VAB and not updating when launch assembly is changed Fixed display issues in the text on the orientation cube in the VAB Updated favorites panel information in the Vehicle Assembly Building Favorites category Fixed a bug where surface attach nodes were misaligned on some engine parts Environments Fixed an issue where ground textures were projected onto vehicles at the margins of the KSC grounds Fixed Kerbin atmosphere disappearing when viewed from Mun’s SOI Fixed collision at bottom of Mohole Fixed terrain decal normals not rendering correctly Reduced scatter meshes floating above terrain Updates to terrain texture matching for some points of interest Updated placement, coloration, and collision for various celestial body landmarks Updated colliders and stretched textures in the parking garage at KSC Scatter adjustments around KSC mountains Updated material on VAB elevators Fixed VAB gantry crane geometry Updated material on VAB doors Adjusted atmosphere settings for main menu background planet Fixed atmosphere not showing in cubemaps under some circumstances Improved atmosphere clipping issues while in Map view Fixed Laythe’s atmosphere rendering incorrectly in Map view Fix a bug that caused lighting to darken on vessels when reentering atmospheres Updated clouds on Jool Minor road line placement adjustments at Kerbal Space Center Fixed collision and updated materials for some points of interest Updated local space shader to restore missing normals in some biomes Updated KSC Training Center roof and Tracking Station dish to fix gaps in geometry Updated colliders around launchpads Updated Kerbin foliage Fixed invisible water above ground to east of KSC lakes Fixed scaled space clouds not displaying in map view Fixed cloud transition dithering issues Improved cloud masking to clean up edges of clouds seen behind vehicle Fixed clouds in Map view not lighting from the correct sun direction for all planets Fixed warnings in cloud-related code Fixed decals sliding and floating on planets Fixed decals getting culled incorrectly after transitioning to low orbit Fixed Laythe's Ocean appearing jagged, pixelated, and jittery after splashing down Fixed ocean shoreline fade out transition at some camera angles Improved LOD transitions for KSC trees Fixed mismatch between high-detail KSC and far-distance LOD material Fixed shadow system to switch to surface shadow mode in KSC view EVA Fixed issue with game saves made after vehicle destruction, in which reloading causes EVA camera mode switch and missing flight information/flight report Fixed kerbals floating when idle while in EVA Fixed kerbals getting stuck when swimming Fixed Kerbals getting stuck inside the Mk1 Command Pod when it's on a flat surface other than the launchpad Improved Kerbal run/walk animation transitions Fixed Kerbal surface velocity resetting when disabling RCS in EVA mode Updated EVA code to remove frame-related discrepancy between collision result values and character state values Fixed ground and step detection being one frame late for kerbals while in EVA Fixed EVA tooltip remaining active when the HUD is hidden during gameplay Fixed inability to recover Kerbals when on EVA Fixed a bug preventing EVA jetpack from firing even when it has enough fuel Kerbals now require 1x timewarp when transitioning to EVA Fixed kerbals being able walk on the sides of objects with collision Fixed climb action not being present for Kelus Long ladder and Bobus Extra Long Telescopic Mobility Enhancer Fixed errors when toggling Jetpack while TimeWarp is active FX & Audio Improved Kerbol flare/bloom effects Fixed post process FX lighting transition in low orbit Fixed an issue where contrails jump positions during universe reference point transitions Fixed ground blast effect occurring at invalid location for the first few seconds of launch Fixed SFX for Panther in afterburning mode Fixed errors on explosion VFX for hydrogen tanks Fixed VFX not showing on RCS thrusters when precision mode is activated Minor updates for non-explosive water impact VFX Launch VFX updates Updated R.A.P.I.E.R. engine VFX Updated launch smoke material Updated explosion materials Fixed audio timing for several animations Game audio balance pass Fixed a bug where audio was muted when entering numpad values in text entry bars on some menus Added maneuver alert and end sounds Added drag and drop staging sounds Added hydrogen and xenon tank destruction sounds Fixed launchpad music not playing when loading a save Tutorials Fixed issue where flight report appears when the user crashes a vessel inside a tutorial Added “Enter” as keyboard input to advance tutorial dialogs Fixed a bug that could cause the first-time user experience windows to remain open on the main menu Text adjustments in tutorials Text adjustments to subtitles for video tutorials Fixed soft lock error when restarting Tutorial 2.2 Fixed some audio elements on tutorial 2.4 Fixed tooltips not displaying in the Tutorial pause menu during tutorial videos Adding scroll bar indicator to the booster selection step in the “Missing the Ground” tutorial Added fail stage when deleting the engine in the “Space is the Place” tutorial Fixed tutorial orientation video getting stuck when clicking at the end of the video progress bar Fixed subtitles in several languages for the video tutorial on the “Space is the place” tutorial Fixed file paths in tutorial saves Minor gameplay updates to the “Missing the Ground” tutorial Updated text in the VAB First Time User Experience Updated first-time user experience: “Out of Electricity” linked to electricity level instead of production rate Fixed a bug with videos not closing at appropriate times Localization Fixed title text overlapping at the Training Center when localized Fixed unlocalized tooltips in the Timewarp bar Added missing localization terms for stockvessels. Localization reformatted for new game creation Adjustments to text sizing and placement in the launchpad selection in some languages Fixed crash when returning to main menu from VAB Font updates for special characters in certain languages Added new translations to: KSC Menu Flight HUD VAB Training Center Launchpad Menu Part Manager Tracking Station Settings ESC Menu Dialog Titles Notifications Action Group Manager Campaign Load Screen Part Action Manager Time Warp UI Tutorial Pause Wing Editor Map View Part Info Tooltip Video tutorials Passive notifications Merging Workspace Tutorial KNOWN ISSUES KSC Runway Lights LOD Visual Regression Description: Players can see runway lights up close, but they are not visible from far away. This was a result of a major optimization fix for the lights. Status: We are aware of this issue and will be looking to address this in a future patch. SUBMITTING BUG REPORTS AND FEEDBACK If you'd like to provide feedback about this build, there are many different ways to do so: Submit Feedback through the Game Launcher Suggest a Change on the Forums Join us on Discord to discuss potential changes Bug reports should be shared to either: Private Division Customer Support Dedicated Bug Reports Subforum

Hi Y’all, I’m Mortoc, the new graphics programmer on the team. I wanted to take some time to chat about KSP2’s graphics and performance – where we are today and what our process is and what the team’s goals are. As many of you have noticed, KSP2’s performance isn’t amazing at the start of Early Access. In a game as complex as KSP2, there are a dizzying number of areas that we could spend our efforts on and the feedback we’re receiving is invaluable for us to focus our time on the issues that affect the players the most. There are different reasons that the framerate can suffer. If the CPU is asked to do too much during simulation or if the CPU is asked to send too much data to the GPU in an organized fashion, it can make the framerate drop without maxing out the GPU. In most cases the performance in KSP2 is bottlenecked by the GPU, and since I'm a graphics engineer, that's what we're going to investigate in this article. Other engineers are working hard on CPU-facing improvements that you'll see reflected in upcoming updates. Deep Dive Warning: Numbers Ahead Before we dig into the numbers, let’s start with a primer on what we’re looking for here. Game developers tend to think of framerate in terms of milliseconds rather than FPS because it’s easier to budget out your frame time that way. Converting from FPS to ms is simple, you just use the formula 1,000 / FPS = ms (for example: 100 FPS means it takes 10ms per frame, 1,000 / 100 = 10). This way we’re talking about how long a system takes to run directly. We want to measure how many milliseconds each system in the game takes in order to figure out which are taking too much time and dropping the framerate. We use a tool called RenderDoc for our automated performance testing (among other tools). RenderDoc allows us to get the ground-truth timings for every single command sent to the GPU. Our tooling can then pull out the slowest GPU events for us to investigate. The machine I’m using here for performance analysis is a laptop with i7-8650U CPU, Mobile Nvidia GTX 1060 6gb GPU and 16gb RAM. It has a slower GPU than our current min spec, so we’re not expecting it to make a playable framerate yet. KSC Landing Screen – 11 FPS 10 Slowest GPU Events Draw # Duration (ms) PQSRENDERTEMP\Draw(229248) 270 6.08 RenderDeferred.GBuffer\Draw(229248) 505 5.84 RenderDeferred.GBuffer\Draw(229248) 506 5.44 CloudCommandBuffer\DrawIndexed(6) 746 4.43 Shadows.RenderJob\Shadows.RenderJobDir\Draw(229248) 652 4.31 GenerateWaterDepthCommand\Draw(229248) 576 3.18 RenderDeferred.GBuffer\Draw(229248) 503 1.72 RenderDeferred.GBuffer\Draw(229248) 504 1.63 Draw(229248) 263 1.62 cloudsShadowCommandBuffer\DrawIndexed(6) 560 1.58 In this scene, eight of the top ten worst-offenders are related to PQS+. PQS stands for Procedural Quad System and it’s the algorithm used to generate planet terrains. KSP2 uses a modified version of PQS from KSP1, generally referred to as PQS+ after all the modifications made to it for KSP2. That table starts with a draw call to PQSRENDERTEMP, which emits 229,248 vertices. Each other draw call that uses that specific number is doing some work on the PQS mesh. The two draw calls not related to PQS in that table are the ones with a 6 in the name and are related to the cloud system. From this report we can see that the terrain clearly takes the most GPU time in this scene; 29.94ms in total. Let’s try another vantage point. LKO – Low Graphics – 8 FPS 10 Slowest GPU Events Draw # Duration (ms) PQSRENDERTEMP\Draw(92160) 237 10.44 RenderDeferred.GBuffer\Draw(92160) 301 4.06 RenderDeferred.GBuffer\Draw(92160) 302 3.14 RenderDeferred.GBuffer\Draw(92160) 304 2.34 Dispatch(12, 240, 1) 1 2.07 RenderDeferred.GBuffer\Draw(92160) 303 1.59 CopyResource(ObserverCubemapView_CubemapFinal, ObserverCubemapView_Temp) 92 0.60 CopyResource(CelestialBodyCubemapView_CubemapFinal, CelestialBodyCubemapView_Temp) 184 0.33 Camera.Render\PQSRENDER_DEFERRED_DECAL_MASK\Draw(92160) 230 0.24 Camera.Render\Draw(92160) 227 0.23 As you travel away from any Celestial Body, we swap out the complex Local shader with a Scaled version that’s much more efficient. This scene is from Low Kerbin Orbit, but still close enough to the planet to be using the Local version of the shader. PQS+ is again 8 out of the top 10 worst calls (the line Dispatch(12, 240, 1) which is Draw Call #1 is from at the start of the frame when we kick off a compute shader to generate the terrain mesh). That first PQS+ call that took over 10ms is especially dirty. Staying Grounded Clearly the PQS System and related shaders are a big performance problem. Let’s talk about that, but first dig into some background. A core philosophy for the early part of KSP2’s EA cycle is to make sure “it still feels like a KSP game”. This means that for each feature we build, we want to start with what KSP1 did and then build a similar system that improves on it. Following that goal, the team started with the PQS design from KSP1 and added modern graphics features for KSP2’s PQS+. As development progressed on KSP2, more and more features were added to PQS+ to keep pushing the artistic envelope. I might be biased, but from orbit, Kerbol’s planets look incredible. Our art team did a fantastic job. From the surface the game is still quite pretty, but the terrain itself just doesn’t have the consistent visual quality we want yet. While trying to build that ground up to our visual ambitions, we added more features than the previous PQS architecture can support. It wasn’t until the ramp up to EA that it became understood just how far past the limits of the tech we had reached. Future Trajectory OK, so, clearly there’s a problem, what are we going to do about it? A few things are being done simultaneously. First, we’re prioritizing performance optimizations for this system over the next couple of patches. Particularly for when graphics settings are “LOW”, we want this system to be eating far less GPU time. This takes two forms: one is pure engineering optimization that doesn’t affect final graphics, the other is to disable certain visual features when the graphics are set to “LOW” or “MEDIUM”. That first category, engineering-only fixes, was taken about as far as it could be with PQS+. Our short-term plans are currently focused on the 2nd category, turning off features that don’t provide enough bang for the buck. Here's an example of an optimization that affects the visuals. Coming soon in a patch, we will be able to turn off the Anti-Tile system in the terrain. In a bunch of places, the effect is negligible, but you can see the Eve surface has a repetitive texture artifact without it. This visual polish comes at the cost of accessing each texture a few more times, putting strain on the memory bandwidth of the GPU. Disabling this effect can have a small-to-medium sized effect on the framerate, depending on the GPU in question. Optimizations like that one are happening now and will arrive in the next few updates. The rest of this article deals with systems that are in progress, so we cannot make specific promises about timelines or features until further along in development. But here’s where we’re heading: In the medium term, my first major project on this team is to design and build a next-generation terrain system – what we’re calling the CBT system (it uses a Concurrent Binary Tree data structure, but it could also stand for Celestial Body Terrain). PQS+ has served us well, but nowadays video cards are much more flexible and there are more modern approaches that will give us better results in terms of performance and visual quality. Exciting new earth-shaking architectures are possible. The next-gen CBT system will be the topic of a future dev blog which will contain a much more detailed look at what we’re building. While it’s too early to share any details, I will say that I’m excited about the artistic expressiveness, potential terrain variety, and performance of the CBT system. Another area that will see a major shift in visual quality and performance is bringing the game up to Unity’s modern renderer, HDRP (read more about HDRP here if you’re curious, it rocks). The main benefits we get from HDRP are a more optimized render engine, which means faster framerates, and a more flexible shader model, which means more effective dev team efforts. It’ll also make it easier for visual mods to be built. As a sidenote, despite how much we love you modders, this change will definitely break most visual mods (sorry modders, sometimes we must hurt the ones we love). These in-progress changes will allow us to build more scientifically grounded yet fantastical worlds for the Kerbals to explore for years to come.

Will the KSP2 OST be available? As soon as Howard Mostrom completes the score for the game, we'll take a look at our options for collecting and sharing it with the community.

What does being in Early Access mean? Releasing the game via Early Access gives us an opportunity to validate assumptions about how our features will work while those features are still in development. The long-term quality of the game benefits greatly from this process, as it allows us to focus our efforts on improving what works and saves us from wasting time optimizing systems that don’t perform well under real-world conditions.

Thank you to everybody who participated in last week’s inaugural KSP2 weekly challenge. The KSP2_challenges discord channel has received almost 1700 posts, and our team has had endless fun following all your amazing achievements - from first-time Mun landings to multi-vehicle, multi-destination flights that touched down on Eeloo! We’ve loved them all, but we’re especially proud of how supportive this community continues to be of new players who are figuring out orbital mechanics for the first time. This week’s prompt: create an Air Launch to Orbit Rocket — that is, a rocket that’s launched from an aircraft! · Primary goal: get an air-launched rocket to low Kerbin orbit · Stretch goal: land an air-launched rocket on the Mun. · Jeb-level goal: land an air-launched rocket on Duna. · Val-level goal: launch an air-launched rocket from Laythe and land on Kerbin.

Are you optimizing for performance? Improved performance is a core goal for KSP2, and as each feature stabilizes, we are focusing on making it faster and more efficient. As updates occur over the course of Early Access, you can expect performance improvements across the game.

Can I play KSP 2 offline? Yes!