Wobbly Rockets with David 'Trigger' Tregoning - KSP2 Dev Chat

[Intercept Games]

 

[Nate Simpson]

I hope you enjoyed this chat! Since this conversation took place, David has been developing a tool that allows our team to compare multiple wobbly rocket remedies, including selective wobbliness for certain part categories, KSP1-style autostrut for the entire vehicle, and various flavors of packed vehicle physics. We are testing these now, with the goal of achieving a near-term improvement in vehicle rigidity while developing a more ambitious long-term fix that's performant at all scales. We'll post more information when we've arrived at a balanced solution.

We know you've waited a long time for a solution to this issue, and we're excited to be closing in on a resolution.

[AtomicTech]

30 minutes ago, Nate Simpson said:

I hope you enjoyed this chat! Since this conversation took place, David has been developing a tool that allows our team to compare multiple wobbly rocket remedies, including selective wobbliness for certain part categories, KSP1-style autostrut for the entire vehicle, and various flavors of packed vehicle physics. We are testing these now, with the goal of achieving a near-term improvement in vehicle rigidity while developing a more ambitious long-term fix that's performant at all scales. We'll post more information when we've arrived at a balanced solution.

We know you've waited a long time for a solution to this issue, and we're excited to be closing in on a resolution.

WOOOOHOOOOOOOO!

[MarcAbaddon]

48 minutes ago, Nate Simpson said:

I hope you enjoyed this chat! Since this conversation took place, David has been developing a tool that allows our team to compare multiple wobbly rocket remedies, including selective wobbliness for certain part categories, KSP1-style autostrut for the entire vehicle, and various flavors of packed vehicle physics. We are testing these now, with the goal of achieving a near-term improvement in vehicle rigidity while developing a more ambitious long-term fix that's performant at all scales. We'll post more information when we've arrived at a balanced solution.

We know you've waited a long time for a solution to this issue, and we're excited to be closing in on a resolution.

Just my 5 cent, but showing that tool with a bit of explaining text and a few pictures would likely be much more informative than this talk was, which just repeated points that were made in the past. And it would be a more convincing demonstration that there is progress and not just talk - the issue with these talks is that people (rightfully or not, different discussion) feel that past communication hasn't bee reliable.  

[ChrisShourai]

Without sounding like a hypocrite from other posts I’ve made about a lack of communication, I’m pretty shocked the dev chat concluded with no solid fix/answer, or overall insight beyond ‘we’ve got some parallel solutions / could do auto-strut now / working on something for the future.’

@Nate Simpson do you have even a remote idea when either a temp or the long term fix might be realized? 

[regex]

Please don't implement autostrut, it completely trivialized KSP1. Similarly, it would really suck if a craft was treated as a single rigidbody.

