Rocket noodling? Oh gods, not again...

[angelatthetomb]

They'll figure it out. Noodly rockets were absolutely atrocious in pre-.2 KSP1 (ten years ago...Jesus I'm getting old...). These days I've forgotten entirely about that, don't even use autostrut, and my rockets don't wobble.

 

Remember the part where it's an Alpha?

[Jarin]

26 minutes ago, angelatthetomb said:

They'll figure it out. Noodly rockets were absolutely atrocious in pre-.2 KSP1 (ten years ago...Jesus I'm getting old...). These days I've forgotten entirely about that, don't even use autostrut, and my rockets don't wobble.

 

Remember the part where it's an Alpha?

Remember the part where it's a sequel, not a rollback to KSP 0.25 with a graphics overhaul? We were hoping for a physics overhaul too, like was suggested throughout development, not the same noodle-rockets and clippy rover wheels we had eight years ago

[magnemoe]

49 minutes ago, angelatthetomb said:

They'll figure it out. Noodly rockets were absolutely atrocious in pre-.2 KSP1 (ten years ago...Jesus I'm getting old...). These days I've forgotten entirely about that, don't even use autostrut, and my rockets don't wobble.

Remember the part where it's an Alpha?

I remember back with the old aerodynamic, back then an major problem was that putting 3 orange tanks on top of each other would collapse because the tanks was weak. This was an major reason asparagus was so popular, tall rockets was an problem and side boosters could help support the load. It was not only because of drag, getting 2 g close to burnout would cause this.  Else I agree with others for most part rockets should not bend, and if they bend they should fail, an 25 meter tall 1.25 wide rocket would have an problem but larger diameter would not. 
Its one exception and that is payload who is not well supported,  
Also long side boosters will flex around the joint unless strutted at top. 
 

[J.Random]

And of course, asparagus had its own issues with the bending, like uncontrolled roll because engine gimbaling would torque the side boosters. Devs borrowed quite a lot from mods, but somehow managed to skip KJR.

[TackleMcClean]

To be asking the devs to implement autostruts seems like such a bandaid treating only the symptom and not the actual problem.

Why should the player care about struts? How should it care about them? When?

All of these are questions that better have a thought out design choice behind them, and what we've seen so far indicates the development is recreating KSP1 physics - quirks and Kraken included - rather than starting with a clean slate and asking such game design questions.

Sure there might be some "charm" to wobbly rockets in a "oh you silly Kerbals" kind of way, and a game with this kind of following will definitely draw out the nostalgia in people. When it comes to personal preference though I am strongly in the corner of realism over quirkiness. The most fun I've had with KSP1 is in RO/RSS designed reusable launcher designs and not wobbly rockets.

I hope the development team can steer this in the right direction, even if it is VERY worrisome that what's shown so far is a very similar to KSP1 but with abysmal performance.

My current hope lies with the modding community to fix a lot of these issues but they can't fix everything at the core level.

[Chilkoot]

15 minutes ago, TackleMcClean said:

Sure there might be some "charm" to wobbly rockets in a "oh you silly Kerbals"

There was charm to it when all you could do in KSP was launch and de-orbit.

Once progression modes were added and launches mattered, noodle rockets and the Kraken stayed "cute" like the grown-up dog that still nips and pees on the carpet.

[tstein]

14 hours ago, TackleMcClean said:

To be asking the devs to implement autostruts seems like such a bandaid treating only the symptom and not the actual problem.

Why should the player care about struts? How should it care about them? When?

All of these are questions that better have a thought out design choice behind them, and what we've seen so far indicates the development is recreating KSP1 physics - quirks and Kraken included - rather than starting with a clean slate and asking such game design questions.

Sure there might be some "charm" to wobbly rockets in a "oh you silly Kerbals" kind of way, and a game with this kind of following will definitely draw out the nostalgia in people. When it comes to personal preference though I am strongly in the corner of realism over quirkiness. The most fun I've had with KSP1 is in RO/RSS designed reusable launcher designs and not wobbly rockets.

I hope the development team can steer this in the right direction, even if it is VERY worrisome that what's shown so far is a very similar to KSP1 but with abysmal performance.

My current hope lies with the modding community to fix a lot of these issues but they can't fix everything at the core level.

