Air Bugs

[herbal space program]

Thank you for the update Nate. This all sounds very encouraging with respect to some of the worst bugs affecting playability, and June 20th is not so long to wait, so I'm pretty jazzed. Not having to spam struts all over my wings so they don't snap off will be a very welcome upgrade, as will not having my planes suddenly and irreversibly turn into hideous drag monsters in the VAB for no apparent reason.  One issue that I haven't seen specifically addressed that is really causing me a lot of problems is all kinds of weird stuff happening when I get two large craft within physics range of each other for docking. Often the focused or target craft will just blow up or disappear as soon as I hit the edge of the physics bubble, and even if that doesn't happen, often I'm getting all kinds of weird camera behavior trying to switch back and forth between orbiting craft when they are in physics range. I also often seem to  lose my target selection and then have no ability to properly re-select that target. In KSP1 that was as simple as double clicking on the target or target part in the flight view, but that doesn't seem to work at all in KSP2, and doing so in the map view with two closely spaced ships seems well nigh impossible. Hopefully that one's on the "lesser known" list, because it would sure be great to have a fix for it soon!

[SethM]

Can't wait for patch three!!!

(actually I can )

[jclovis3]

A bug I've experienced so much it tops half of this top ten list IMHO is how landing gear can cause the craft to flip like crazy, even sometimes explode, upon extending if extended at too high an altitude. The workaround seems to be wait until you are close to the ground so I think there is a point of reference issue with this. I have since been avoiding use of landing legs all together as a result. Often, coming out of time warp with legs extended triggers the sudden toss and turn of the ship too. Having legs attached to structural girders and beams makes things worse.

[FlazeTheDragon]

Very exciting update for sure.

The wing joint strength fix is a very smart way of going about things.

Question: will the save file size bug be fixed for existing saves, or will it only apply for new games?

[TFA3393]

3 hours ago, Nate Simpson said:

causing radial decouplers to eject with inconsistent force directions and magnitudes (and messing up our Korolev Crosses).

Oh my gosh I'll be so happy if this is fixed!! I need my symmetry! 

[Alexoff]

4 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.

Oh my God! And where do these fluctuations in the position of parts come from? Have quantum effects been added to the game? How about tunneling kerbals under the surface?

4 hours ago, Nate Simpson said:

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

It seems that many fixes will be software workarounds, which will only complicate further work.

4 hours ago, Nate Simpson said:

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.

How many developers are currently working on KSP2, that there is no one to fix and test such terrible and annoying bugs for 4 months?

[TickleMyMary]

Yet again, I'll believe it when I see it... Get that killer build released, the one you guys just "couldn't" put down before launch.

All these weekly comms are doing for me is showing me how little there is to actually say about a game that just needed 'polishing'... Crazy situation.

[Sylvi Fisthaug]

Thank you for a great update, Nate! Looking forward to the next one. 

[0111narwhalz]

1 hour ago, RocketRockington said:

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. 

Perhaps wings should have more additional nodes displaced "up" and "down" depending on their thickness.

[herbal space program]

31 minutes ago, Alexoff said:

4 hours ago, Nate Simpson said:

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

It seems that many fixes will be software workarounds, which will only complicate further work.

Calculating all the momentum transfers between a  complex tree of dozens to hundreds of elastically coupled rigid bodies through time, so that overall momentum is exactly conserved,  is basically an impossible computational problem, because among other things nature does not have to worry about floating point precision. Any solution to make that work in a manner resembling reality is therefore by definition going to have to involve significant workarounds.

Edited June 9, 2023 by herbal space program

[Alexoff]

6 minutes ago, herbal space program said:

Calculating all the momentum transfers between a  complex tree of dozens to hundreds of elastically coupled rigid bodies through time, so that overall momentum is exactly conserved,  is basically an impossible computational problem

As I have noticed, almost any problem in KSP2 is completely unsolvable and difficult, even one that did not appear in KSP1. I wonder why all these complex oscillations push the craft down and not up? Although, since they are random, the orbit must be stable due to constant wobbles in all directions.

[herbal space program]

1 minute ago, Alexoff said:

As I have noticed, almost any problem in KSP2 is completely unsolvable and difficult, even one that did not appear in KSP1. I wonder why all these complex oscillations push the craft down and not up? Although, since they are random, the orbit must be stable due to constant wobbles in all directions.