What I think could work pretty well would be node-to-node welding of similar size, so a 2.5 -> 2.5 node would weld but a 1.25 -> 2.5 node wouldn't weld. Makes adapters useful, makes a sort of intuitive sense, reduces rigidbodies, doesn't mess with wheels (if they're surface attached)... Naturally this wouldn't apply between decouplers.

vOv At least you guys aren't taking the easy out.

Edited September 29, 2023 by regex

[chefsbrian]

On 9/27/2023 at 8:33 PM, chefsbrian said:

As long as the discussion is about the changes being done to solve the current issues with rockets flopping all over, I'll be overall happy - whether I'm happy with the specific changes or timelines is a different story, but I'll consider it progress if my displeasure is regarding when and how, as opposed to whether its even getting touched. However, if this is the equivalent of the heat system dev blog, a whole lotta words telling us "Wow its hard but we'll totally get it eventually" and just leaving it at that, I will not be happy.

So, "Wow its hard but we'll totally get it eventually". As promised, I am not happy.

You have all these options, can you please stop being so scared of making the 'wrong' choice that you end up making none at all? Your here to make a game, not make perfection, do not let perfection get in the way of good enough. Turn on one of the options that works right now, with the full disclosure that its probably not what you want right this second and it's liable to get replaced.

[Nate Simpson]

17 minutes ago, ChrisShourai said:

 

@Nate Simpson do you have even a remote idea when either a temp or the long term fix might be realized? 

I have a very strong idea when the short-term fix is likely to materialize, but the complexity of this game has a way of turning "low-risk" predictions into misstatements. To my eyes, it feels very close. But there are always questions that can only be answered by testing (which for a game like this can take time). Does it work in all situations? Does it introduce new bugs? Does it break a seemingly unrelated system in a hard-to-detect way? I'm reminded of how the joint reinforcement technique we introduced for a narrow subset of parts created an initially subtle but ultimately game-breaking fuel flow bug that flew under the radar for weeks. 

What I can say, without fear of misrepresenting things, is that it's a priority task for our most senior developers, and it is internally our most-wanted fix right now.  We released this video to underscore that it's a priority for us and that we're approaching the problem with the nuance and openness that it deserves. Our goal here, given requests we've seen here for greater transparency, was to provide more visibility into the way we navigate the sometimes complicated terrain of requirements presented by this game.

[whatsEJstandfor]

I'm loving the dev chat format! More of this! And I love hearing engineers talk about the nuts and bolts of the issue!

That being said, I'm not sure what we learned that we didn't already know. We already knew it was a complex issue and that different solutions have pros and cons. Couldn't that be said about literally every choice made during development? Nate's follow-up post is encouraging but, yet again, it's a case of telling us rather than showing us. 

It's good to know, though, that many solutions are presumably being explored deeply, and I'm excited to see what the ultimate one chosen is!

Edited September 29, 2023 by whatsEJstandfor

[The Aziz]

2 minutes ago, Nate Simpson said:

the complexity of this game has a way of turning "low-risk" predictions into misstatements.

Not to mention when the community turns the misstatements into "broken promises" and all hell is let loose.

[Nate Simpson]

In case people are wondering why I listed "wobbly rockets" as our current top bug and not "orbital decay," it's because a hotfix just went out (38 minutes ago) that not only fixes the recently-detected registry bug, but also addresses the orbital decay issue.  It's a huge relief, both as a developer and a player, to have this finally squared away:

 

[cocoscacao]

18 minutes ago, Nate Simpson said:

I have a very strong idea when the short-term fix is likely to materialize

Just out of curiosity, why bother with short-term solution if it's gonna end up in the trash can eventually, but consume so much effort and time?

[Stewcooker]

"You could turn off all the joints, single rigidbody,, but then you lose some of that novelty..." I feel like "wobbly rockets" aren't an interesting "novelty", they're inaccurate and immersion breaking. Yes KSP prides itself on being cartoony and accessible, something I feel like the dev team may have leaned a little too hard into at times, but at the end of the day this is a physics-based sandbox game trying to emulate real-life rocketry, and in real life rockets don't wobble or bend when they encounter shear forces, they break. Often catastrophically. At this point my vote is to echo what @regex says and implement node to node welding of parts of the same size or cross section. You can still calculate shear forces and aerodynamics per part, and if shear forces reach a certain threshold, *bam*, explode the part, decouple the nodes, and then you've got a realistic emulation of a rocket.

And @Nate really hits the nail on the head around the 4 minute mark when he says "When a player sees a rocket, if the structure itself appears to be unitary....you'd sort of expect all those cylindrical elements to basically be constructed as one solid piece" (paraphrase). I agree, that is what I expect, but beyond that, its what I saw when SpaceX launched their 397 foot tall, 11 million pound Starship on it's first test flight. I saw that rocket tumble, fall sideways, and then the FTS kicked in and exploded the rocket, all without the slightest bit of (observable) flex or bend. Yes, I agree that lateral nodes with a cantilevered weight out on the end should experience some bend, but the core of my rocket should, as Trigger so eloquently put it, "Fly straight and true like a brick house".  

I think the team is getting there, I know they're really putting a lot of work into finding an implementation that includes the best of both worlds. But I have to wonder two things:

1. Is finding one solution for all the parts across the board worth it, or would it be easier to have different physics for different parts? Whereby i mean a vertical stack of tanks behaves as one rigidbody, but nodes attached laterally or with a docking port experience the same kind of wobble we have built in now?

2. Why are these questions and solutions just now being discussed when the initial release date was early 2020?

[regex]

2 minutes ago, cocoscacao said:

Just out of curiosity, why bother with short-term solution if it's gonna end up in the trash can eventually, but consume so much effort and time?

Not to mention if it creates a false expectation in the playerbase, which will absolutely happen no matter how many warnings to the contrary...

[Nate Simpson]

9 minutes ago, cocoscacao said:

Just out of curiosity, why bother with short-term solution if it's gonna end up in the trash can eventually, but consume so much effort and time?

This is a great question. We're aware that the people who have chosen to play the game in Early Access have done so because they want to have fun (while participating in the evolution of the game). There continue to be some bugs that are active obstacles to fun - these are distinct from bugs related to polish, presentation, or ease of use. Fun-killing bugs have to go to the top of the pile. Thankfully, the process of settling on a joint rigidity solution isn't made all that much more difficult by running through the potential remedies and recognizing that one of the lower-cost choices could make the game more fun for people while the extensible, interstellar-friendly version is under construction.

[Periple]

I very much liked Nate’s vision of how it should be: stacks are rigid but surface-attached masses flex.

If it was me I’d probably just make all joints except surface ones rigid and then refine it from there.

[cocoscacao]

2 minutes ago, Nate Simpson said:

lower-cost choices could make the game more fun for people while the extensible, interstellar-friendly version is under construction.

This game has been under development for a long time (officially). I fear that short-term solution may cause additional bugs, forcing dev team to waste time hunting and fixing issues that shouldn't be there in the first place. I don't mind waiting a little longer if I'm being honest.

Hopefully, you guys (and ladies) made the right call. Best of luck with it.

[chefsbrian]

1 minute ago, cocoscacao said:

This game has been under development for a long time (officially). I fear that short-term solution may cause additional bugs, forcing dev team to waste time hunting and fixing issues that shouldn't be there in the first place. I don't mind waiting a little longer if I'm being honest.

That's not really how it works. The dev team doesn't really waste time hunting and fixing bugs - The bugs will, for the most part, exist regardless for a given feature set, the question is whether the dev/qa team catches them proactively, or after launch. Either way, they spend the same amount of time actually fixing things. Being over aggressive trying to paper everything out to try and spot bugs before code enters the system can be counter productive, as most bugs are based on false assumptions (IE This resource will be available, this system won't produce bad output, this function produces this kind of output reliably) that stem from developers simply not being able to know every detail of every aspect of the vast codebase of a game. Flawless resource management might reduce some of that by making sure the expert/veteran in a given section of the code is available for a given change, but nobody is perfect, and the veteran in one space is often the veteran in many, so its triage - someone's gonna end up working with stuff they're unfamiliar with, all the time.

A good QA can help make sure more of those bugs and bad assumptions are caught in the pre-launch window rather than the post-launch window, but you generate bugs regardless, and spend time fixing them regardless. Just the nature of the beast.

The alternative is to just not develop a feature at all - But until you develop it, you have absolutely no idea what the possible time commitment required for error fixing will be. And sometimes it can turn out to be a complete nothingburger - You might have your experts spend hours theorycrafting issues to watch for an address, only for absolutely none of them to manifest because, to quote a master of 'good enough' game developing, "It Just Works". Letting that uncertainty prevent you from attempting action is how you get nowhere with a project. Its about deciding which risks you want to take, rather than none at all. 

[Mikki]

Excellent audition 

Edited September 29, 2023 by Mikki
oh them typos

[cocoscacao]

17 minutes ago, chefsbrian said:

That's not really how it works. The dev team doesn't really waste time hunting and fixing bugs - The bugs will, for the most part, exist regardless for a given feature set, the question is whether the dev/qa team catches them proactively, or after launch. Either way, they spend the same amount of time actually fixing things.

Not really sure I understood ya there. Take Nate's statement itself:

1 hour ago, Nate Simpson said:

Does it introduce new bugs? Does it break a seemingly unrelated system in a hard-to-detect way? I'm reminded of how the joint reinforcement technique we introduced for a narrow subset of parts created an initially subtle but ultimately game-breaking fuel flow bug that flew under the radar for weeks. 

By introducing short-term solution, you may or may not create a bug in a seemingly unrelated system... thus wasting time trying to fix that system... You eventually end up realizing you shouldn't care... but time went into it, instead of focusing on long term solution. 

Edited September 29, 2023 by cocoscacao
typos

[Alexoff]

1 minute ago, cocoscacao said:

By introducing short-term solution, you may or may not create a bug in seemingly unrelated system... thus wasting time trying to fix that system... You eventually end up realising you shouldn't care... but time went into it, instead of focusing on long term solution.

A long-term solution may also add bugs. In general, any change in the game can create an unpredictable number of bugs. It seems to me that if the developers could predict what kind of bug this or that solution might cause, they would probably do it right away without any bugs.

 

I actually didn't really understand the point of the video. That there is a problem, they know about it and are working on it, we already knew that. I thought we would be shown in practice in the game itself some attempts to solve the problem one way or another.

[MechBFP]

1 hour ago, regex said:

Please don't implement autostrut, it completely trivialized KSP1. Similarly, it would really suck if a craft was treated as a single rigidbody.

The problem I am seeing is that a lot of people automatically assume "My craft wobbles, that is why I failed!" rather than "My craft failed because I designed it like garbage!"

Good luck convincing people of the later rather than the former.

For those people autostrut didn't trivialize the game, it made the game playable for them.

Edited September 29, 2023 by MechBFP

[chefsbrian]

7 minutes ago, cocoscacao said:

By introducing short-term solution, you may or may not create a bug in a seemingly unrelated system... thus wasting time trying to fix that system... You eventually end up realizing you shouldn't care... but time went into it, instead of focusing on long term solution. 

My point is that the long term solution is not somehow immune to that either. Both have the exact same risks per change made. The difference between a long term solution and a short term solution is magnitude - a long term solution is usually considered long term because you have to do a lot of things to make it happen, meaning a lot of change work, a lot of resultant errors, and a lot of fix work. The short term solution is the thing you can do with a far lower magnitude of changes, so far less immediate effort and far less things being touched that could break. So you can get it out in a measure of days or weeks, not months, even when things catch on fire.

Its also not really representative to think of the time spent on the short term solution as simply wasted effort that should be spent somewhere else. Both the short and long term solution for a given space address mostly the same general systems - If there's an underlying physics occlusion bug (Completely made up) that's impacting joint rigidity, then that issue is going to be encountered regardless of whether you're doing a quick change or an in depth one. Unless your short term solution is bizarrely and fantastically out of line from the long term goal, they're walking the same code paths and are gonna hit many of the same issues.

[cocoscacao]

2 minutes ago, chefsbrian said:

they're walking the same code paths and are gonna hit many of the same issues.

Ehr... Maybe? In some cases? I get your point now, but I don't agree completely.

[shdwlrd]

24 minutes ago, MechBFP said:

The problem I am seeing is that a lot of people automatically assume "My craft wobbles, that is why I failed!" rather than "My craft failed because I designed it like garbage!"

Good luck convincing people of the later rather than the former.

For those people autostrut didn't trivialize the game, it made the game playable for them.

So much this... Don't get me wrong, auto struts was useful in certain situations for experienced players. (Ex. Large to huge space planes.) But it doesn't need to be a crutch for bad design choices.