How should rockets flex?

[Lisias]

33 minutes ago, Alexoff said:

The real difference that Juno is working out seems to be 7 people. KSP2 is being developed by more than fifty people + developers from Squad.

And exactly how you intend to make it look good for KSP2? You are praising Juno:New Origins better than I could ever would be able to!!!

(I didn't knew they were just 7 devs!!!)

 

33 minutes ago, Alexoff said:

And another difference in positioning, since in KSP2 the game of the millennium was promised, and Juno was not positioned like that - no colonies, no multiplayer.

Do you have positive feedback from the Juno devs about not going to implement colonies and multiplayer?

 

33 minutes ago, Alexoff said:

The disadvantages of Juno are that you can make any procedural rocket with any procedural engine, which removes KSP challenge, where you need to make something unusual from the available parts.

I fully agree on this one. IMHO, KSP2 should walk away from such game model, and this is the reason I'm advocating for some kind of structural challenge.

KSP¹ can be way more challenging than Juno exactly because of these constraints. And for people that want to play without these constraints, there's Juno.

 

33 minutes ago, Alexoff said:

It seems to me that in real life such a rocket will collapse under its own weight, and will not bend like a sausage. But in the KSP, it seems there is no such feature as the ultimate pressure on the part.

Exactly, see my Agena video somewhere in this thread's previous posts.

Interesting enough, structural abuse on KSP¹ is "punished" by the wobbling, so yeah.. KSP¹ is way more similar (or less dissimilar) to Real Life™ than Juno. So, if wobbling it set to go, it must be replaced by something else - otherwise we would have… Sugared Juno On A Golden Plate, and not a KSP¹ sucessor.

Edited July 17, 2023 by Lisias
Hit 'save" too soon.

[PDCWolf]

2 hours ago, Lisias said:

The auto-struts can also be seen as a tool for structural reinforcement. My problem with it is it being dirty cheap - using auto-struts should tax the user both on Funds and Weight on every part affected by it.

Autostruts create multiple new, invisible joints between non adjacent parts. Thus you can weld anything magically to the root, heaviest or grandparent part. Explain to me how welding my cockpit to the biggest tank in the bottom stage is a tool for structural simulation.

2 hours ago, Lisias said:

you can bet your Slide Rule it costed NASA a lot of money in reinforcements, that by their turn taxed the whole structure with mass.

And simulating those things properly is something clearly outside of the scope for KSP1 and 2. The glorified bug they left unpatched in its place (le random funny no collision wobble) happens to be wholly inappropriate to portray such things as well, and adding "moar struts" is a tax that punishes players' computers progressively on the limited partcounts we have, specially limited in the case of KSP2. Struts are also known to cause problems as well, specially once you add "enough" of them.

2 hours ago, Lisias said:

But still better than nothing!

For the level of engineering involvement the game has, and what some users pretend to justify portraying, wobble is not better than nothing, it is worse than nothing, as it fails to transmit the proper message and requires hacks (autostrut, no self collision) to even work.

2 hours ago, Lisias said:

I'm pinpointing how ridiculous would be a 220 meters, 7.5 meters wide

Well, funny you should say that, considering the ISS habitable modules measured in the video are ~109 meters long, not more than 3 meters wide (ratio of 36) versus 220 meters at 7.5 meters width (ratio of 29.6). That rocket can definitely be built more resistant than the habitation modules in the ISS, and the only variable left to check is mass.

[Lisias]

48 minutes ago, PDCWolf said:

Autostruts create multiple new, invisible joints between non adjacent parts. Thus you can weld anything magically to the root, heaviest or grandparent part. Explain to me how welding my cockpit to the biggest tank in the bottom stage is a tool for structural simulation.

Well. It allows reinforcing the structure's stiffness, as a real engineer would do by reinforcing the spars or whatever is the structural workhorse of the thing. You see, KSP¹ is a Simulacrum, not a Simulator - as long some resemblance to the Real Life™ constraints is achieved, we are good.

But you touched an interesting point: Auto-Strut to the heaviest part should not be dynamic, it should be set on stone at Editing time.

(Not to mention the use of auto-strut should tax the user on Funds and Mass)

 

48 minutes ago, PDCWolf said:

Well, funny you should say that, considering the ISS habitable modules measured in the video are ~109 meters long, not more than 3 meters wide (ratio of 36) versus 220 meters at 7.5 meters width (ratio of 29.6). That rocket can definitely be built more resistant than the habitation modules in the ISS, and the only variable left to check is mass.

Shove the ISS on a launch pad and see what happens. (This last argument of yours is an insult to our intelligence at best, and a intelectual dishonesty at worst).

Edited July 17, 2023 by Lisias
Interesting Grammars made slightly less interesting.

[Alexoff]

1 hour ago, Lisias said:

Do you have positive feedback from the Juno devs about not going to implement colonies and multiplayer?

To be honest, I don't really follow development. But I definitely didn’t see cool videos about what they promised to do by 2020. Now it seems that we will get colonies on Dune after real colonies appear on Mars ...

1 hour ago, Lisias said:

Sugared Juno On A Golden Plate, and not a KSP¹ sucessor.

But once upon a time, "simple rockets" were a primitive attempt to make something like a KSP for mobile phones. But someone rested on their laurels and shot epic videos with developers walking in slowmo, and someone just made the game step by step

[PDCWolf]

33 minutes ago, Lisias said:

Well. It allows reinforcing the structure's stiffness, as a real engineer would do by reinforcing the spars or whatever is the structural workhorse of the thing. You see, KSP¹ is a Simulacra, not a Simulator - as long some resemblance to the Real Life™ constraints is achieved, we are good.

Honestly, I thought part of the things that we didn't want in KSP2 was more "right click to do stuff" like science, and in this case autostruts. Problem > right click > solution is not good gameplay, already demonstrated in a myriad of ways in KSP1.

33 minutes ago, Lisias said:

But you touched an interesting point: Auto-Strut to the heaviest part should not be dynamic, it should be set on stone at Editing time.

If you autostrut to parent (i.e. the non cheat way), then you have a new problem: joint limits. Autostrutting your cockpit to your bottom tank adds 3 joints. Autostrutting your cockpit, to its decoupler, to its tank, to its engine, and so on, adds Nparts*3 for the whole rocket.

33 minutes ago, Lisias said:

(Not to mention the use of auto-strut should tax the user on Funds and Mass)

It's a bandaid fix for a bug, not a game mechanic. This is clear in the way its implemented and the others hacks required (part to part collision disabled being the main one).

33 minutes ago, Lisias said:

Shove the ISS on a launch pad and see what happens.

Funny how I didn't mention the whole ISS, just the hab modules they did the experiment in, which can totally be arranged in a single column, but I am the intellectually dishonest one.

 

Edited July 17, 2023 by PDCWolf

[Pthigrivi]

16 hours ago, Lisias said:

Well. It allows reinforcing the structure's stiffness, as a real engineer would do by reinforcing the spars or whatever is the structural workhorse of the thing. You see, KSP¹ is a Simulacrum, not a Simulator - as long some resemblance to the Real Life™ constraints is achieved, we are good.

I'll be really interested to see the dev blog on the solution here, as I do agree with Nate's sentiment that if joints were behaving properly autostrut should not be necessary as a crutch. And while Im not a programmer I do suspect "its not as simple as pushing the stronger joints button" to be true. A big part of the reason rockets wobble less in real life than they do in game is that the structure is a cylinder rather than two blocks attached at a central hinge point. By increasing the number of perimeter connections between parts you increase its lateral strength. Of course we also have hundreds of parts with different base sizes and there are performance costs to be considered so Im sure this is a pretty sticky problem at the nuts and bolts level. 

[Lisias]

3 hours ago, Pthigrivi said:

I'll be really interested to see the dev blog on the solution here, as I do agree with Nate's sentiment that if joints were behaving properly autostrut should not be necessary as a crutch. And while Im not a programmer I do suspect "its not as simple as pushing the stronger joints button" to be true.

To tell you the true, the autostruts adds problems by their own - you have more points to calculate stress, and as the CPU gets overloaded, these calculations fail to be done in time (a simulation is a real-time computation, besides mostly developers failing to acknowledge this properly).

One thing that could alleviate the problem (autostruts and also the regular joints) would be to wave the fixed 30 physics frames per second, and addint a delta-time between each physics fame update. This would allow the physics to be calculated on an arbitrary amount of "PFPS" (physics framer per second) and this, by itself, would solve about 80% of the Krakens on this game (rhetorical stats, pulled the number from my SAS - but it's not too far from my perceived reality).

 

4 hours ago, Pthigrivi said:

A big part of the reason rockets wobble less in real life than they do in game is that the structure is a cylinder rather than two blocks attached at a central hinge point. By increasing the number of perimeter connections between parts you increase its lateral strength.

About the joints, a possible solution would be something as Ubioweld automatically being applied to the craft - some parts could be automatically welded together as a single rigid body, saving computation (and joints). This would work way better with the wobble being replaced by rigid bodies  bending under stress.

 

4 hours ago, Pthigrivi said:

 Of course we also have hundreds of parts with different base sizes and there are performance costs to be considered so Im sure this is a pretty sticky problem at the nuts and bolts level. 

On Real Life™, we have spars and support frames, and KSP bluntly abstracted them, replacing them by the attachment points.

We can track down almost all the conceptual problem we have on KSP (both on them) to this simple fact: we had replaced spars and support frames for something else, but we still want them to behave like the things we had replaced.

Some compromise is unavoidable.

[Stephensan]

here is my answer, and i still strongly believe it will fit everyone's needs in the wobbly department while also making the game interesting and use the materials, research, and further need of improving, and if you don't like the base wobbliness just have a stronger rigidy in the start/creating save world.

a TLDR: "Have it researchable, let players set up base wobbliness or disable it entirely"

but long, rough draft that i don't want to elaborate on further due to it just being a rough idea that i quite enjoy
 

It could just be a research thing, where you can easily create a couple of extra lines (not code I'm talking about tech tree lines) t that can go "deep" into the tech tree and "slowly" adds more rigidity to parts. It would require more materials to make it less wobbly or more rigid and you can just click a "scaler" that makes the entire rocket cost more or less, fewer materials.. Things can be categorized like "fuel tanks" "structural" "Pods" "Colonies" "XYZ ABC" etc.

Due to not having "time" and watching your rockets build slowly (i wish) just making it cost more materials and some additional research points doesn't seem like such a bad idea/plan, keeping the "kerbal" way while also adding the want/need to push further for more stable and "larger builds".

So starting off rockets can still be quite wobbly, but the people that dare go larger CAN but have a higher chance of wobbliness without upgrading anything. It makes sense from a logical standpoint that while you progress further in the tech tree, the stronger your rockets are.. It creates a fine balance of "expensive but will never fall apart" and "should i cheap out on this build" etc. For me it creates a lot of ideas of what you can "do".

and then it can just be simply turned off with a setting to ONLY have the strongest stability when it's disabled.. And starting wobbliness will depend on the overall difficulty of the save with a slider, and a "on and off" button

I doubt that there needs to be a forced level for each thing, and COULD be optional for the insane players that want REALLY wobbly rockets.

(think about the content)

"I played ksp 2 on the hardest difficulty with zero stability upgrades"

No idea how much extra work that can/could add to adding new "tech tree" points where structural stability is getting stronger and stronger depending on what tech level you are at.. but that's just an idea I'm throwing out in the wind.

This COULD probably also help create alot of modders aswell wanting to add income and the sorts into the game making it even more of a "positive feedback loop".

[RocketRockington]

10 hours ago, Pthigrivi said:

Nate's sentiment that if joints were behaving properly autostrut should not be necessary as a crutch

Would you say a cardboard box is not 'behaving properly' when you tried to use one as a structural element in building a house?  Or would it be more honest to say that the person/people who decided to use cardboard instead of wood are the ones who behaved improperly?

Ultimately it seems like this was a decision made early by people who didn't know  the ramifications of their decisions, and now a story is being promoted that this wasn't the intended behavior, except it clearly was, and also they had no idea that if they wanted to not have things behave like this, that it would be a very difficult thing to rework.   

Sounds very like like management that didn't listen to their engineers early on, but now want to blame the engineering for not being able to fix it fast. 

I can absolutely see why 0% of the engineers at Star Theory transitioned to Intercept.

Edited July 18, 2023 by RocketRockington

[MechBFP]

15 minutes ago, RocketRockington said:

Sounds very like like management that didn't listen to their engineers early on, but now want to blame the engineering for not being able to fix it fast. 

I can absolutely see why 0% of the engineers at Star Theory transitioned to Intercept.

The rest of your post was fine and then you just pull *citation needed* for no reason. Why?

[Pthigrivi]

55 minutes ago, RocketRockington said:

Would you say a cardboard box is not 'behaving properly' when you tried to use one as a structural element in building a house?  Or would it be more honest to say that the person/people who decided to use cardboard instead of wood are the ones who behaved improperly?

Ultimately it seems like this was a decision made early by people who didn't know  the ramifications of their decisions, and now a story is being promoted that this wasn't the intended behavior, except it clearly was, and also they had no idea that if they wanted to not have things behave like this, that it would be a very difficult thing to rework.   

Sounds very like like management that didn't listen to their engineers early on, but now want to blame the engineering for not being able to fix it fast. 

I can absolutely see why 0% of the engineers at Star Theory transitioned to Intercept.

We're at page 10 of this argument, so I think we can dispense with some of the repetitive misconceptions. Bending IS intended behavior, and rightfully so. They are bending too much and too easily, which is not. Most everyone including the devs agree with this. Thats clearly not a trivial problem to solve or it would have been solved much earlier. Some have posited that the solution is to make all vessels completely rigid and not respond to physics at all until they spontaneously shatter. I just don't think that argument is a good one. Take the time and solve the actual problem.

Edited July 19, 2023 by Pthigrivi

[PDCWolf]

28 minutes ago, Pthigrivi said:

Bending IS intended behavior, and rightfully so.

It is not. At least not in the way it's present currently in either KSP1 or 2: for KSP1, having autostrut is the telltale sign, a simple right-click hack to solve the problem in place of a proper solution which the team never found (as it really requires rewriting a good part of unity's default joints) at the heavy cost of performance, enabling senseless designs, and so on. I must also remind you that for KSP1 we're on what must be the third iteration of "trying to scale wobble back", which includes another hack: disabling part to part collisions, a solution that was final until the breaking ground DLC, which introduced robotics and thus users needed to be able to enable that back (which was given on a part to part basis, so you don't get self-explody stuff again).

For KSP2, we still have the same problem with same-vessel collisions being disabled by default, and we also happen to have whoever's faulty vision of how rockets should behave. Sadly we don't have autostrut because they want a "proper fix", which let me spoil you: given it's been at least 144 days "in discussion", discounting any time before release, it is safe to say said fix is not coming.

This is exactly why people are concerned when Nate says he wants wobble in the game, because when you add up the fact that they decided to not re-implement autostrut, and reimplement the same-vessel-collision hack, then you know they're going the wrong route. And then you get people arguing that self-ghosting rockets and wet noodles promote STEM .

Edited July 19, 2023 by PDCWolf

[Pthigrivi]

2 hours ago, PDCWolf said:

It is not. At least not in the way it's present currently in either KSP1 or 2: for KSP1, having autostrut is the telltale sign, a simple right-click hack to solve the problem in place of a proper solution which the team never found (as it really requires rewriting a good part of unity's default joints) at the heavy cost of performance, enabling senseless designs, and so on. I must also remind you that for KSP1 we're on what must be the third iteration of "trying to scale wobble back", which includes another hack: disabling part to part collisions, a solution that was final until the breaking ground DLC, which introduced robotics and thus users needed to be able to enable that back (which was given on a part to part basis, so you don't get self-explody stuff again).

