Kerbal Space Program 2 News

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.

[hr][/hr]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.

[h3]Bug Status[/h3]
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.

[h3]Bug Reports Subforum[/h3]
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!

[h3]Weekly Challenges[/h3]
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!

[hr][/hr]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.

[h3]Bug Status[/h3]
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.

[h3]Bug Reporting Progress[/h3]
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!

[h3]Engines[/h3]
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.

[h3]Community Highlights[/h3]
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.

[h3]Weekly Challenge[/h3]
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!

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