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

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

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

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

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

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

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

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

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

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

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

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

If you'd like to provide feedback about this build, there are many different ways to do so:
Submit Feedback through the Game Launcher
Suggest a Change on the KSP Forums
Join us on Discord to Discuss Potential Changes

Bug reports should be shared to either:
Private Division Customer Support (for game-breaking bugs)
Dedicated Bug Reports on the KSP Subforum

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

Good afternoon, fellow Kerbonauts.

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

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

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

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

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

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

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

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


For an HD render, check it out here.

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

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


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


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


Congratulations to all who conquered this one!

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

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

Cheers!

---

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

Hello everyone!

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

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

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

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


Drag cube renderings for the Size M conical command pod.

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

Drag cube data for the Size M conical command pod.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

More live occlusion values.

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

Drag Cube areas for the Size S decoupler.

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

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

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

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

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

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

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

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

---

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

Hello fellow Kerbonauts!

The Intercept Games office is buzzing with activity as we submit our last check-ins for the upcoming v0.1.3.0 update and QA puts all the changes through their paces. We're currently aiming for a June 20th update, but as usual I'll hedge a bit by pointing out that QA always makes the final determination about whether the final build is release-ready. As we near that date, we should have more confidence about release timing as well as more details on exactly what fixes and changes will be present in the update. As always, we'll share detailed patch notes when the update goes live.

We have seen movement on most of the items in our top 10 list this week! It's very exciting:

1. Vehicles in stable coasting orbits sometimes experience orbit instability/decay - Status: fix in progress

• We've figured out what's going on here: when an orbiting vehicle is not under on-rails time warp, the effects of minor joint fluctuations within the vehicle rigidbody cause tiny-but-cumulatively significant changes to the vehicle's velocity. The outcome of this is that orbital parameters can change due to all of this subtle wiggling. A system is now being crafted to prevent orbital velocity changes when a vehicle is not under thrust. This change will likely not make it into the v0.1.3.0 update, but we know what's wrong and the steps to fixing it are well understood.

2. Trajectories change when vehicles cross SOI boundaries - Status: fix in progress

• Engineers believe they understand the cause of this issue and are working on a comprehensive solution. This fix will, most likely, not be complete before the v0.1.3.0 update.

3. Certain inline parts cause aerodynamic drag numbers to spike - Status: fix being tested

• Next week, Chris Adderley will be posting a dev blog entry describing the aero occlusion saga. It's a doozy. The fix is in and being tested by QA. We believe it is solid for v0.1.3.0.

4. Returning to craft from VAB causes craft to go underground (possibly related to Kerbals and landed vehicles dropping through terrain while being approached) - Status: multiple fixes being tested

• This was actually two unrelated bugs, but happily we have submitted fixes for both of them and they're both looking good for v0.1.3.0.

5. Decoupling and/or undocking events result in various issues including loss of control, incorrect controllability of decoupled subassemblies, loss of camera focus, and other issues - Status: may have many causes, but some fixes in progress

• This bug describes a nebulous family of bugs that have one thing in common: decoupling sometimes causes weird things to happen, and sometimes those weird things result in loss of control or other flight-killing outcomes. Our engineers have submitted six separate changes that address an array of decoupling-related issues, and they’re all being tested right now. These will be broken down in detail when we release patch notes for v0.1.3.0, but it’s a good bet that some edge case issues will still persist after the update. This is an area where public information submitted to the Bug Reports subforum can help shine a light on player stories that may be difficult for us to replicate internally.

6. Save files get bigger over time (TravelLog experiencing "landed" status spam) - Status: fix being tested

• We are cautiously optimistic that this fix has eliminated the runaway file size issue. It is being tested for inclusion in v0.1.3.0.

7. Opening part manager causes major frame lag - Status: experiments ongoing

• We've been working on this issue from different angles for quite a while, with varying results. Currently, engineer Patrick DeVarney is working on a method of invoking entries within the part manager on an as-needed basis, rather than always loading all part attributes simultaneously on PAM deployment. This fix will not make it into v0.1.3.0, but if the experiment bears fruit in the future it will have significant impact on PAM deployment lag. We’re all rooting for you, Patrick!

8. Major post-liftoff frame rate lag immediately above launchpad (associated with engine exhaust lighting) - Status: fix being tested

• As we said last week, the short-term remedy for this issue was to turn off shadow casting for point lights associated with engine exhaust. We’ll likely revisit this once we’ve got other performance-impacting issues sorted out.

9. Root parts placed below decouplers cause issues with stage separation - Status: fix being tested

• This is actually related to bug 5, and relates to engine plates being the root part. It has been fixed and is in QA review.

10. Vehicle joints unusually wobbly, some part connections unusually weak - Status: under investigation, some fixes in progress

• We are testing a fix for one of the most irksome manifestations of this issue, and I’ll elaborate below...

One of the trending bugs on the Bug Reports subforum relates to wings spontaneously popping off of vehicles. This phenomenon is exacerbated by wings in KSP2 being lard, unitary parts with a single connection point - a situation that was less problematic in KSP1, where wing stresses were spread out across a large number of parts and joints. You may have been aware that for some inline stack nodes, we automatically apply a trio of additional joints to increase the rigidity of the connection. Engineer Jamie Leighton has implemented a new system that applies a similar multi-joint reinforcement to wing roots, and does so in a way that is physically correct. Now, the surface attach node of a wing element is augmented by additional joints that are placed linearly along the wing’s root, and the distance between those joints is controlled by the length of the wing’s root. Check it out:


Purple circles show the positions of wing root joint reinforcements.

This fix is being tested and is slated for release in the v0.1.3.0 update.