The truth is that KSP1 had all kinds of problems with phantom forces, even in the latest version, so that's not really a fair point.  Also, the fact that KSP2 seems to have different problems in  that regard  could perhaps be because KSP2 is trying to increase realism with more complex calculations that go off the rails more easily, or perhaps because whatever physics engine they are using for KSP2 produces errors in those calculations that are not all covered by whatever workarounds they used in KSP1. Either way, fudging the numbers to zero everything out is the only way it is ultimately going to work.

[Nicrose]

Very glad to see the transparency has been staying steady, as well as bug fixes! Gotta admit that I'm not too thrilled at the current cadence/schedule but I'm hoping that gets faster over time. But in the mean time I'm very excited for the next patch!

2 hours ago, RocketRockington said:

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'. 

I think it's important to remember that it's also an approximation of real life.  creating a procedural mesh is a LOT simpler than a procedural rigged mesh with bones and paint weights and if you wanted to do with with blend modes it's also difficult when bringing procedural parts into play. Bending things in games dynamically is not as simple as you may think it is. And even if they did figure that out, is it worth the resources on the computer to calculate the bend depending on the forces? I personally don't believe so and I think that their direction, considering the falling off is a bug, is a great medium to strike when it comes to game vs real life.

[wasml]

Thank you! Looking forward to this patch and next weeks Dev blog.

5 hours ago, Nate Simpson said:

Now, the surface attach node of a wing element is augmented by additional joints

This reminded me of the ReCoupler mod from KSP1. It would be great to see the ReCouple functionality added sometime in the future (post 1.0?) as it would open up additional design possibilities - anyways - just a suggestion!

[RocketRockington]

1 hour ago, 0111narwhalz said:

Perhaps wings should have more additional nodes displaced "up" and "down" depending on their thickness.

Yeah that's what I was suggesting.  Joint rigidity is separate from joint breakage anyway.  It's weird they used 4 joints - 2 would be just as good given where they're placed.  Three or four with two of them above the other joint(s) would give better stability.  That's how KJR does it afaicr.

19 minutes ago, Nicrose said:

I think it's important to remember that it's also an approximation of real life.  creating a procedural mesh is a LOT simpler than a procedural rigged mesh with bones and paint weights and if you wanted to do with with blend modes it's also difficult when bringing procedural parts into play. Bending things in games dynamically is not as simple as you may think it is. And even if they did figure that out, is it worth the resources on the computer to calculate the bend depending on the forces? I personally don't believe so and I think that their direction, considering the falling off is a bug, is a great medium to strike when it comes to game vs real life.

Tbh I don't think they should add wing flex either, given the massive amount of work they have in other places. - but they definitely shouldn't have wings that flop around at their attachment point, that's less realistic than rigid wings.

1 hour ago, herbal space program said:

Calculating all the momentum transfers between a  complex tree of dozens to hundreds of elastically coupled rigid bodies through time, so that overall momentum is exactly conserved,  is basically an impossible computational problem, because among other things nature does not have to worry about floating point precision. Any solution to make that work in a manner resembling reality is therefore by definition going to have to involve significant workarounds.

Yet another good reason they shouldn't have used KSP1s jointed parts system, just to keep the 'lol noodle rockets' hilarity that's only funny for a few newbies who mostly drop the game after an hour or two. 

[Geredis]

3 hours 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.

I'm honestly surprised (not really, but you know what I mean) from how you phrased it, that no one thought "what if someone wants to nudge an orbit with an external vehicle without the use of a docking port" as a very basic contingency that would have to be worked around. It was an extremely common method once upon a time in KSP1 to hook and move satellites, stations, and other ships that had run out of fuel and lacked a docking port or to go around on garbage collection runs when playing without debris limits. 

[herbal space program]

32 minutes ago, RocketRockington said:

Yet another good reason they shouldn't have used KSP1s jointed parts system, just to keep the 'lol noodle rockets' hilarity that's only funny for a few newbies who mostly drop the game after an hour or two. 

My personal feeling is that representing ships you put together in a Lego-like click-on parts format in some real-time manner, which reflects your design decisions in an understandable way, including structural integrity in regard to internal and external forces, is an essential aspect of what made the game so very engrossing for me. I would hate to lose that.  However, if you have some representation of that factor in mind that you think would be better, I'd love to know about it.

Edited June 10, 2023 by herbal space program
typo

[BowlerHatGuy3]

3 hours ago, PDCWolf said:

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.

The wobbliness is too iconic to go in my opinion. I’d rather have a slider in the settings you could adjust.

[stephensmat]

Nate, I'd like to add my appreciation to you and the other Devs for updating us on the how's and where's of buxfixing. Talking about progress is always preferable to long silences.

The really good news is that when we get to the expansion stages, all these bugs will be fixed at the coding level. While I imagine Science and Colonies will have their own bugs to patch, we won't have to worry about stable orbits and SOI glitches again.

