Craft structure: still a tree or not?

[Psycho_zs]

In KSP 1 crafts are structured as trees, with every part having a single parent down to a root part. This is a limitation for the building process, which manifests itself in the way radial decouplers are used, inability to form structural loops, multiple pylons etc.

There is a multidock capability (and Recoupler mod that uses it to simulate multipath constructs), but it is not trivial to utilize it.

So I wonder, will there be any relevant changes in  KSP 2?

[GoldForest]

4 minutes ago, Psycho_zs said:

In KSP 1 crafts are structured as trees, with every part having a single parent down to a root part. This is a limitation for the building process, which manifests itself in the way radial decouplers are used, inability to form structural loops, multiple pylons etc.

There is a multidock capability (and Recoupler mod that uses it to simulate multipath constructs), but it is not trivial to utilize it.

So I wonder, will there be any relevant changes in  KSP 2?

Multi-docking is something the KSP community has wanted for a long time now, since a lot of people like to make multi-docked structures. 

It's not outside the realm of possibility that they would add the ability in, either at launch or in a future update. 

[nikokespprfan]

I personally hope this is one of those issues that simply does not get recreated in the process of rebuilding the game.

[chaos_forge]

This would definitely be nice to have fixed, yeah.

[Empiro]

12 hours ago, GoldForest said:

Multi-docking is something the KSP community has wanted for a long time now, since a lot of people like to make multi-docked structures. 

It's not outside the realm of possibility that they would add the ability in, either at launch or in a future update. 

Ship representation is something that is pretty core to the game itself, so changing it later is probably impossible. Hopefully that means it is there at launch.

[mattinoz]

Given KSP2 is still unity, and parts geometry and textures seem to largely travel between versions as evidenced by the video. Then you have to suspect the reason there won't be a KSP1 to KSP2 save convertor is the file format is radically different.

If it's going to handle colonies and other large assets you'd think the first thing to do would be to break up a save file into smaller pieces and better define the interaction of those pieces. Makes sense to me at least to not update the position of every item in the game compared to every other every time you save instead just track them by orbits or fixed landed locals and only care if the visually approximate.

[Bej Kerman]

With release getting closer and closer, I want to see more activity in this thread.

[Incarnation of Chaos]

It's extremely likely the crafts will still follow a "Tree" structure, but will have more logic to handle edge cases like multi-docking.

[mattinoz]

5 hours ago, Incarnation of Chaos said:

It's extremely likely the crafts will still follow a "Tree" structure, but will have more logic to handle edge cases like multi-docking.

Seems to me it needs to be forest of trees with loose tendril connections. So each "craft" stays distinct and can dock or break away without the jolt of merging into a single tree like KSP 1.

Especially with Orbit and Base construction of other craft, exotics fuels and docks for fuelling looking like part of the game. A single tree seems a bad state of affairs.

[Incarnation of Chaos]

30 minutes ago, mattinoz said:

Seems to me it needs to be forest of trees with loose tendril connections. So each "craft" stays distinct and can dock or break away without the jolt of merging into a single tree like KSP 1.

Especially with Orbit and Base construction of other craft, exotics fuels and docks for fuelling looking like part of the game. A single tree seems a bad state of affairs.

It really just depends how much the developers want to trade performance for allowing novel craft designs. Even allowing multiple "Trees" to exist would increase the computational complexity significantly, then adding the physics LOD and acceleration on top would complicate things and introduce bugs. The tree structure is staying for a reason; there was a dude in another thread who put it much better. Hopefully they drop in

[OHara]

At one of the interviews, ShadowZone explained one use for a more general construction method, directly to the KSP2 team (link to time-stamp in the YouTube video).

To build the desired craft from that video, in KSP1 we have to build from one docking connection along one of the legs and then back up the other, then bridge this second docking connection with a strut. 
In the image at right, the root part is at right to match the video, and I mis-aligned docking ports just to show which one is not directly connected.

If the EAS-4 strut would have zero mass (KSPv1.2 already removed its drag) we would have the result we wanted. KSP1's simulation handles the resulting loop of physical constraints just fine.  Placing and dragging an EAS-4 strut is the only way to indicate the second physical connection in KSP1.

Does anyone know of a good example for a user interface, 
that allows users to connect subassemblies in more general ways? 

In KSP1 we place a part-or-subassembly onto a chosen part of the craft under assembly, with a single mouse click, which naturally leads to the single point of connection and tree structure.  CAD software (used for designing automobiles and such) tends to use tree structures, plus various ways to add constraints that I think are too complicated for a game.  The ReCoupler mod for KSP1 automatically joins additional nodes that are close enough, with some added highlighting and user interface tools to help see what is happening.  Maybe those U.I. concepts can be streamlined into KSP2 without making it too complicated for new players.

KSP2 would need some way to make clear when we are making two or more connections.
It might be wise to store craft in a more general structure, directed acyclic graph instead of tree, so that multiple connections are truly equivalent.  The nature of building craft by adding 'child' parts to a 'parent' or 'parents' gives the structure a natural acyclic order, so that if we offset a part it remains clear which parts are 'descendants' that should follow along with the offset.

Edited May 17, 2020 by OHara

[mcwaffles2003]

11 hours ago, OHara said:

At one of the interviews, ShadowZone explained one use for a more general construction method, directly to the KSP2 team (link to time-stamp in the YouTube video).

To build the desired craft from that video, in KSP1 we have to build from one docking connection along one of the legs and then back up the other, then bridge this second docking connection with a strut. 
In the image at right, the root part is at right to match the video, and I mis-aligned docking ports just to show which one is not directly connected.

If the EAS-4 strut would have zero mass (KSPv1.2 already removed its drag) we would have the result we wanted. KSP1's simulation handles the resulting loop of physical constraints just fine.  Placing and dragging an EAS-4 strut is the only way to indicate the second physical connection in KSP1.

Does anyone know of a good example for a user interface, 
that allows users to connect subassemblies in more general ways? 

In KSP1 we place a part-or-subassembly onto a chosen part of the craft under assembly, with a single mouse click, which naturally leads to the single point of connection and tree structure.  CAD software (used for designing automobiles and such) tends to use tree structures, plus various ways to add constraints that I think are too complicated for a game.  The ReCoupler mod for KSP1 automatically joins additional nodes that are close enough, with some added highlighting and user interface tools to help see what is happening.  Maybe those U.I. concepts can be streamlined into KSP2 without making it too complicated for new players.

KSP2 would need some way to make clear when we are making two or more connections.
It might be wise to store craft in a more general structure, directed acyclic graph instead of tree, so that multiple connections are truly equivalent.  The nature of building craft by adding 'child' parts to a 'parent' or 'parents' gives the structure a natural acyclic order, so that if we offset a part it remains clear which parts are 'descendants' that should follow along with the offset.

In KSP 1 there is a way around this specific problem that I have used. You include a bicoupler and then attach a docking port to is using 2x radial symmetry. After this you add a docking port to the 1st set of docking ports with the same symmetry followed by attaching these docking ports to another bicoupler without symmetry. You can add whatever you want between the multicouplers so long as they're symmetric and com back to the same distance between them. 

Edited May 18, 2020 by mcwaffles2003