🚀 <-- This rocket denotes an issue or change that community members directly helped by sharing or suggesting it to our dev team. Thanks to all of you who send in bug reports and suggestions!
Bug Fixes
Map and Tracking
🚀 Fixed: Trajectory position changes when vehicle transitions between spheres of influence (SOI) [Original Bug Report]
Lots of stuff to talk about today! As many of you know, a couple of new bugs were introduced with last week’s v0.1.3.0 patch. The most significant of these bugs relates to a loss of atmospheric drag (and physics in general) when capsules are decoupled. For the first time ever, we issued a hotfix to correct that issue yesterday morning.
Yesterday's v0.1.3.1 hotfix also contained a fix for a VAB bug in which fairing editor UI elements were drawing on top of one another.
We discovered after yesterday’s hotfix that people were unable to launch the game outside of the Private Division launcher. This was not intentional, and has been fixed — due to a configuration error on our end, we accidentally included Steam’s built-in DRM. KSP2 is DRM-free, just like KSP1. The fixed update was pushed to Steam this morning. Sorry for the headache!
We’re testing a second hotfix (timing TBD) that corrects the blurry navball issue. And because we’re sneaky little devils, we’re also doing some testing around a fix for the SOI transition trajectory bug. If these fixes prove stable and low-risk, we’ll release a second hotfix. Fingers crossed! The work that’s gone into the SOI transition issue — number 2 on our top-ten most wanted bugs list — deserves a special mention. Engineers David Tregoning, Mark Jones, and Shalma Wegsman put in colossal efforts to both track down the cause of the issue and to craft a solution. This one has been a long time coming, and it’s great to be able to knock such a big item off the list.
The credit for the fast turnaround on all the latest fixes goes to a well-coordinated joint effort between engineers, production, and QA. We’re still learning as we go, but things are feeling good.
Bugs: The Next Generation
Based on the Bug Reports subforum, these are the community's 10 most-upvoted bugs:
Note: Navball Blurry [18 votes] and SOI Trajectory Line Issues [18 votes] have been left out of the above list since we're considering them for the second hotfix.
Thank you to everyone who took the time to submit bugs in the subforum. Even if you don’t have a new issue to report, your upvotes help us determine the relative priority of the bugs that have already been posted. While we investigate the bugs above, two other non-feature items also feature in our top ten:
Rockets are still too wobbly
SAS causes runaway pitch oscillation for aircraft in flight
Lots to do! Thanks again for submitting such detailed and well-documented bug reports. It's going to be a busy month!
AMA with Kristina Ness, Art Director
Did you catch our AMA with our Art Director yesterday? Kristina was asked a lot of interesting questions, many of which ranged well beyond the art domain. She gave fantastic and detailed answers! If you missed the stream, it's definitely worth watching on YouTube! With the help of streaming wizard Dakota, she even got to show off some visuals as well! You can find a transcript of the AMA here as well. Thanks, Ness! https://www.youtube.com/watch?v=GTFcLtqtdfI
KSP2 Steam Sale
This is the second week that KSP2 is on sale for 20% off, which ends on July 13th at 1pm ET. If you've got any friends who you think might enjoy the last bit of heat-free reentry during Early Access, now's a great time to tell them about the sale!
Weekly Challenge
Last week’s Jool 5 challenge produced some of the coolest, most ambitious craft designs we’ve seen in KSP2. Check out this absolute unit from DarlesChickens:
Or this beauty from Razorback:
And here’s a unique one from Tr1gonometry:
We know that in the Wobbly Rocket Era, missions of this kind can be extra challenging. Kudos to everybody who braved the bugs and slipped the surly bonds of Kerbin regardless!
This week’s challenge? You’re putting on an air show! Build a maneuverable stunt plane and show off your fancy flying skills. Buzz the tower! Under the bridge! Do some barrel rolls! To get specific:
🏆 Jeb Level Goal: : Fly under the R&D bridge as fast as you can.
🏆 Val Level Goal: Fly through the parking garage bridges (from the water), under the R&D bridge, then back through the parking bridges as fast as you can.
🏆 Tim C Level Goal: Fly a loop around the R&D bridge so that you pass under it twice in one maneuver.
Don’t forget to wear your G-suit — you’re about generate some wing loads that’ll make your crew chief very grumpy! While your screenshots are always welcome, video capture will be the best way to show off your maneuvering prowess. Good luck!
Summer Changes
Now that Summer's here, with all its vacation-related comings and goings, I'll be letting other parts of our team takeover these posts. In the coming month, you'll still see the following here:
Bug report updates
More AMAs
Challenges
In addition, we'll be uploading more gameplay clips to our social channels.
We've got a lot of good momentum coming off the last update and we're already making great headway on the next one. Looking forward to sharing our progress with you soon!
We sat down with Art Director Kristina Ness for another Ask Me Anything, this time live on Twitch! Thank you to everyone who submitted questions and tuned into the AMA. As a reminder, we're in Early Access! Plans can change.
For those who couldn't catch the stream, a YouTube version is now available. Check it out as Kristina talks about KSP2's art style, art processes, and more!
She may or may not have showed off some never-before-seen art...a peek may or may not be below...
Concept art of the new Kerbal suits.
Early idea sketches of the Early Access key art.
The sketch that would become the Early Access key art.
🚀 <-- This rocket denotes an issue or change that community members directly helped by sharing or suggesting it to our dev team. Thanks to all of you who send in bug reports and suggestions!
Bug Fixes
Flight
🚀 Atmospheric drag not correctly applied to capsule after decoupling [Original Bug Report]
UI/UX
🚀 Procedural fairing editor buttons overlap one another in VAB [Original Bug Report]
Thanks to Community Member Kavaeric for making the image!
Happy day-after-update, fellow Kerbonauts!
Many of you have had a few hours to experience the v0.1.3.0 update, and hopefully you have found the gameplay experience improved! Many players are reporting significantly better framerates, but there are more than just performance gains on the menu. Among the new fixes and features we’re most excited about for this update:
New parts, including three new engines, new docking ports, and the A.I.R.B.R.A.K.E.
The Flight HUD UI is now re-scalable via player settings
Several decoupling-related flight bugs have been resolved
We knocked out several of the vehicle-falls-through-terrain bugs
We nailed that really annoying VAB bug that kept you from putting down procedural parts after picking them up
We strengthened wing attachments with a new automatic multi-joint system
We fixed the asymmetrical separation forces on radial decouplers, restoring the beauty of booster separations
There are many other fixes, big and small. Take a look at our patch notes to get the full rundown.
What's Next
This update represents an incremental step in the ongoing Early Access process of addressing game-breaking bugs while moving toward our first Roadmap update, which will add Science collection, a new Mission system, and parts progression to the game. We still have quite a few game-breaking bugs at the moment, as well as aspects of gameplay that still need refinement (wobbly rockets, overactive control surfaces, strange SAS behavior). We will be posting our new top-ten most wanted bugs next week (three of which will be carrying over from our previous top-ten list). If you’re playing the latest update and you come across a bug that you’d like to report, please do so via the Bug Reports subforum on the KSP Forums; you can upvote existing reports, or if your issue isn't listed, you can submit a new report through the form. We will be following those threads very closely to track which issues are most important to the community as a whole.
We are aware that one of the decoupling fixes in this update has introduced a new issue that breaks aerodynamic drag after a decoupling action. Thanks to early reports from the community, we have been able to reproduce the bug and are working on a fix. If the fix proves stable and low risk, we will consider releasing a hot fix in a few days.
Some players have also correctly noted that the orbital decay and SOI transit trajectory bugs are still present in v0.1.3.0 - while we had high hopes for an eleventh-hour breakthrough, neither fix made it across the finish line in time. In the days after code lock, a new fix for the SOI transit issue was submitted and is being tested. Our engineers have also isolated the orbit decay issue and believe they have a good remedy on deck. With updates, there’s always the temptation to hold the build just a couple more days to sneak in additional fixes (which we actually did this week). Alas, at some point the train has to leave the station, but it’s at least comforting to know that these issues will be addressed in an upcoming update. We appreciate your patience, and we hope that the changes that did make it into this week’s update have improved the game for you.
Other questions that we've been asked:
Where's reentry and heating? We are working hard on both. We expect reentry VFX to arrive earlier than thermal systems and heat-related part destruction, so there may be a short phase during which reentering vehicles look like they’re being heated, but really aren’t. We don’t want to reverse any of our recent framerate gains, so we’re taking the time needed to make sure reentry is both awesome-looking and performant. To give you better visibility into the work taking place in this area, we will be posting a new dev blog about the heat system soon!
What's going to be in v0.1.4.0? As we continue to work through our critical bugs list, those that are fixed by the next update will be included. We are still targeting foundational bugs and playability issues. As we work down through the list, we’ll report on our progress.
When is the Science Update? The first of the headline Roadmap updates - which will add Science, Missions, and an R+D Center, is still several months away. A lot of work is going into the "Dot Two" update — deep architecture work, bug fixing, new systems, and a lot of new content. We will continue to release incremental updates until that time, with the goal of eliminating the major game-breaking bugs prior to v0.2.0.0. We’ll provide a release date for that version as soon as we can
Steam Sale
With summer upon us, Private Division is holding a 20% off sale for KSP2. This sale ends on July 13th. If you’ve got a friend who has an interest in participating in Early Access, now is a great time to hop on board!
Upcoming AMA
On Thursday, June 29 at 10am PT, our Art Director Kristina Ness will be fielding your questions about KSP2, and this is a rare opportunity to get detailed answers about the game's art! You can submit questions for here on this post!
Weekly Challenge
Last week's "Score a Goal" challenge was extra challenging, but those who conquered it created some very original vehicles!
First, there's this submission from Miss, which deserves special mention as it’s the only attempt that involves not only a ball, but a rocket-powered foot!
Squidplaz did some reaction wheel magic to get a ball under the R+D Center bridge:
User pyasupro posted this beauty on Twitter, and made goals on both the Mun and Moho:
This week's challenge: we're going to Jool! Here are the deets:
🏆 Primary Goal: Launch a single-Kerbaled mission (only 1 spacecraft may depart Kerbin's SOI, but it can be built in Kerbin orbit) that passes through the SOI of all 5 of Jool's moons at least once before returning to Kerbin.
🏆 Secondary Goal: Same as primary, but land a probe on each of Jool's moons (the probes don't have to return).
🏆 Jeb Level Goal: Same as secondary, but plant flags on Bop and Pol.
🏆 Val Level Goal: Plant flags on all 5 moons of Jool in one mission before returning safely to Kerbin.
Kerbal Space Program 2 is at a discounted price of 20% off until July 13th at 1PM ET. Join us in the Early Access journey into the stars and experience exciting new features as they first-hand as they come online.
We also just released our latest patch v0.1.3.0 (today, fresh out the oven). Highlights from this patch include:
New parts (A.I.R.B.R.A.K.E.S, Clamp-O-Tron Inline Docking Port, S3-28800 Methalox Fuel Tank, and more!)
Have you ever wanted your own Jeb or Val? Or wanted to rep KSP in a fashionable manner? You're in luck - KSP merch is also on sale for 40% off until July 1st!*
*Discount based on Private Division’s SRP. KSP merch offer ends: July 1st, 2023 at 11:59AM ET. Available while stocks last. See store.privatedivision.com for pricing and terms.
🚀 <-- This rocket denotes an issue or change that community members directly helped by sharing or suggesting it to our dev team. Thanks to all of you who send in bug reports and suggestions!
Bug Fixes
Flight & Map
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: 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
Parts & Stock Vessels
Added A.I.R.B.R.A.K.E.S part
Added Clamp-O-Tron Inline Docking Port, Clamp-O-Tron Shielded Docking Port, and Mk2 Clamp-O-Tron Docking Port parts
Added Cornet, Trumpet, and Tuba engine parts
Added S3-28800 Methalox fuel tank part
Adjusted MEM-125 Engine Mount color mask and part size to match similar parts
Added auto 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
UI / UX
🚀 Added flight HUD UI scaling in player settings
Fixed: Fairing length slider gets stuck after reverting to the VAB from flight
Fixed: Lower stage Delta-V displays 0 when adding an empty stage above an engine in the VAB
Fixed: Changing radial symmetry count after placing the first part of a strut causes the strut to break Fixed: Log error in some situations when selecting the visibility mode icon on an interstage fairing
🚀 Fixed: Toggling control surface in wing editor fails to remove control surface when editing multiple wings
Fixed: VAB becomes unresponsive after clicking the fairing edit button and doing an unrelated action
Fixed: When holding ALT and hovering over part in the VAB, part asset name shows instead of part name
Fixed: Wrench icon appears before placement of procedural wing
Environments
Adjusted PQS transition range for Vall
Integrated KSC trees into mesh scatter system, reducing lines of code and improving performance
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.
A Word About Wobbly Rockets
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.
Ongoing Work for the Science Roadmap Update
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:
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.
Weekly Challenges
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.
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.
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.
Bug Status
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.
Bug Reports Subforum
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!
Weekly Challenges
Last week's challenge produced some very clever Gilly landers dockers, and some very original low-gravity rovers.
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!