For KSP2, we still have the same problem with same-vessel collisions being disabled by default, and we also happen to have whoever's faulty vision of how rockets should behave. Sadly we don't have autostrut because they want a "proper fix", which let me spoil you: given it's been at least 144 days "in discussion", discounting any time before release, it is safe to say said fix is not coming.

This is exactly why people are concerned when Nate says he wants wobble in the game, because when you add up the fact that they decided to not re-implement autostrut, and reimplement the same-vessel-collision hack, then you know they're going the wrong route. And then you get people arguing that self-ghosting rockets and wet noodles promote STEM .

Forgive me, Im not a programmer by trade. Wouldn’t same-vessel collision create a lot of wonky problems for part clipping?

Edited July 19, 2023 by Pthigrivi

[RocketRockington]

21 minutes ago, Pthigrivi said:

Forgive me, Im not a programmer by trade. Wouldn’t same-vessel collision create a lot of wonky problems for part clippin

I love people arguing that wobble is there to enforce good 'realistic' structural design - but also that solid rocket parts should be allowed to interpenetrate willy-nilly.  

3 hours ago, Pthigrivi said:

Bending IS intended behavior, and rightfully so.

The only amount of bending that's 'rightfully' present is so miniscule that 'no bending' is the correct approximation.

[Pthigrivi]

