Jump to content

Craft structure: still a tree or not?


Recommended Posts

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?

Link to post
Share on other sites
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. 

Link to post
Share on other sites
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.

Link to post
Share on other sites

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.

Link to post
Share on other sites
  • 8 months later...
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.

Link to post
Share on other sites
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 :P

Link to post
Share on other sites

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

ub2PICU.jpgTo 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 by OHara
Link to post
Share on other sites
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).

ub2PICU.jpgTo 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 by mcwaffles2003
Link to post
Share on other sites
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...