Removign the wobble can be made in a form that makes the game more realistic AND  uses less CPU. Just merge all tanks stacked of same diameter into a single tank. OR GIVE US THE DAMN PROCEDURAL TANKS!

 

One thing I find absurd in general is most of the CPU   used in KSP is there to simulate something that is an ERROR of the early classic KSP, that  is detrimental to the gameplay and then we need an external feature to cancel it. That is pure absurd.

[J.Random]

3 minutes ago, tstein said:

Just merge all tanks stacked of same diameter into a single tank.

NO.

Fuel flow manipulation within a single stage is a thing. Merging tanks together will break it.

[Movado]

13 hours ago, Chilkoot said:

There was charm to it when all you could do in KSP was launch and de-orbit.

Once progression modes were added and launches mattered, noodle rockets and the Kraken stayed "cute" like the grown-up dog that still nips and pees on the carpet.

Exactly. The noodling, consequent low frame rate and the Kraken put an end to my desire to do more in KSP 1. Even with autostrut, some of my biggest projects (such as a massive Planetary Base System rocket) could barely hold it together through launch. Once assembled, the Kraken often tore the base apart on load.

To see these issues reappear at the first public showing of KSP2 is massively disheartening. It shows that the programmers in charge of the crucial aspects of KSP2's spacecraft simulation have learned precious little from the development of KSP 1.

[tstein]

5 minutes ago, J.Random said:

NO.

Fuel flow manipulation within a single stage is a thing. Merging tanks together will break it.

 And WHEN  did anyone  manipulated the flow in any form other than   use upper parts before lower ones? That is a non issue at all.

[J.Random]

Just now, tstein said:

 And WHEN  did anyone  manipulated the flow in any form other than   use upper parts before lower ones? That is a non issue at all.

Do I really have to explain it? This is kinda basic thing to do in KSP1 (especially with FAR) not to overengineer the rocket with stupid amount of stabilizing fins.

You got it backwards. You drain the top tank in the same stage _last_, to keep CoM at the top, above CoL and providing enough leverage to the engine for gimbaling to keep you on course.

[tstein]

4 minutes ago, J.Random said:

Do I really have to explain it? This is kinda basic thing to do in KSP1 (especially with FAR) not to overengineer the rocket with stupid amount of stabilizing fins.

You got it backwards. You drain the top tank in the same stage _last_, to keep CoM at the top, above CoL and providing enough leverage to the engine for gimbaling to keep you on course.

I do the exact opposite for the same reasons with   perfect success rate..    I will let  as an exercise for you to figure out why   that is how things are done in real world..

 

also  REaction wheels  cannot hold your rocket  straight in KSP 2 anymore....

[J.Random]

Just now, tstein said:

I do the exact opposite for the same reasons with   perfect success rate..    I will let  as an exercise for you to figure out why   that is how things are done in real world..

You're moving CoM _down_ to stabilize your rockets during launch? And it works? Either you're the one overdoing it with reaction wheels, or you're lying. Moving CoM down, closer to the engines, never helped stability in KSP1. Ever. Be it Vanilla or FAR. That's how you get rockets tumbling out of control, trying to fly backwards.

[tstein]

2 minutes ago, J.Random said:

You're moving CoM _down_ to stabilize your rockets during launch? And it works? Either you're the one overdoing it with reaction wheels, or you're lying. Moving CoM down, closer to the engines, never helped stability in KSP1. Ever. Be it Vanilla or FAR. That's how you get rockets tumbling out of control, trying to fly backwards.

No  it is not the UP or down  that control  it.. it is the torque arm  difference between the  drag and the  mass center.   you cannot  look at only one arm to solve the system minimally.

[J.Random]

It's the same bloody rocket, if the total length is X and one arm is Y, the other one is X-Y, for crying out loud, was, is and will remain to be so. So yes, I can confidently say that when you move CoM down, closer to the engine, you're reducing the torque available through engine gimbaling, while at the same time increasing the torque resulting from any AoA>0 (which also creates positive feedback loop, btw). As I said already, it's trivial.

[cfds]

There is no technical reason to have a set of tanks with their own CoMs that combine to a rigid body where the CoM moves accordingly to the fill state of the single tanks. Unless you are just trying to ride the coat tails of Unity...

[J.Random]