There are lots of other bugs going down this week as we’ve entered the cherry-picking process going into the final stretch on v0.1.3.0. It's important to keep in mind that while we've been focusing on sharing our progress on top community issues in these dev updates, a lot of work has been done to solve a lot of lesser-known issues as well. We’ve fixed the issue with not being able to rename vehicles in the tracking station, for example. We also think we’ve knocked out an inertia tensor bug that was causing radial decouplers to eject with inconsistent force directions and magnitudes (and messing up our Korolev Crosses).

While we’ve knocked out quite a few big bugs over the past couple of months, there’s still plenty of work to do. We’re hoping that this upcoming update makes a big dent in some of the most frustrating issues you’ve been encountering, but we don’t intend to let up at all in our pursuit of the remaining bugs and performance issues standing in the way of a stable, reliably performant gameplay experience. Our bug-hunting momentum is good and morale is high.

I mentioned last week that Dakota and the Community Team were continuing to add new functionality to the Bug Reports subforum on the KSP Forums. You can now upvote issues that you have encountered, add additional information to existing bugs (especially handy to the devs when a bug is caused by a weird or complex edge case - for example, it’s already been instrumental in helping us to track down a VAB "not enough resources" issue), and see the list sorted by prevalence. This will give our team an up-to-date view of the community’s most requested fixes. After the v0.1.3.0 update goes out, our hope is that both we and the community can get a faster and clearer picture of community priorities via this subforum. Check it out and let us know what you think!

Last week's challenge produced some very clever Gilly landers dockers, and some very original low-gravity rovers.

How about this space dualie by Socraticrat?


Or this incredible lander by ChaddingtonDuck:


In addition to celebrating all the challenge-inspired community creations over the past week, we also posted a Player Highlight calling out Coriolis, one of our most prolific vehicle builders. We've been enjoying their creations for a long time, and we can't wait to see what they come up with next!

Another Coriolis masterpiece.

This week, we're challenging you to make bases! Sure, you can land in a cool spot, but can you land other stuff near the same spot to make an off-planet village? We'll have colonies one day, but that's no reason not to do some early scouting for the best camping spots!

Good luck, space campers!

---

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

Good afternoon, Kerbonauts!

This week, we're working on many of the same bugs we were working on last week (one aspect of our increased transparency is likely to be that you get to share in the joy of waiting for the oven to go "ding"). We did see some encouraging movement on a few items, but I'll keep the original ten bugs on the list until we've got bona fide QA sign-off on them.

For most of this list, investigation and/or testing is ongoing. Areas that saw significant change have been marked in bold:

1. Vehicles in stable coasting orbits sometimes experience orbit instability/decay - Status: possible fix in progress
   
2. Trajectories change when vehicles cross SOI boundaries - Status: fix in progress
   
3. Certain inline parts cause aerodynamic drag numbers to spike - Status: fix being tested
   
4. Returning to craft from VAB causes craft to go underground (possibly related to Kerbals and landed vehicles dropping through terrain while being approached) - Status: possible fix being tested
   
5. Decoupling events result in various issues including loss of control, incorrect controllability of decoupled subassemblies, loss of camera focus, and other issues - Status: may have many causes, but some fixes in progress
   
6. Save files get bigger over time (TravelLog experiencing "landed" status spam) - Status: fix being tested
   
7. Opening part manager causes major frame lag - Status: experiments ongoing
   
8. Major post-liftoff frame rate lag immediately above launchpad (associated with engine exhaust lighting) - Status: fix being tested
   
9. Root parts placed below decouplers cause issues with stage separation - Status: under investigation
   
10. Vehicle joints unusually wobbly, some part connections unusually weak - Status: under investigation

Issue 2: Trajectories change when vehicles cross SOI boundaries

We have three engineers looking at this and we have already ferreted out a couple of issues - the introduction of axial tilt to KSP2 introduced some discrepancies, and our SOI transit handoff math had some inconsistencies as well. A few other issues surfaced in the simulation code, and we're assessing both the impact of those issues and the scope of work required to correct them.

Issue 3: Certain inline parts cause aerodynamic drag numbers to spike

This bug is the one that saw the most movement this week. Our investigation of the spiking drag numbers revealed that we had a problem with drag occlusion. There is special code that reduces the frontal drag impact of a part that is blocked by another part, and in some cases we were seeing inline parts behave as though they weren't shielded from airflow at all. In some cases, we were also seeing the opposite - wide parts that should have been creating drag were not having their frontal drag assessed at all. Of course, this latter case would rarely register as a problem, whereas the initial problem manifested in all sorts of unpleasant ways - essentially, parts positioned aft of other problem parts behaved like airbrakes, affecting both the overall drag and stability of the vehicle. Even weirder, these drag occlusion issues only arose when a vehicle was built horizontally!

This problem has been corrected. In fact, it’s been SO corrected that after we fixed it, we started to get messages from QA that aircraft felt too fast! We checked the numbers, and they’re correct. We’re still testing this fix, but it’s looking very good for the upcoming update. The details of how this problem was analyzed and corrected would make a very interesting dev diary from Chris Adderley, if he ever gets a few moments to spare.

Issue 8: Major post-liftoff frame rate lag immediately above launchpad (associated with engine exhaust lighting)

Quick clarification: engines had previously each spawned a point light that cast shadows. While this was very pretty, it wasn’t great for performance (and this impact was increasingly pronounced at high engine counts). We have turned off shadow casting for those lights and are seeing an improvement in framerate near the launchpad.

