Air Bugs

[Nate Simpson]

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 20 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 about exactly what fixes and changes will be present in the update. As always, we’ll share detailed patch notes before 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 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 (at time of writing, there is a rumor that we've fixed this, but this news is so hot off the presses that I won't update the status quite yet. If it is in fact fixed, it will make its way into the 0.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 a fix has eliminated the runaway filesize 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 a significant impact on PAM deployment lag. 
      
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...

Wings be poppin'

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 large, 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:

Magenta 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 Callahan and the Community Team were continuing to add new functionality to the Bug Reports Subforum. 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 Challenge

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! Here are your goals:

• Primary goal: land a habitat that can hold at least 20 kerbals on the surface of the Mun or Minmus. It should have solar panels and at least one antenna
• Secondary goal: Near your initial habitat, land a pressurized rover that can hold at least 6 Kerbals, and land an observation tower that is as tall as possible (for scanning the horizon for interesting rocks from the comfort of a sofa or beanbag chair)
• Jeb-level goal: Use the same transport vehicle design (booster, transfer stages, sky crane, etc.) to deliver each of the above base elements
• Val-level goal: Build this base on a body outside Kerbin's sphere of influence.
• Tim C-level goal: Build this base within 1km of a unique point of interest (e.g. the mohole, Dres canyon, Vall crevasse, etc.)

Good luck, space campers!

P.S.: The title of this post is not my fault. Please blame our Art Director, Kristina Ness. 

[Spicat]

Finally, a date

[Astro648]

epic

[Acid_Burn9]

2 hours ago, Nate Simpson said:

A system is now being crafted to prevent orbital velocity changes when a vehicle is not under thrust.

But what if a collision with another object happens? A stage separation? The vehicle being affected by an exhaust of another vessel? Thrust is not the only way to change trajectory.

I really hope the system in question here is not as primitive as described.

Edited June 9, 2023 by Acid_Burn9

[Clayel]

Any update on some fundamental problems that involve reusing or reimplementing similar or the same code from KSP 1? I've heard a lot of systems have not changed at all.

[The Aziz]

I like how you indirectly answered my question under the last post about predicting when which fixes arrive.

Also

2 hours ago, Nate Simpson said:

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.

I think that's indeed the way to go. The manager should be as flexible as possible, including pinning, filtering, scaling etc. It's a long way to go for sure but looks like you're off to a good start.

[schlosrat]

2 hours ago, Nate Simpson said:

Issue 1 - Vehicles in stable coasting orbits sometimes experience orbit instability/decay

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 v0.1.3.0 update, but we know what’s wrong and the steps to fixing it are well understood.

Issue 2 - Trajectories change when vehicles cross SOI boundaries

Engineers believe they understand the cause of this issue and are working on a comprehensive solution (at time of writing, there is a rumor that we've fixed this, but this news is so hot off the presses that I won't update the status quite yet. If it is in fact fixed, it will make its way into the 0.1.3.0 update)

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

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.

LOL! The reason for degrading orbits is hysterical! Have we not told you that rockets are too wobbly!? It will be delightful to see this one quashed, and I thank you from the bottom of my wobbly pilot's seat for all the hard work the team has put in on this.

And for issue 2: Hurray! This is truly great news! I hope your solution pans out. This will make the game far more fun to play!

Looking forward to Chris's dev blog!

Edited June 9, 2023 by schlosrat

[Nate Simpson]

2 minutes ago, Acid_Burn9 said:

But what if a collision with another object happens? A stage separation? A vehicle being affected by an exhaust of another vessel?

 I really hope the system in question here is not as primitive as described.

Excellent question. Actually, there is an analogous system in KSP1 that works similarly. Off the top of my head, I don't know how it handles decoupling or other non-propulsive physics events. This may require a scalable solution that can be expanded to include edge cases (for example, the effects of stage separation), but the current effects of which are so profoundly game-impacting that a simpler approach gets us to more stable footing sooner. My short-term goal for this feature is KSP parity. That said, I'll bring up your concerns the next time I chat about this with an engineer.

[Vortygont]

I'm happy to hear about fixing wing detachment bug, it destroyed all my heavy SSTOs. I honestly saw by plane behaviour that wings don't have sufficient amount of joints to behave realistically and reported this problem.  I hope to get additional fixes for plane bugs so I will start to really enjoy planes!

UPD
I understood that after update I won't attach my wings with struts for better durability, finally so conveniently

Edited June 9, 2023 by Vortygont
Sruts mention

[ahmed4363]

8 minutes ago, Acid_Burn9 said:

But what if a collision with another object happens? A stage separation? A craft being affected by an exhaust of vessel?

 I really hope the system in question here is not as primitive as described.

I think this is just a quick explanation of what this system would do, not exactly what it does. Basically a TL;DR of the system

[DerpyAintHere]

I love ksp2 to much to be mad at the patch 3 release date. Cant wait!

[S_Coriolis]

Stop praising me or I'll send Megamaid to remove all the air in your office and I don't think you want to mess with her 

[TheKSPGuy]

While I'm pretty disappointed that issue 1 is likely not being fixed for another couple of months, I am happy that several game-breaking and major annoyances are being fixed. I, and probably many others, would appreciate a hotfix ASAP for orbits changing randomly whenever you do get that sorted out.

I'm really happy to hear the team has taken our concerns over floppy rockets and falling wings seriously, and will be fixing this in the next few weeks. I'm excited to try out my fighter jet replicas when the update releases.

[LunarMetis]

That release date's not too far away at least. Are you guys planning on speeding up update cadence once KSP2's on a more stable foundation?

[Socraticat]

I did manage to Circumnavigate all of Gilly last week. Here's a link to the end of the run:

 

Edited June 9, 2023 by Socraticat
Changed link to relevant timestamp

[RocketRockington]

2 hours ago, Nate Simpson said:

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 large, 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:

 

This fix seems like it's only going to address the wings falling off in one direction - from drag - rather than helping with forces in the dorsal/ventral direction.   Maybe try triangulating those joints a bit, or you'll just continue to have wings that flap like a bird's.

2 hours ago, Nate Simpson said:

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

Way to throw QA under the bus for that .1 release.

[Nate Simpson]

2 minutes ago, RocketRockington said:

This fix seems like it's only going to address the wings falling off in one direction - from drag - rather than helping with forces in the dorsal/ventral direction.   

This is by design: we are not trying to create a system in which wings never fail. We just don't want them to fall off inexplicably. Please take the new system for a spin and let us know if you think it's still producing frustrating results!

[The Aziz]

7 minutes ago, S_Coriolis said:

Stop praising me or I'll send Megamaid to remove all the air in your office and I don't think you want to mess with her 

All we need is some ear-sized RV and a bit of Schwartz

[MarcAbaddon]

12 minutes ago, Nate Simpson said:

Excellent question. Actually, there is an analogous system in KSP1 that works similarly. Off the top of my head, I don't know how it handles decoupling or other non-propulsive physics events. This may require a scalable solution that can be expanded to include edge cases (for example, the effects of stage separation), but the current effects of which are so profoundly game-impacting that a simpler approach gets us to more stable footing sooner. My short-term goal for this feature is KSP parity. That said, I'll bring up your concerns the next time I chat about this with an engineer.

Can't speak towards all cases, but generally KSP 1 handles this in a very solid manner, with no random orbital decays but 'pushing' vessels with Kerbals on EVA working (the physics breaking parts of pushing Kerbals was the effectively infinite fuel, not that pushing works in principle). Decoupling also worked ok and changed your orbit a bit.

 

Is it only me remembering this, but was there talk earlier about the orbital decay having to do with coordinate system switches? Was this incorrect, or are there two issues with orbits?

[PDCWolf]

Issue 1 sounds like a literal repeat of something that happened in KSP1, with same-craft collisions and joint mess caused phantom forces.

Issue 2 indeed sounds like racing/MT issues (specially considering you've kept data on this a bit more secret).

Issue 6 seems a tamer version of the Multi-Docking Crash (still unaddressed even though it's a release bug), where docking vessels through more than a single port causes a massive spam on the logfile, to the point the game crashes.

Issue 7 looks really obvious in hindsight: "Yeah let's make a panel that lists everything on the ship at once" "wow it causes lag"

Issue 10 (and 1) should probably clue you in on the fact wobbliness needs to disappear. It is not realistic, nor it is an abstraction of, or analogous to any realistic phenomena. It also seems the same system is responsible for wings popping off, which also seems like it is getting an improper fix since you're considering only the drag force. I hope the "falling off" ends up appropriate to acting forces on all directions.

Congrats and a golf clap on all the improvements made to the bug subforum. It now needs a good standard and continuation of proactive and proper responses to posted bug reports (acknowledged, worked on, and such).

 

[The Diamond Gear]

Wow, the transparency and depth of this Dev Update gives me hope that this game isn't going to be lost in early access.

I am especially exited to see the wings shearing off bug getting addressed, as I have suffered from losing many Space plane and SSTO designs to it. Now that I see that most of the major issues I have experienced with the game so far are already being fixed, I am hopeful for a bright future exploring the beautiful expanse of the Kerbolar system!

PS: I am definitely going to enjoy doing this weekly challenge, as I love building planetary bases, especially on Minmus.

[S_Coriolis]

1 minute ago, The Aziz said:

All we need is some ear-sized RV and a bit of Schwartz

Do it

[whatsEJstandfor]

I am extremely stoked to see this format of dev blog becoming the norm, and I love getting insight into how subtle the issues that cause these big bugs are! I can't wait until the next patch drops, and especially can't wait to see what's coming after that!

[schlosrat]

Personally, I'm over the moon about the Issue 2 status! And by over the moon, I mean able to depart from the Mun's SOI and get a trajectory that will swing me close by Kerbin... Say, a nice 90km Pe perhaps?

[RocketRockington]

24 minutes ago, Nate Simpson said:

This is by design: we are not trying to create a system in which wings never fail. We just don't want them to fall off inexplicably. Please take the new system for a spin and let us know if you think it's still producing frustrating results!

I guess we'd need to see it in practice, but there's a reason wings are attached on real aircraft to the Wing Box.  Not the wing plank, or wing -infinitely-narrow-plane, but the box.   Because there's rigidity in all directions.  Wings do flex, but not at the root like they're attached to a hinge, but along their span.

And in general you've erred FAR too far in the direction of "LOL everything falls apart so easy" so far, according to the majority of the community, so I don't really trust the direction of 'yeah we just want things to fall apart anyway, oh so Kerbal'.