1 minute ago, RocketRockington said:

I love people arguing that wobble is there to enforce good 'realistic' structural design - but also that solid rocket parts should be allowed to interpenetrate willy-nilly.  

The only amount of bending that's 'rightfully' present is so miniscule that 'no bending' is the correct approximation.

Again forgive my presumption but being in a field where deflection and physics are omnipresent for every structure I interact with I personally appreciate this effect being slightly exaggerated in a game setting precisely because I can see it. If it were so slight as to be undetectable it would be useless, but still less useless than failing to model structural loads entirely.  Again: this is a hard problem of fine-tuning. Near everyone in the poll appreciates the visual feedback of a structurally unsound vessel flexing under load. The issue IS NOT the existence of flex in game. It is the wildly unforgiving and unrealistic expression of the current build. 

[RocketRockington]

2 hours ago, Pthigrivi said:

Again forgive my presumption but being in a field where deflection and physics are omnipresent for every structure I interact with I personally appreciate this effect being slightly exaggerated in a game setting precisely because I can see it. If it were so slight as to be undetectable it would be useless, but still less useless than failing to model structural loads entirely.  Again: this is a hard problem of fine-tuning. Near everyone in the poll appreciates the visual feedback of a structurally unsound vessel flexing under load. The issue IS NOT the existence of flex in game. It is the wildly unforgiving and unrealistic expression of the current build. 