I also mentioned last week that we were exploring ways of communicating our current priorities more clearly, as well as giving members of the community more agency to communicate their own experiences and priorities to us. With that in mind, Dakota Callahan and the Community Team have begun to make some changes to the Suggestions and Development subforum on the KSP2 Forums. We’ll get into more detail about our specific implementation next week, but Dakota has already shown some of his work in that subforum - he’s taking several steps, including creating a new Bug Hunter member role, reformatting threads so that they can be up-/down-voted (this is just for bug threads), adding recommended tags/prefixes, and setting up a system that allows administrators to combine duplicate issues. This will start as a pilot program, and its success will hinge on how useful the community finds it and how maintainable our team finds it. The best possible outcome would be that players use the subforum to surface the issues they find most pressing, and our devs have the ability to ask directly for additional context. Again, I’ll provide more detail about this new structure when it’s fully in place, but in the meantime check out Dakota’s post - he’s got some great ideas!

After posting footage of the three new deep space methalox engines that will be arriving in update v.0.1.3.0, we’ve been asked by a few people what those engines can really do. Our Lead Producer Nestor Gomez (of KSP1 fame) suggested that we share some stats in the time-honored old-school way - with cool blueprint-style graphics! Without further ado, here are the three new engines (with special thanks to Matt Poppe, who continues to do amazing work on everything he touches):







I have run a few missions with these engines, and I can attest that they’ve opened up quite a few new capabilities - ones that will become invaluable when the R + D progression enters the picture and nuclear thermal engines are not yet in reach.

Last week, we did a space station challenge! Several of your impressive submissions can be seen over on our recent Community Highlights post. Some of this stuff is just nuts.

This week’s challenge is technically about landing, though given Gilly’s low gravity, it might just as easily be called a docking challenge. We challenge you to land on Gilly!

Good luck to you all and see you next week!

Good afternoon, Kerbonauts!

This past week has been a learning experience. The last post received a lot of comments, many of which expressed doubt, frustration, and in some cases anger about either the seeming lack of progress on KSP2 or the perception that a dark reality about the game's state is being concealed. Our team has been reading your comments and asking one another if there's some way we can do better.

In the past, every item in these posts has has to cross a threshold of certainty - we don't want to announce some new feature or target date, only to experience a trust-eroding failure to follow through. I feel this burden especially keenly because in the past I have personally announced dates that turned out to be incorrect. For this reason, we have avoided talking about features in progress, bugs under investigation, or internal delivery deadlines. With a game this complex, nothing is ever assured until is has been thoroughly tested by QA. When you combine this "stay quiet until you're absolutely sure" ethos with a more dispersed update cadence, what you get is long periods of silence.

Now of course, I haven't gone literally silent. Posts come out every week. Before each post goes out, I meet with the production and community teams to review the past week's progress, and many great, exciting developments are discussed. They often take the form of "we've made great progress on x category of a super annoying bug" or "this feature looks good but we haven't had time to fully validate it yet". By my standard of "don't talk about it until it's truly done," neither of those scenarios yield anything that's safe to post about. What is safe, then? Well, for the most part, content updates like new art, parts, and graphic improvements come along in nice, neat little parcels that are not only visually pleasing, but also are unlikely to generate an unmet expectation. They're fun and they're safe, and artists are always creating new content. So you see lots of that.

But the other thing you see lots of is some variation on "improved stability and performance". That's my catch-all term for that very meaningful category of progress that, because of my reluctance to write bad checks, can't yet be talked about it detail. When I hold back on such items, I comfort myself that the less I reveal now, the more surprising the patch notes will be when we release them.

Still, I'm questioning my choice to withhold information about systems in progress. Yes, there's always the chance that when we talk about a feature in development, that we're also creating an expectation that the feature will be present in the next update. Similarly daunting is the possibility that we'll announce that we're working on something the community perceives as "easy" (an especially common situation when we're working on a feature that is already functional in the original KSP), and then take a long time delivering that feature that people may decide we don't know what we're doing. In such cases, we then need to take the time to explain in technical detail why the implementation of such and such of a feature is non-trivial in KSP2. Increased transparency carries costs, and those have to be balanced against other feature-facing work we could be doing.

I'm extending trust to you and will talk about a few things that are not yet complete, so you can see some of the ropes we're hauling on every day - some of which may prove to be long. This list is not exhaustive (there are dozens of people working on dozens of items simultaneously, and there are some features that we really do want to be surprises), but it'll give some visibility into the issues we're tackling. Please do not assume that if a bug isn't mentioned that it is unknown to us or not being worked on - this is a top-ten list.

Our bug prioritization is broadly guided by the following:

• Category A: Any bug that causes loss of a vehicle in flight (physics issues, trajectory instability, decoupling instability, loss of camera focus, unexpected part breakage/RUD)
  
• Category B: Any bug that affects the fidelity or continuity of a saved game (rigidbody degradation, save file inflation, loss of vehicle or Kerbal during instantiation or focus switching)
  
• Category C: Any bug that negatively affects the expected performance of a vehicle (drag occlusion, staging issues, thrust asymmetry, joint wobbliness, landing leg bounciness)
  
• Category D: Any VAB bug that prevents the player from creating the vehicle they want to make (symmetry bugs, fairing/wing editor bugs, strut instability, inconsistent root part behavior)

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

Until a player can envision a vehicle, create it without being impeded by VAB issues, fly it with a reasonable expectation that physical forces will be consistently applied, and have their progress at any point without worrying about the fidelity of that save, the KSP2 experience will be compromised. Obviously, now that we are layering in progression mechanics (Science gathering and transmission, missions, and R&D tech tree) in preparation for downstream Roadmap updates, the importance of addressing these issues only increases.

Therefore, here are a few of the biggest issues we're wrangling with right now:

1. Vehicles in stable coasting orbits sometimes experience orbit instability/decay - Status: possible fix in progress
   
2. Trajectories change when vehicles cross SOI boundaries - Status: fix in progress (see below)
   