I already gave one. Another one would be spaceplane/shuttle configurations, for which you may want different CoM positions during launch and descent. It was at least insinuated that procedural tanks are either implemented already or should be at some point. Merging/autowelding tanks together, on the other hand, will create problems without solving anything. Most of the flex will be on smaller, lighter parts anyway: engine plates, interstage fairings, decouplers, docking ports, etc.

[Guest]

17 hours ago, TackleMcClean said:

To be asking the devs to implement autostruts seems like such a bandaid treating only the symptom and not the actual problem.

Why should the player care about struts? How should it care about them? When?

All of these are questions that better have a thought out design choice behind them, and what we've seen so far indicates the development is recreating KSP1 physics - quirks and Kraken included - rather than starting with a clean slate and asking such game design questions.

A small, but important premise: I'm a serial abuser of struts and autostruts. In KSP1 i always made my rockets as rigid as possible, hunting down any noodling and flex and fixing it.

That said.

 

You're right in one thing here, we're talking about an intentional design choice, not a bug, nor a fail in optimizing.

When they showed, at the very beginning, the first shot of a rocket noodling around (in a comical, exaggerated way) it was to showcase that the flex between joints was still there in the new code.

Keyword here being 'showcase' as in "look here! See the flex, this is still KSP!" and not as a bug to be fixed.

 

Another small, but nonetheless important, premise: I'll be happy if they scrap the flex and go with a complete rigid system, or re-implement the same band-aid solution they did in KSP1, autostruts.

But.

 

I think there is gameplay to be had in the flex of parts, even when it make your rockets blow up.

Like this:

18 hours ago, J.Random said:

like uncontrolled roll because engine gimbaling would torque the side boosters.

This is gameplay, not a bug.

If you have a 20m high booster, and you have the decoupler all the way up near the nosecone, the booster should be flexing enough to mess around with the gimbaling of the engine, and either struts or a better placed decoupler is the gameplay answer to that.

Same thing when you use the smallest possible decoupler on the biggest rockets, it should flex like a ball joint, otherwise it would make no sense to use the appropriately sized decouplers.

 

Now onto something I'm sure will be a little bit more controversial, this:

From Matt Lowne last gameplay video, is not a bug either, but gameplay too.

Why?

Because of this connection:

A 3.75m fairing, connected to a 1.25m lander, connected to a 2.5m service module, and not just that but a payload that's half the height of the rocket.

(I'm not accusing Matt Lowne of not being able to build a rocket, he built a full Duna mission in 20 minutes, so let's give him some slack)

The game has plenty of options (thanks @Space Scumbag for the video) to allow you to stack smaller diameter stuff neatly into fairings:

What I'd love to see on top of that is a ring fairing base instead of a full one to allow you to combine fairing with structural tubes and pack landers in tubes like the Apollo missions, and to solve the "fairing too high" problem Matt had in the video.

 

Tank-tank connections could be a little more rigid, and maybe parts should break apart when they flex after a certain amount, and the system does need some overall balancing, but flexing has the potential to be a meaningful and interesting design gameplay loop.

[J.Random]

17 minutes ago, Master39 said:

This is gameplay, not a bug.

If you have a 20m high booster, and you have the decoupler all the way up near the nosecone, the booster should be flexing enough to mess around with the gimbaling of the engine, and either struts or a better placed decoupler is the gameplay answer to that.

Same thing when you use the smallest possible decoupler on the biggest rockets, it should flex like a ball joint, otherwise it would make no sense to use the appropriately sized decouplers.

Oh, I'll happily agree to that. I would even argue that struts shouldn't merely bolt parts together but limit degrees of freedom instead, so that player would have to use proper triangle/cross strut configurations. With proper tools to provide eye-pleasing symmetry or even multipoint/one-to-many attachments. I'm thinking kinda like KAS where you put endpoints separately and then connect them as you wish, instead of vanilla single part struts.

I was just saying that asparagus wasn't perfect as a solution to long stack flex by itself. And stack connections should be much more rigid, imo. Some flex is ok, but when the control point is far from CoM (which will inevitably happen with interstellar ships, or large interplanetary crafts, or even simple space stations), you get uncontrolled SAS-induced oscillations and eventual krakens.

[Guest]

6 minutes ago, J.Random said:

Oh, I'll happily agree to that. I would even argue that struts shouldn't merely bolt parts together but limit degrees of freedom instead, so that player would have to use proper triangle/cross strut configurations. With proper tools to provide eye-pleasing symmetry or even multipoint/one-to-many attachments. I'm thinking kinda like KAS where you put endpoints separately and then connect them as you wish, instead of vanilla single part struts.

I was just saying that asparagus wasn't perfect as a solution to long stack flex by itself. And stack connections should be much more rigid, imo. Some flex is ok, but when the control point is far from CoM (which will inevitably happen with interstellar ships, or large interplanetary crafts, or even simple space stations), you get uncontrolled SAS-induced oscillations and eventual krakens.

Oh, yeah, I was just using yours as an example, and a great one at that. Honestly I didn't go as far as thinking about the wobbling of boosters messing with the direction of thrust before reading your comment.

[TackleMcClean]

While some may enjoy the challenge of battling the Kraken/flexing crafts, I think it's not something that should be strived towards if it comes with performance cost.

[Pthigrivi]

I think to some degree players have become to my mind overly dependent on autostrut, buuutt it does save on part count so thats probably not a big deal. I also think players react negatively to vessels flexing unrealistically and then in their advice kind of overcorrect by saying they shouldn't flex at all, and then just spontaneously fail. You do want some visible flex as a cue to the player that there's an issue, but it should really only happen when something is actually structurally inadequate. The flex looks a little unforgiving at the ESA preview, but then for some reason (probably being rushed) even a lot of the experienced CC's didn't seem to know how to strut properly and were just slapping dozens of struts in useless and inefficient ways. Real rockets do have struts, and players should have to think at least a little about stability. 

[Arugela]

On 2/20/2023 at 6:25 PM, linuxgurugamer said:

At least in the initial release, there aren't any autostruts

We are going back to the primitive days. When life was hard and food was scarce...

I'm assuming there aren't even insides to the ship parts to hold treats anymore.

Why did we never get the ability to walk inside the stations/parts. And was that being added to this? How will it work with noodly rockets? Will they get flung around or will the physics be different inside the ship?

Edited February 23, 2023 by Arugela

[Gotmachine]

1 hour ago, Master39 said:

You're right in one thing here, we're talking about an intentional design choice, not a bug, nor a fail in optimizing.

Nope, that couldn't be further away from reality.
I can say with 99% confidence now that KSP 2 is using the Unity vanilla PhysX joints implementation.
Why so confident ? Because the floppy joints is a well known intrinsic limitation of that implementation, and all you can do is "spam more joints" workarounds, which KSP 1 does in two variants :
- For stack nodes connections, it actually create multiple joints, usually 3 joints put 120° apart on a circle centered on the node.
- Autostruts
This is also what the KJR mod does. KJR is basically just a smarter and fully automatic autostrut implementation, spamming additional joints using some heuristics based on connected parts mass.

The point is that floppy joints as they exist in KSP 1 and now KSP 2 are not a game design choice and never were.
They are the result of using a physic engine that isn't designed to handle what KSP is trying to do with it, and that decision itself is the result of not enough skill/resources to implement an alternative.

[Guest]

1 minute ago, Gotmachine said:

Nope, that couldn't be further away from reality.
I can say with 99% confidence now that KSP 2 is using the Unity vanilla PhysX joints implementation.
Why so confident ? Because the floppy joints is a well known intrinsic limitation of that implementation, and all you can do is "spam more joints" workarounds, which KSP 1 does in two variants :
- For stack nodes connections, it actually create multiple joints, usually 3 joints put 120° apart on a circle centered on the node.
- Autostruts
This is also what the KJR mod does. KJR is basically just a smarter and fully automatic autostrut implementation, spamming additional joints using some heuristics based on connected parts mass.

The point is that floppy joints as they exist in KSP 1 and now KSP 2 are not a game design choice and never were.
They are the result of using a physic engine that isn't designed to handle what KSP is trying to do with it, and that decision itself is the result of not enough skill/resources to implement an alternative.

First, I'm talking uniquely about KSP2 here, KSP1 was mostly a accident for how everything works.

 

They could have gone with an entirely rigid model, or implement the KJR workaround as the default, instead they went for flexible joints and made a video specifically showcasing them, pointing it out in early interviews.

Like it or not but the presence of flexible joints in KSP2 is a choice.