Fair, though I think @Kavaerichas a better suggestion without the visual flex, that would also make for a better game system.  Have you looked at it?

This is the sort of thing I would have hoped for out of a new KSP, new fun game systems to explore.  Graphics updates are all well and good, but so far the gameplay/systems improvements are nearly nil.

[PDCWolf]

7 hours ago, Pthigrivi said:

Forgive me, Im not a programmer by trade. Wouldn’t same-vessel collision create a lot of wonky problems for part clipping?

That was a problem even after turning off part to part collision. Had to be "fixed" in 0.20, yet you can still make stuff that explodes on the launchpad if you clip stuff wrong.

This is after 0.16, which introduced the original rule for parts in a vessel to not collide with each other:

So yeah, the answer is no. We had clipping long before they turned the same-vessel collisions off. How that worked is not something I could decipher from thin air, though that patch in 0.20.1 heavily hints at clipped parts being detected and having special conditions applied to them (probably with the same occlusion formula later used on fairings, which is why you can clip tiny fairings inside stuff and have the original part act as if inside a fairing)

Edit to add, 0.15 had this logic worked on as well, before same-vessel-collision was deactivated:

Edited July 19, 2023 by PDCWolf

[Dakitess]

Some kind of assist is required to deal with KSP being Lego's part stacked vertically, period.