3. Certain inline parts cause aerodynamic drag numbers to spike - Status: under investigation
   
4. Returning to craft from VAB causes craft to go underground (possibly related to Kerbals and landed vehicles dropping through terrain while being approached) - Status: possible fix being tested
   
5. Decoupling events result in various issues including loss of control, incorrect controllability of decoupled subassemblies, loss of camera focus, and other issues - Status: may have many causes, but some fixes in progress (see below)
   
6. Save files get bigger over time (TravelLog experiencing "landed" status spam) - Status: fix being tested
   
7. Opening part manager causes major frame lag - Status: experiments ongoing
   
8. Major post-liftoff frame rate lag immediately above launchpad (associated with engine exhaust lighting) - Status: fix being tested
   
9. Root parts placed below decouplers cause issues with stage separation - Status: under investigation
   
10. Vehicle joints unusually wobbly, some part connections unusually weak - Status: under investigation

We’re tracking down some strange vehicle behaviors associated with spurious autostrut errors. As we’ve discussed here before, some radially-attached parts are reinforced by additional invisible autostruts to improve their stability. It turns out that these autostruts don’t always break cleanly during decoupling events, and may be the cause of some of our more frustrating decoupling issues (including those where detached vehicle elements appear to still affect one another’s behavior). We’re still investigating this one, but we have high hopes that its correction will result in a significant reduction of mission-killing errors.

Finally, we have zeroed in on the cause of some of the trajectory errors we’ve been seeing - especially the situation in which a trajectory changes spontaneously when crossing an SOI boundary. This one is deep in the code and its correction may end up fixing a few other downstream issues. This is a complicated problem, however, and we may not solve it in time for the June update. We should know more about this one soon.

I’ve provided the list above as a stopgap. We have been discussing internally how best to improve bug status visibility so that you have a better idea of what we’re working on. We’re looking at a lot of options right now, and I’ll update you when we’ve settled on something. We recognize the need for this transparency and we’ll come to a solution soon.

ANYWAY...we have some nice content news! Update v0.1.3.0 will be the first KSP2 update to contain not only bug fixes, but a few new parts. Right now, we can confirm the arrival of the following:

• A.I.R.B.R.A.K.E
  
• Clamp-O-Tron Shielded Docking Port
  
• Clamp-O-Tron Inline Docking Port
  
• MK2 Clamp-O-Tron Docking Port
  
• Cornet Methalox Engine (new small extensible-nozzle orbital engine)
  
• Trumpet Methalox Engine (new medium extensible-nozzle orbital engine)
  
• Tuba Methalox Engine (new large extensible-nozzle orbital engine)
  
• S3-28800 Large Inline Methalox tank (longer version of large methalox tanks)

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


Note: This is a shortened version of the video due to Steam's file constraints. Check out the full 1:17-minute long video here!

We're still testing the new grid fins. Because these parts require some special part module support, engineering work is ongoing. Due to the complexity of this work, we don't believe grid fins will make it into the v0.1.3.0 update.

Next for the Weekly Challenge, we're building space stations! Thanks to @RyanHamer42 on Twitter for the suggestion!

Good luck and have a good weekend, everyone!

A fine May afternoon to you, fellow Kerbonauts!

I'll start with a bit of good news: the v0.1.3.0 update will be dropping in June. We'll announce an exact target date when we're a little closer to the day. We've already seen a few big bugs go down (you can throw a fairing away now in the VAB without endlessly redeploying its editor, for example), but I'm going to hold off on itemizing other fixes until they're confirmed zapped by QA. Regardless, we're feeling good about our progress in all areas and are confident that the next update will provide good performance, stability, and gameplay improvements.

In the meantime, our design and content teams continue to bring new parts to life. One thing they're working on now: grid fins! There were designed by Chris Adderley and brought to life by Alexander Martin. Chris would like me to point out that the fin on the right is shown upside-down so that you can see the beautiful serration detail:


Our tech artist Jon Cioletti (with the help of graphics gurus Christ Mortonson and Phil Fortier) has pulled off the impressive feat of improving both polish and performance by overhauling the solar lens flare occlusion system. Lens flare occlusion (the scaling/disappearance of the sun's lens flare when passing behind objects) no longer uses raycasts or colliders - now we're literally counting pixels on the sun itself. The result: no more sun peeking through terrains or oceans, no more weird flare behavior behind vehicle parts, and the sun now shines correctly through visors, trusses, parachutes, and windows! Check it out:


Disclaimer: This is a compressed GIF version for Steam due to file size constraints. Check out the full video res version here.

We've also been building some lovely Science collection parts, which are meant to provide interesting, meaningful payloads for research missions. This is one of our new radial science collection parts (designed by Chris Adderley, built by Alexander Martin, and animated by Paul Zimmer):


In community highlight news, we've received your capybaras and have found them various cute, hilarious, and unsettling. For more capybara shenanigans, check out this week's roundup. This week's challenge is to land on Moho!

See you all next week and happy flying!

---

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

Good day, fellow Kerbonauts!

In last week's post, I communicated our intent to decrease the update cadence during Early Access to allow our team to devote a greater portion of their time moving toward 1.0 and a little less time prepping incremental public updates. Some have expressed concern that this change signified some dark portent. To ease some of your concerns, here are a few clarifications:

• Our team is fully funded, properly staffed, and completely focused on executing the full vision of KSP2. Our velocity is good and our morale is great. This is still a dream job, and we're still committed to making this game spectacular.
  
• We want to balance our desire to be Santa (literally the most fun part of my job) against our goal of delivering an excellent product. The update cadence we're looking at right now extends the previous cadence by two to three weeks - structurally, the change is not radical. I know the waiting is painful, especially when there are still game-breaking bugs. Hopefully, the fact that each update will contain more improvements due to that lower frequency helps to offset some of the frustration of waiting.
  
• This project has from the beginning been viewed as a long-tail endeavor requiring a long-term investment. We are not worried about keeping the lights on; and we will be delivering on all of the promised roadmap features over the course of the Early Access period.
  
• These development updates will continue to provide visibility into areas where gains are being made. These posts are by no means comprehensive, not least because many of the improvements we're seeing aren't necessarily photogenic. They are meant to give you a taste of what's to come.

For example, we have seen rescalable UI elements in action for the first time this week (with many thanks to our new engineer Ryan). We know this is a highly-anticipated improvement, especially for players with higher-resolution displays. The same below is a work in progress (yes, I see the app bar isn't scaling yet) - the final implementation is likely to index to preset sizes to avoid scaling artifacts. I'm certainly looking forward to this one:



Note: This is a work in progress!

Darrin House, our Director of QA, posted a really in-depth Dev Blog that I think does a great job of showing the behind-the-scenes reality of testing this game. It pairs well with a lot of recent discussion in the community about the role of QA in the development process, and it gives some insight into the unique challenges presented by KSP2. No shade on previous dev blogs, but this one raises the bar. I am perhaps saying how much I like pictures here. It has lots of pictures.

This week saw some unprecedented radness on the ksp2_screenshots Discord channel. Check out these masterpieces from Coriolis, Little Earl, memes1, and Schwing2727:


Finally, this week's challenge: fly a mission inspired by ESA's JUICE program. While we wait for the RIME antenna to get itself unstuck, let's send good vibes ESA's way by flying our own multi-moon probes to the satellites of Jool! Now's a great time to polish up your gravity-assist chops.

Have a lovely weekend!

---

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

My name is Darrin, and I'm the new Director of QA here at Intercept Games. I'm new to the Intercept team (I joined a week before the KSP2 launch) but I'm not new to QA. I've been doing software testing since the early 90s and worked at Visio/Microsoft for 17 years and then at Amazon for the last several years (most recently as a founding member of the Luna game streaming service). I'm an old-school hardcore gamer - I've been playing since I had "The Bard's Tale" on my Commodore 64; my Xbox gamer score is 150,000+ and I don't pad that with those silly games to just farm achievements! I'm doing my best to learn KSP2 as fast as I can, and just so happen to sit directly to Nate; I've received the rarely given "high five" that I will cherish always.

I'm here to help as much as I'm able. People here in the office GREATLY appreciate the feedback you give. To that end, we need to help make the flow of bugs that you find as easy as possible for all of us to track in our systems (for all of us).

Please contact Private Division Customer Support for any game breaking issues such as hard crashes. But, if you are posting about an issue, the more data we have the better (aka in the Specs discussion in Discord, you'll want to post your detailed specs info!).

Running into an issue is frustrating; I feel your pain. Trust me when I say, bugs drive us just as crazy as they do you (honestly probably more, because we need to retry them over, and over, and over!). But when you find an issue that is important enough to post about - you can do it one of two ways:

• A. "This game doesn't work! I can't play!!" (end of message)
  
• B. "This game doesn't work, here is some info and specific steps of what I was doing - please fix it!!" (adds a bunch of information we can work with)

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

So, help us help you and please give us all the information we might need. Please submit your feedback on the KSP forums to ensure we see it. By giving us necessary information, this helps us move issues up the chain faster and keeps others from having to ask you for the same information over and over:

• Title: A sentence that summarizes the issue.
  
• Specs: See 'The Best Way to Get Your Specs Info' section for how to give us all the info we need here.
  
• Severity: High/Med/Low. This is your opinion - but it typically goes: High = crash, Med = feature not working as expected, Low = there is an issue, but has a workaround.
  
• Frequency: High/Med/Low. Does this happen a lot? Can you reproduce it consistently? Or was it a one off? (We still want to know about one-offs, but we'll categorize it as such).
  
• Description: Tell us what you were doing, what you expected to happen, and what actually happened, etc. The more information here the better, we want specifics, not generalizations.

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

I can hear some of you now: "Hey...! Why do we have to do the work for you? I'll be 100% honest - you don't. Some bugs that come from the community have already been found by our QA team here. But sometimes, bugs can seem to be a "one off" or very difficult to put together consistent repro steps.

The more information we have and the more we know people hit it, the less time it will take to turn around a meaningful fix.

"Wait...if the QA team is finding all these bugs, why aren't they all fixed?"

The process of deciding what bugs to fix is quite complex and is based on many factors. We do not always go after the easiest bugs to fix, but rather bugs we feel will have the largest customer impact at any given time. But at the same time, we must consider the impact of any bug that while fixed, could have other implications (aka regressions). We factor in the severity of the bug combined with its frequency, as well as a ton of insider knowledge from people here on the team; and we work very closely across all roles and make these decisions together as a team.

We care A LOT about bug regressions, so if you see a new bug that didn't exist previously, then please pass along the information to us and we'll look into it ASAP. But remember, a change to how something works from one build to another is not necessarily a bug. We're in Early Access and we'll make changes to how things work at times to see how that goes and iterate on that over time.

Investigating a bug takes time to get a precise scenario for the engineer to address (that's why the steps and info above can help). They will then do their own investigation on the fix itself (what it would take, what parts of the code would be affected, how risky of a fix it is, could it break other parts of the title, etc.). Once that's approved, there is a code review of the changes that were made. Then the change is put into a specific branch/build of KSP2 where testers will do a full investigation of the original bug and do halo testing around the areas that the code affected. Finally, it goes into a release candidate build along with a bunch of other fixes, and it gets tested again in a very deep regression suite of tests to ensure that other (supposedly unrelated areas of the product) still function as expected. There's actually even quite a bit more to it than that - but it's a good summary of how we do things here.

Kerbal Space Program 2 is...huge. I've owned the testing of products that ship to hundreds of millions of users that had a simpler test matrix than KSP2 does. There are A LOT of areas, processes, and stages of testing a product; and I'm not going to go into all of them here (it would be a doc 20x longer than this). So, this blog is mostly focused on end-user reported issues and how we deal with those.

But with regards to complexity, our KSP2 Test Lead, Josh, who has been playing KSP since 2013 and testing it for the past five years, put some information together.

"Talking about the complexity of construction and variables for potential issues, there is a consideration on why something may not be known, tracked, or reproduced before.

How unique is your vessel? It's straightforward to test parts in a vacuum (the "by itself" kind, not specifically the "no air" kind) and confirm that all the bits and pieces are functioning as designed. However, interactions between various parts are where we often see things go sideways. There is a hierarchical interaction that can cause problems, is compounded by where it was placed relative to other parts, and when it was placed (order of construction). This is further exacerbated by what was done before the vessel was made and how it's been flown.

Let's break down possible iteration numbers to give an example as to the potential complexities available in KSP2:

If you were to use every stack attach part that has a top and bottom stack attach node in every possible permutation without duplicates, it would be factorial 245, which translates to a number 481 digits long. For reference, the estimated number of atoms in the known universe is only about 10^80 (10 to the 80th power), or an 81 digit number. So, this is interesting, but not realistic. In normal circumstances, you are not likely to build a vessel using EVERY stack attach part.

• If you assume people are only using about 30 stack parts in a single vessel stack (so a non-repetitive permutation of 30 out of 245 possible stack parts) you still end up with 7.429002947 E+70, or a number about 71 digits long.
  
• That’s permutations, however. What about just using specific parts together in general in no particular order (combinations)? That has to be a significantly smaller number right? Well, even dropping this down to only combinations using 15 of the 245 potential stack attach parts with double (top/bottom) attach points still gives us a total of 3.396886498 E+23 possible combinations (or a 24 digit number). For comparison, the number of stars in the sky is estimated only about 200 sextillion (or a 2 followed by twenty-three 0’s, also 24 digits long in total).

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

• Parts with a single stack attach node
  
• Stack parts that are attached radially (and the surface attach-only parts)
  
• Subassemblies that can be inside fairings/cargo bays
  
• Parts stack attached to other radially attached parts connected to the center stack of the vessel
  
• Adapters that allow stack attachments in other directions
  
• Adapters that allow a single stack to diverge or converge (such as bi/tri adapters)
  
• Translate/rotate transform parts (which also add new orientations to branch off from)

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

An example of how configurations can have impact, we recently fixed an issue with a handful of small parts that would cause the entire vessel to fly apart at a certain point in flight, only when used in conjunction with other specific (similar) small parts in a specific hierarchy order. Not all combinations of a vessel using those parts caused this, only in specific permutation orders.

One of the best ways to ensure a bug you encounter in flight is tracked is to give us as much information as possible. A log file and save help a lot, but if you have a workspace file for your vessel, in some circumstances, that can be even better.

There is more to this game than parts, but the above is a math-heavy example of the complexity we are working with in test. This is by no means the only game to have this many potential variations to consider, and it won't be the last, I am sure. The one takeaway is this, the more information that can be provided with the circumstances something went wrong, the quicker we can identify the issue. Attempting to reproduce issues with just a list of the 20 parts used to create a vessel? That could take a VERY long time."
All that being said - someone on the team did the math and even with our entire product team testing on a particular build of KSP2...our total user base will pass that time spent testing within hours of release.

We use a matrix method that combines every feature with frequency of use across all hardware combinations and operating systems. This testing effort is what really adds to the time between patches, and then if we combine bug fixing alongside of new feature development, it's big. Automation helps of course, but as users of the product you can understand that the majority of testing needs to be hands on.

It's not all crazy matrixes and slogs of testing we have to do. We also have fun playtest events with themes (quite a few are ones we do just before the Community team sends them out as challenges):


From the recent playtest where a Designer on our team, Chris, is trying to branch out from rockets.

I've worked at both Microsoft and Amazon as well as a few smaller companies, and our QA to developer ratio is on par with just about any team I've ever been on. We have a dedicated QA team here at Intercept Games (Seattle) who follows the feature crews as new features are developed and a larger QA team within Private Division (Las Vegas) who owns regression passes and overall validation. We supplement needs (hardware testing, OS's, etc.) with some vendor testing from time-to-time. We even have a large amount of previous hardcore Kerbal players that joined our team and have been helping us out, no matter their role (and I don't mean just Nate!). We've got a ton of experience on the team going back to the early KSP1 days as well as others who have come during KSP2 and are now some of the best creators on the team.



Here are a couple pics from Lo - who is a member of the PD QA team in Las Vegas.

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.


Every company handles minimum requirements a bit differently, but we use them as our bar of initial support (aka we don't officially support or test anything below minimum requirements). We set that bar based on the performance checks we've done in-house during our testing and evaluation process. Some users may choose to try to run KSP2 on a below-the-minimum bar computer even though we don't officially support it and we allow that (aka we don't do a check at launch to determine hardware and force a hard stop at that point). This choice is a tough one, because we want to allow users who might have some very specific or unique hardware to try to run KSP2 and this allows some specs clearly below the min bar to try to run even though that will likely cause issues.

And that's where things can get crazy - because we'll see someone post on the boards that the game is unplayable and that they have a good computer to play it on, but after drilling in - the majority of the time the computer is below the minimum requirements bar (and the telemetry we currently have tells us the same story).

Somewhere between our recommended settings and our minimum settings is where we do the majority of our testing. We have a large variety of hardware in-house and we supplement that with vendor testing, but there will always be cases where users will try hardware that we haven't and don't have access to. In these cases, we greatly value the input from the user base and will acquire hardware from time-to-time ourselves, when needed, based on that info.

Constructive feedback can provide positive results. There was a very large thread on our Discord and a subset of users who all had specs below the min bar - they all had integrated graphics cards and were having very similar results (KSP2 wouldn't load at all). I checked with our Senior Engineer, Mortoc, on this topic and he suggested a potential workaround by having them set their Windows resolution to 1024x768 - and now most of them are now able to play. No promises of course since it's below the minimum requirements, but it's worth a shot if you are also having that issue.

Our goal is to improve the minimum requirements over time, but we can't guarantee where it will go to, or what those requirements will be. We'll use the data that comes in from users, our automated benchmarks that we run as well as in-house testing to monitor performance over time.


Building functional complex ships is a goal on the team as well. Marc, a tester on the team since early KSP1 days (aka Technicalfool on the Discord) sent these to me when I asked for a ship to use for testing.

The more spec information we can get, the better that we can help you solve issues. Typing it in is great, but even the best of us can have a memory lapse and think we have 16GB when maybe we only have 12GB. Same with video cards - it can get super confusing; and if someone on the team is investigating an issue for you only to find out the specs you listed were incorrect...it's wasted time. So a screenshot of your specs is best and here's how you can get it:

If you are running via Steam, click "Big Picture Mode" in the upper right corner of the Steam window. Then bring up the menu from the lower left and choose: Settings ➟ System. Scroll down to the Hardware section and then screenshot/use the Snipping Tool to get the info needed. To exit this mode, click in the bottom left of the window and then click Menu ➟ Power ➟ Exit Big Picture Mode.


Alternatively, if you want more info, in Windows - hit the Winkey (⊞ Win) to bring up the start menu and type in: dxdiag. This will bring up the DirectX Diagnostic Tool. The first tab (System) will show your system model, processor, and memory. Now, just click the "Save All Information" button at the bottom, and it'll put everything into a text file.

Nothing in that file is harmful to send, but if you don't want to share everything else on there, screenshot the important areas.



The other tabs will give you information about your displays and video cards, which is typically important if you're having performance issues. If you have multiple monitors or a laptop connecting to a monitor - then you might have to click on the last display tab to see the correct video card information. Again, if you don't want to share all your info, screenshot the important stuff.



The good, the bad, and even the ugly. We like to hear what you have to say. Our community team keeps us in the loop (and coordinates us doing stuff like this dev blog and the AMAs) and we love to meet and chat with you all in person as well. We had the opportunity to chat with some of you at GDC (had quite a few Mun and Minmus landings) and we're looking forward to more in-person events in the future.

Hi Kerbonauts!

We sat down with Design Director Shana Markham for another Ask Me Anything on Discord. She's been working at Intercept Games for 3 years! The full AMA can be found here, complete with an audio version. As a reminder, we're in Early Access! Plans can change.

Questions are organized by topic and include who/where the question came from. And we've heard your feedback-the next AMA will be even more varied in source and topic. Be sure to check the Discussion Board for the next AMA callout (date TBD). Thank you to everyone who submitted questions and tuned into the AMA!

What is a design director? (enjoyer, Discord)

• A design director is someone who is responsible for standards, practices, and excellence of a particular discipline. I oversee all of the designers over here at Intercept Games. I also make sure the designers here can learn and grow and become better designers every day.

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

• The VAB. There's a lot of cool moments that help new players learn how to build and fly. Exploring that design space allows more expert players to learn shortcuts to make things faster. It's a win-win on both sides of players.

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

• Glumo!

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

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

What has been the process of bringing a solid gameplay foundation to player progression in KSP2? (StarHawk, KSP Forums)

• We have to answer 'how does progression give implicit and explicit goals'. If you look at something like Science, that's implicit. No one is directly telling you to go do experiments. Implicit goals are a better space for Kerbal since we're based on exploration. Explicit goals though, are way better for newer players, because it helps them learn what the game is about and what they can do. It also helps some players explore different areas of the game they may not have explored before.

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

• There's a lot to this. We have a handful of subject matter experts including professors and other outside sources. Internally, we read whitepapers and dive deep into all different types of topics. When I initially came into the project, I first knew Nate as "that guy who has a whitepaper about metallic hydrogen taped to his wall". With this game, we're not always working just with game designers - we're working with people who are passionate about aerospace which is fantastic.

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

• Most Difficult: Establishing the roadmap. We started from an endpoint "here's the game as a whole", buy when you go into Early Access, it's not 50% of each feature, it's milestone on milestone - each building on top of each other. It took us months to sort out. There's still moments where we think about moving things around, but trying to take this absolute behemoth of a game and parse it out into a bunch of different phases.
  
• Easiest: Sorting parts by types as a default in the VAB. When we started, we just sorted by size - but it caused difficulty with finding parts. Once we added sorting by types, it made sense to make it the default.

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

• Depends! Depends on the part and so many other aspects. For some parts we're working on right now, it's a pretty quick turnaround. But for a lot of the parts, we think about "what's the reality of this part" and then we go through the "what's the gameplay elements that this part could add?". From there we move into "okay, we understand what the user story will be when a player uses this part". We'll then do whiteboxes and think about how the parts will impact other parts in the game. Ultimately it depends.

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

• We kept it to 1/6 size for gameplay reasons. There's not more really on this. Basically if we brought the size up, it would directly impact the game negatively when compared to KSP1.

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

• Yes, and I totally understand the current implementation makes long distance missions pretty hard to do. I can't say when a change might come, but I can say we're talking about it a lot.

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

• One of the first big propulsion fuels that will come in is nuclear-based. As it comes to resources and biomes, Kerbin isn't a hotbed for uranium - so for all of you who choose to play Exploration, that will be the first time you need to look past Kerbin for things you need.

What was the most important change in design of KSP2 from KSP1 that you feel is overlooked by the community? (viccie211, Discord)

• Approachability. All of the little things that lead to more people coming to the game and moving away from opaqueness. Moving away from "hope you remembered this!!". We want players to come in, learn, try, fail, and want to try again. That doesn't happen if the game doesn't provide players the information and guidance needed to make those decisions. Which is complicated when you're dealing with a game that includes rocketry and orbital mechanics. We can't simplify that stuff, so we have to guide players carefully.

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

• The tutorial suite currently in the game is the beginning. For every milestone, we ask ourselves "what else can we add?". So yes, more tutorials to teach more advanced topics! Certainly when colonies comes out, advanced landings will be extremely useful. One of our writers did a knowledge-share internally about precision landings, and that taught us a lot about how in-depth that topic can be - and we have to figure out how to distill that down to make it approachable for new players.

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

• Glad to hear the tutorials are helping you get up and flying. We definitely want to do that. Some things we're working on: landing, interplanetary travel, basic troubleshooting, planes, and docking. We want each tutorial to build on top of the previous one.

How will resources be distributed across so many planets to give the player a reason to explore every world? If resources aren't the catalyst for exploration, how else do you plan on motivating exploration? (Astr0Guy5, KSP Forums)

• We could put a different resource on each planet, but it gates players into "you must do X or you will not proceed". We don't want to force players to go to every single place if they don't want to. Also that's not really true to reality either. Instead, we want to look at the various resources on a planet and how it plays into your space program. Especially with colonies and exploration, you may want to build a mining colony - but perhaps it's really far away and it's annoying to get to. So instead you go somewhere else and build an additional orbital colony to build resource pathways.

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

• Yes, you will gather raw resources and then refine them into what you need. Chris Adderly had a lot of fun building a production chain graph which I hope we one day get to release since it's really helpful to understand how it all flows together.

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

• To give a specific number, I think we're looking at 14-15 specific resources throughout the universe. Focused on what you need for propulsion. Same resource may be present in multiple locations, but prevalence/proximity to existing infrastructure are factors we're thinking about as well.

As KSP has many parts that aren't exact recreations of real rocket parts, or are future technologies that don't exist yet, determining what stats like thrust and specific impulse sounds more involved than looking it up. Could you give an overview of the process the team uses to determine the stats for, say, a metallic hydrogen engine? (pschlik, Discord)

• Whenever we look at introducing new parts, we group parts into certain stories and goals. That helps us understand certain behaviors and gameplay elements. For example, we command parts. All of the individual types of parts have stories that help players reach particular goals. Once you understand that, you figure out what the variable is that we can tweak. Like "okay maybe command pods have a better heat tolerance than landers". You derive formulas from the guidelines and then compare the parts together and look into the real life data, and ultimately we see how the parts build on top of each other. It's a crazy number of variables.

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

• We've moved some variants out as their own parts. Certainly a topic, but also would likely not appear in the same form as KSP1.

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

• Not fully sure on the 1.875M parts, but for the larger part categories you'll see this come with Interstellar because those engines are gigantic!

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

• Yes, we call these procedural parts. I believe the next one will be radiators which will come when heat returns. We add procedural parts when we feel like "wow there's a lot of parts that are samey". Wings 100% were a priority for us in Early Access and now we want to build on top of that.

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

• Not using oxygen is something we want to put through its paces for authenticity and gameplay values, maybe it's something we could do but also what do we and the player get out of this? Does it open it up too much? That's the beginning part of the conversation. There's a lot of good things in the atmosphere, so expect in the future that the Kerbals will start to give them more attention.

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

• Sure. Folks are familiar with the PAW from KSP1 (individual windows). In KSP2, we unified this to the PAM, the list of parts. The heart of that decision was based in accessibility - it can be really hard for some players to click on specific parts. This is a frequent conversation for our UI/UX group.

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

• Underwater bases definitely scare me a little, but we 100% want to support boats. KSP1 has some awesome boat content and we want to continue to allow that. But also.....there are some celestial bodies that might have some challenges you might need a boat for...

Will previous science parts from KSP be in KSP2? (Krzysztof, Discord)

• Parts will be different between the two games. In this case, the design team really wants to hit on their own building and flying usage challenges. You'll see less "let me put a thermometer on my command pod" and more "I've got this weird bulbous thing that performs an experiment and I need to build a rocket around it".

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

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

Will colonies feature automation gameplay (within the colony, so not the delivery route system)? It can look something like this: resource extractor building mines a raw source, resource refinery building makes a useable material out of it, assembly. (Acid_Burn9, Discord)

• There's a colony dev blog that I did a long time ago, which still has things to keep in mind like "KSP is a game about designing cool rockets". Like if a player wants to launch the game and fly a mission to Duna, we don't want the player to have to do 30 minutes of colony overhead to start working towards that goal. We want to make sure automation is implemented to make sure the part of the game that is really important to us, rockets, continues to stay the main gameplay loop.

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

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

Interstellar

With interstellar technologies and travel on the roadmap, is relatively a thing in KSP2? Will KSP2 handle time dilation effects when traveling at high velocities to the target star system? (Angelo Kerman, KSP Forums)

• Nate talks about this...and it's terrifying. No other comment...

If you read all of this (or scrolled to the bottom hehe)...snacks for you! 🍬