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:
- Vehicles in stable coasting orbits sometimes experience orbit instability/decay - Status: possible fix in progress
- Trajectories change when vehicles cross SOI boundaries - Status: fix in progress (see below)
- Certain inline parts cause aerodynamic drag numbers to spike - Status: under investigation
- 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
- 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)
- Save files get bigger over time (TravelLog experiencing "landed" status spam) - Status: fix being tested
- Opening part manager causes major frame lag - Status: experiments ongoing
- Major post-liftoff frame rate lag immediately above launchpad (associated with engine exhaust lighting) - Status: fix being tested
- Root parts placed below decouplers cause issues with stage separation - Status: under investigation
- 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!