Rocket don't work like this IRL, it wont "bend" / wobble because of multiple stacked segments with as many weird junctions.

As long as we don't have procedural tanks (and it's totally fine to discuss this point as another subject, actually already addressed), KSP2 NEEDS a workaround, something to make vertical stack acting like a monolithic tank. It can be (it should be) automated, like recognizing that there is 5 same diameters tanks all connected directly without any structural parts like decouplers, engine, or whatever, just tanks : act like one big tank. It would fixe 50% of the whole trouble, it would feel realistic, and it would help performance by ignoring theses numerous useless junctions.

When there is a decoupler between 2 stacks of tanks ? Then it's okay to treat it as junction, with its weaknesses. Not as much as current weird wobbles, of course.

This goes for all junction that are different that Same-Diameter-Tanks being stacked. You can consider a change of diameter as a new junction, for instance, and gives it some weakness, while not as much as currently, of course. 

Now it would need some comprehensive rules regarding a tank being stacked with another part of the same diameter, say, a battery : I would argue that same thing apply than for tanks between eachother, but that's debatable. I would not want tiny probe made of 10 same diameter differents parts (ion engine, xeon tank, IRW, batteries, electronic pod, structural truss, RCS tank, and some other) to be perfectly rigid for the sake of being the same diameter... Or would I ? It actually feel okay, when thinking about it. A better approximation and solution that consider each linkage with its own weaknesses.