[Scarecrow71]

6 hours ago, Nate Simpson said:

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)

This is my biggest pain point in the game.  I am so very glad you guys are working on this, and I can't wait to get the next patch so we can see if this is finally fixed.

With that said, @Nate Simpson, are there any updates on when we can maybe start to expect Science in the game?  Thus is the only topic I didn't even see you touch on, and one of the things you mentioned last week would be part of your weekly updates.

[Stewcooker]

Glad to see that a lot of these bugs are being fixed in the next update!

The transparency on the bugs is greatly appreciated, it helps everyone see how tough some of these issues are to solve. I would like to see something similar on the upcoming features.

For example, how's Re-Entry Heating coming along? What are the particular blockers or pain points the team is encountering? Are they artistic in nature, or is there an issue with calculations? Maybe Unity-based? I imagine trying to figure out which GameObjects are occluded from heat and those that aren't in a performant way might be a particularly tough nut to crack. But then again, I can see how the Phantom Drag bug could have impeded progress on the heating problem as well, since if parts are causing drag it's probably influencing heating as well.

[RocketRockington]

50 minutes ago, herbal space program said:

My personal feeling is that representing ships you put together in a Lego-like click-on parts format in some real-time manner, which reflects your design decisions in an understandable way, including structural integrity in regard to internal and external forces, is an essential aspect of what made the game so very engrossing for me. I would hate to lose that.  However, if you have some representation of that factor in mind that you think would be better, I'd love to know about it.

Plenty of ways have been discussed previously.  To summarize, there's a bunch of ways to give feedback in a way that's more realistic, performant, and interesting:

1. Have a rigid body forces simulation (eg: Polybridge, among many games that do something similar.  Many games with far less investment pull this off) that determines strain between rigidly attached parts.
2.  Have the parts that are reaching their limits give off some feedback - sound, visual crinkling, etc.  Add debug UI or in-game telemetry visualization for more precise info.
3.  Just like KSP does now, break up the ship when tolerances are exceeded.  

[Redneck]

@Nate Simpsonthank you for the info nate appreciate it!

[PDCWolf]

1 hour ago, herbal space program said:

My personal feeling is that representing ships you put together in a Lego-like click-on parts format in some real-time manner, which reflects your design decisions in an understandable way, including structural integrity in regard to internal and external forces, is an essential aspect of what made the game so very engrossing for me. I would hate to lose that.  However, if you have some representation of that factor in mind that you think would be better, I'd love to know about it.

Jointed stacks don't wobble in real life. Try making a really tall stacks of blocks, books, whatever, and even without a joint they won't slide, as the friction of flat surface against flat surface pretty much prevents that. At some point, they might slide off each other and fall, but not wobble. Wobble is not an analogous to real life structural integrity, much less that of a vertical stack of equal elements.

1 hour ago, BowlerHatGuy3 said:

The wobbliness is too iconic to go in my opinion. I’d rather have a slider in the settings you could adjust.

Many things are iconic, most iconic things in the history of humanity, the ones everybody knows of, are not good. Wobble is not a carefully programmed mechanic, or a "design choice", it's the shortfall of using Unity's one-size-fits-all joint system, clearly not made for self-colliding stacks of lego-like parts. This is even more evident when you consider the same reason that caused self-craft collisions in KSP1 to be disabled and then become optional in Breaking Ground is almost the exact same reason they're about to be turned off in KSP2 again.

[RocketRockington]

48 minutes ago, Scarecrow71 said:

This is my biggest pain point in the game.  I am so very glad you guys are working on this, and I can't wait to get the next patch so we can see if this is finally fixed.

With that said, @Nate Simpson, are there any updates on when we can maybe start to expect Science in the game?  Thus is the only topic I didn't even see you touch on, and one of the things you mentioned last week would be part of your weekly updates.

He mentions having 3 engineers working on just one bug in a prior update.  Given that - even if the other bugs are only getting one person a piece working on them - and given that these bugs have to be the top priority (not to mention the more minor bugs that are likely to be included in the patch) - do you really thing they have any spare engineering capacity to do anything else? 

You can see from the slow progress week on week that the bugs here aren't the quick-fix deluge they gave us in the first two patches.   It's good that it seems they'll have tackled 5 or 6 of the top 10 after 2+ months of additional work since patch 2  - but it also likely means that science has likely seen no attention from engineering.  That's why they're giving us random parts vs new gameplay systems - and why heating, which apparently only needed some polish work 3 months ago, isn't announced for this update either.