If done correctly, it would eliminate the need for AutoStruts or weird work around, at least for rockets. But things are different for planes (especially) : wings. And other lateral non stacked parts that create long branches not interconnected. I guess that physical struts can be a solution, and it feel okay to use them to reinforce legitimately a payload inside a cargo bay. It's actually more logical to get them physical, visible, with weight / costs. But it's not when it comes to connecting two end of long wing branches so that they don't flap in the air. OF COURSE it's supposed to be one big wing, and not 2 different branches. But the game can't guess it. It could it ? :p

Some king of autostrut but fully manual would be nice, like designating the start and the end point. Of course, most will say that people will abuse it : I don't care how people play their solo game, but in any case, since the game would actually feel okay without any struts, it woiuld only allow theses edge cases and people won't over-abuse it as it won't really add much, don't know if i'm clear enough haha.

I would love some autostrut geometric limitation, it's dead simple : theses virtual struts would have some lenght limitation, that's it. You're not supposed to link 2 distant parts ? Then don't allow it, it's not required to deal with the precedent edge cases (side boosters, wings linkage, etc).

It would really be benefitable if we could write an open letter that represent as best as possible the community expectation about it. The initial poll is a good thing, it would need to be fine tuned.

[RocketRockington]

HarvestR, original dev for KSP, in his next game ditched wobble physics completely for a completely rigid body simulation of craft, with a bespoke structural simulation for part breakage/destruction.

So basically, if you care what the original KSP dev and designer has to say, a lot of points of contention are gone

1.  The original dev decided to change out the way craft physics parts worked for his next game because he LEARNED and MOVED ON.  This shows that all the people who thing wobble is intentional and should be kept - well, HarvestR disagrees with you.

2. The development studio for Kitbash is only 4 people per linkedIn, one of them a freelancer,   So moving on to this custom physics was not a monumental, ginormous incredible heap of work, as KSP2 developers/apologists would often want you to believe, and can be accomplished by a small agile team that knows what it's doing because it has the prior game as an example of what not to do, and has a reasonable understanding of what to do to make their next iteration better.

 

 

Edited July 25, 2023 by RocketRockington

[MechBFP]

I am not sure why you think anyone cares if he disagrees. The end results of their game will show whether or not that small piece even matters in the end. 

[Infinite Aerospace]

Rockets in KSP2 should flex in the same matter real rockets flex, not all that much but catastrophic failure due to aerodynamic forces is possible.