[0.20.x] Subassembly Manager

[Raptor831]

Just wanted to pass along the info here. I've never had a problem with my standard launcher and missing struts or fuel lines. They were there in SL and SM. I just saved my part with the standard 2.5m decoupler as the root part, and it's been playing nice. I only really have the 1 launcher as of yet, and it's only got 4 fuel lines and about 10 struts, but I think I've only seen 1 strut not connect correctly in the VAB.

Hope this works for others, as it would save a lot of headaches!

[Eric S]

The problem is how one saves a subassembly while still preseving the attachment points? Cause the difference between the subassembly save and the normal save is that the normal save preserves all it's attachment points. So, the tree structure is not the same, or at least don't behave the same.

The problem isn't in the save though. It's in how the KSP VAB/SPH interface handles detached parts. As I said before, you can see this behavior just by pulling a few parts off of a craft. Only the part that was originally attached to the craft will have functional nodes until you reattach the assembly to the craft. This is because that part is the root of the part tree that you detached, so in order for the craft to remain a tree, that part has to be what gets reattached to the tree that represents the craft.

In a tree structure, each item can have at most one parent. Only one item in the tree will have no parent, and that item is considered the "root" of the tree. On the other hand, each item can have as many children as you want. That first part is the cause of this issue. It's also the reason you can't close a loop of parts without docking rings or EAS-4 struts.

Let me see if I can explain this with some ASCII art. Say you've got a capsule as the first part of your ship. We'll use C to represent that part. So your initial tree looks like this.

C

So C is the root of the tree. Now, let's attach a fuel tank to the capsule. We'll use F to represent the fuel tank.

C <- F

So C is the parent of F, and F is the child of C. Now, if we attach two RCS quads to the fuel tank, we get a tree that looks more like

C <-F <-R
      <-R

So at this point C has F as a child, and F has two R as a child. Now let's add a Hubmax.

C <-F <-R
      <-R
      <-H

Now, if you pick up the tank, the craft tree reverts to just

C

And you have a tree that looks like this "picked up"

F <-R
  <-R
  <-H

Now, since this tree starts at F, that can be the only node that can be reattached to the craft, since all the other nodes already have a parent node. Yes, the H part should have nodes available to connect to a parent part, but since it already has a parent, it's nodes are disabled until the tree is reattached to the craft.

[SyrusDrake]

I feel rather stupid for having to ask for help but...it doesn't work for me.

It just plain doesn't show up. I moved the content of the zip to the GameData folder but nothing happens. There is no button in the VAB.

Is it possible that it's not getting along with the "Part Group & Filter" mod? Because that's also modifying the button bar.

Help would be greatly appreciated

[MR4Y]

The problem isn't in the save though. It's in how the KSP VAB/SPH interface handles detached parts. As I said before, you can see this behavior just by pulling a few parts off of a craft. Only the part that was originally attached to the craft will have functional nodes until you reattach the assembly to the craft. This is because that part is the root of the part tree that you detached, so in order for the craft to remain a tree, that part has to be what gets reattached to the tree that represents the craft.

In a tree structure, each item can have at most one parent. Only one item in the tree will have no parent, and that item is considered the "root" of the tree. On the other hand, each item can have as many children as you want. That first part is the cause of this issue. It's also the reason you can't close a loop of parts without docking rings or EAS-4 struts.

Let me see if I can explain this with some ASCII art. Say you've got a capsule as the first part of your ship. We'll use C to represent that part. So your initial tree looks like this.

C

So C is the root of the tree. Now, let's attach a fuel tank to the capsule. We'll use F to represent the fuel tank.

C <- F

So C is the parent of F, and F is the child of C. Now, if we attach two RCS quads to the fuel tank, we get a tree that looks more like

C <-F <-R
      <-R

So at this point C has F as a child, and F has two R as a child. Now let's add a Hubmax.

C <-F <-R
      <-R
      <-H

Now, if you pick up the tank, the craft tree reverts to just

C

And you have a tree that looks like this "picked up"

F <-R
  <-R
  <-H

Now, since this tree starts at F, that can be the only node that can be reattached to the craft, since all the other nodes already have a parent node. Yes, the H part should have nodes available to connect to a parent part, but since it already has a parent, it's nodes are disabled until the tree is reattached to the craft.

A crazy suggestion would be that a saved subassembly could behave like it had a root at each attachment point. Sorta like not making a root to a subassembly, but transforming the whole subassembly into a root.

[-ty-]

So im trying to build a rocket right now, and I have a lunar lander saved as a lander, but when i load it with Subassembler into my other rocket, it appears with no attachment points at all, so i can't place it anywhere. Any help would be appreciated.

[Pontiac]

A crazy suggestion would be that a saved subassembly could behave like it had a root at each attachment point. Sorta like not making a root to a subassembly, but transforming the whole subassembly into a root.

The work involved in doing so, and being 100% accurate is pretty close to being impossible, DEPENDING on whether one could pick which event is happening. Somewhere down the line of events starting from when the user clicks the Left Mouse Button (LMB) the game has to decide whether we're picking up a part off the vessel or from the parts list or a part hanging out in space, dropping a part out in space or in the trash or on the ship, etc.

So then SAM has to decide when to act on the right behavior. So first assuming that this detection can be done at all, if we have determined that we're between the point of knowing we're picking up a part and its NOT the root part, and the point of actually physically removing the part and its children from the ship, we have to take a catalog every single part in its "attached state", denote a special name to it (Since putting the soon-to-be new structure could already be named something else), decide if it is a part that not only has a parent, but connects to another part somewhere else on the structure and REMEMBER that other parts new name if it has already been assigned one, and if the other part hasn't been named remember to come back and check for that new name when everything else has been cataloged, and THEN remember the entire state. *takes a deep breath after that run-on sentence*.... At this point, Unity can handle moving the parts we've selected, and move them all around. If the user wants to save the ship, because, you know, the computer CAN'T know that we want to save the structure when we pressed the LMB, so when the part is dragged to the save point, or, is released by joining to another part of the structure, or dragging to the trash, or whatever. If we're dragging to the save button, then draw the "SAVE AS" dialogs as usual, save the in-memory cataloged parts to the .craft file. After the second mouse button click, we then forget everything we did.

Its just too difficult to do from a mod perspective due to the way KSP handles parts in a disconnected state.

So im trying to build a rocket right now, and I have a lunar lander saved as a lander, but when i load it with Subassembler into my other rocket, it appears with no attachment points at all, so i can't place it anywhere. Any help would be appreciated.

Couple of things you can do.

- When you load your parts, drop them somewhere in the VAB/SPH disconnected. Then pick it up and attempt to attach. Rotate the parts if needed.

- Start a new build with a decoupler as the root part. Load your craft and see if it will attach. If it does, something is up with your lifter.

[Pontiac]

It Does work with docking ports, but you have to save the craft from the docking port down. The easiest way to do this is to just start with a tiny probe, then put the docking port under it and the rest of the craft attaches to the docking port. Now when you want to save it you can just move the docking port and everything attached under it to the icon. You could do the same thing and maintain your struts and fuel lines by moving the tiny probe core to the icon and saving it too, then just deleting it once you've pasted it into the other craft

Double-post. Sorry, I missed a chunk of this thread somehow.

Not sure if you read my post back in the SAL days, but, the "real" fix is having your lifting stage with the root part as being a decoupler, or something with at least two nodes, and build out your lifter stage that way. Same with a payload. Decoupler as the root part, and build the rest of the payload as needed. When you go to save the assembly, you're saving the ship in its fully-parts-attached state so long you drag the ship FROM the root part which is the decoupler in my example.

@Everyone: For a better understanding of what is happening and why things like fuel lines and struts are breaking;

If we were to translate each part of a ship into a family member, being a parent to a child and child to a parent, your root part is the granddaddy that started it all. The granddaddy is the "parent" of all in a uni-gender world (Fitting for Kerbals so far, isn't it?) Every single part, other than the root part, have a child to parent relationship. Each child can only have one parent, but each parent can have one or more children. While in the VAB/SPH, the exception to the rule for stock parts happens to be the Fuel Line and Strut parts. Although these two parts do follow the parent/child relationship, they also have this growth added feature that allows them to attach to other parts. The part that SAL and SAM fail on is when you try to save something that isn't the root, the two parts forget who they're connected to after the fact. Unfortunately the parts are saved in this forgetful state. I don't think there is any function, code, or procedure that will tell a component to re-attach to the first thing it runs to after ALL the children are loaded. I've not found one yet at least.

[Mr Shifty]

I've been thinking about the ideal SAM-type mod:

1) Folders are great. You should be able to sort all of your craft files into folders and sub-folders. Rather than just a sub-assembly manager, we need a whole new craft file manager with sub-directory support.

2) Sub-assembly files are just craft files. They're functionally identical to any other craft file, right? Why can't we just use any craft file as a sub-assembly? Seems like a perfect thing to integrate into a new craft file manager.

3) We need a way to change the root part of a vessel. I envision a right-click on any part of a loaded vessel with an option to "Set this part as root." Seems like you'd have to change its parent to a child and propagate that change up the tree, but it should be possible.

[Tw1]

One thing that would be useful, is the ability to easily overwrite a sub assembly with an updated version, without having to type in the exact same name.

Otherwise, this looks fine.

But I'm not really seeing any advantage over the existing patched version of sub assembly atm.

Edited July 9, 2013 by Tw1

[TheUndeadFish]

1) Folders are great. You should be able to sort all of your craft files into folders and sub-folders. Rather than just a sub-assembly manager, we need a whole new craft file manager with sub-directory support.

I would love to enhance this. But currently KSP exposes exceedingly minimal file/directory facilities and doesn't allow me to bring in what I would need from the .NET framework. So that rather cripples my ability to do what I would want.

2) Sub-assembly files are just craft files. They're functionally identical to any other craft file, right? Why can't we just use any craft file as a sub-assembly? Seems like a perfect thing to integrate into a new craft file manager.

On my to-do list. But many craft probably won't have a free attachment node on their root part and thus wouldn't be attachable as subassemblies. So it's a question of whether I can solve that problem first, or just put craft loading in before that regardless.

3) We need a way to change the root part of a vessel. I envision a right-click on any part of a loaded vessel with an option to "Set this part as root." Seems like you'd have to change its parent to a child and propagate that change up the tree, but it should be possible.

I've taken a stab at a way to do this today... But even after flipping the necessary child-parent relationships, it's not working properly. Crawling around the minimally documented depths of KSP has not led me to a solution yet...

One thing that would be useful, is the ability to easily overwrite a sub assembly with an updated version, without having to type in the exact same name.

Otherwise, this looks fine.

I'm going to be working on that for my next update. Possibly tomorrow.

But I'm not really seeing any advantage over the existing patched version of sub assembly atm.

Currently the main advantages are:

- I'm allowed to distribute this one since I wrote it from scratch, whereas the old one didn't have a proper license and thus distributing any modifications to it violated the implicit copyright/intellectual-property/whatever of the original author.

- I'm still here and working on it, whereas the author of the original has disappeared.

- I've licensed mine so that others can continue it if I ever disappear.

[Tw1]

-snip-

Currently the main advantages are:

- I'm allowed to distribute this one since I wrote it from scratch, whereas the old one didn't have a proper license and thus distributing any modifications to it violated the implicit copyright/intellectual-property/whatever of the original author.

- I'm still here and working on it, whereas the author of the original has disappeared.

- I've licensed mine so that others can continue it if I ever disappear.

Great. I'm convinced. Bye old subassembly mod, you're going.

[HoY]

The only thing I miss from the old one is the button and button placement

Maybe some time in a future update??

[TheUndeadFish]

New version released.

0.1.3

Added the ability to save over an existing subassembly without having to re-type the name.

Added a warning message if the user tries to save a subassembly that probably won't be attachable (no available attachment nodes on root part).

No longer allows trying to save a subassembly without a name.

The save/load button appears in an inactive mode when it's not clickable, instead of being completely invisible.

[NoMrBond]

One thing I've noticed, if you externally copy a .craft file from your VAB/SPH directory to the sub's directory, and then load it with the sub-manager, the fuel-lines/struts are (usually) fine and correct

So what about an option to load crafts from the SPH or VAB directories?

Edited July 11, 2013 by NoMrBond

[stupid_chris]

I had an issue the other day when moving a craft from the SPH to the VAB. I was doing something in the VAB, and I needed SPH symettry, so I saved the assembly, brought it up in the SPH and did my thing. The problems came by when I took it back to the VAB. The parts were messed up and I'm not quite sure how to describe it, I'll take a screenshot when I have a moment. You might still want to check it out yourself.

[TheUndeadFish]

I had an issue the other day when moving a craft from the SPH to the VAB. I was doing something in the VAB, and I needed SPH symettry, so I saved the assembly, brought it up in the SPH and did my thing. The problems came by when I took it back to the VAB. The parts were messed up and I'm not quite sure how to describe it, I'll take a screenshot when I have a moment. You might still want to check it out yourself.

So VAB to SPH to VAB... interesting. I've taken something from the SPH to VAB, but not a full round trip like that. I'll try some experiments and see if I can get anything weird to happen.

[NoMrBond]

Yeah, I've had that too, the symmetry options can get confused when you move an SPH created craft to the VAB or vice-versa

Sometimes editing the .craft line from SPH to VAB (or the other way depending on which way you've moved it) works, sometimes not.

It would be nice to be able to just switch from radial to vertical to mirrored symmetry options without having to faff about with externally copying .craft files around then reloading in alternate hangers etc

[stupid_chris]

So VAB to SPH to VAB... interesting. I've taken something from the SPH to VAB, but not a full round trip like that. I'll try some experiments and see if I can get anything weird to happen.

Weird, I tried it again and haven't been able to get that same bug again. I'll try to describe my issue:

I was building a base, and wanted the legs to be at the same height, so I transferred my whole craft file to the SPH, there I added the legs and transferred back to the VAB. There, I realized I went back to my old build and realized I had taken the root part of the craft along to the SPH, so I deleted it and sticked the rest under. Then, I just wanted to move the part with the legs and well, there were landing legs appearing at weird places on the screen, like on the other side of the assembly, or floating at the most random places. I had to delete them because it just didn't work.

Also while trying to recreate this I noticed a different issue that didn't occur to me before:

I tried to do the same and got legs in a symmetric way on one of the arms. When I tried using symmetry to copy it to the other ones well, one leg disappeared.

[HoY]

Yeah, I've had that too, the symmetry options can get confused when you move an SPH created craft to the VAB or vice-versa

Sometimes editing the .craft line from SPH to VAB (or the other way depending on which way you've moved it) works, sometimes not.

It would be nice to be able to just switch from radial to vertical to mirrored symmetry options without having to faff about with externally copying .craft files around then reloading in alternate hangers etc

Press TAB to switch symmetry modes from VAB to SPH modes, and back. V does vertical snap, however don't go into vertical snap mode while in SPH mode while in the VAB or weird things happen lol

It makes the parts think there's collider surfaces in odd places and will let you connect parts into empty space in the building.

[stupid_chris]

Press TAB to switch symmetry modes from VAB to SPH modes, and back. V does vertical snap, however don't go into vertical snap mode while in SPH mode while in the VAB or weird things happen lol

It makes the parts think there's collider surfaces in odd places and will let you connect parts into empty space in the building.

Doesn't that require editor tools/editor extensions?

[HoY]

Lol yes it does. Sorry I forget sometimes that they are different mods, even tho they are both brand new I can't even consider building without both of them. I get extremely frustrated when either one of them isn't installed when attempting to build something purely stock, to the point where if there's a rule against any sort of mod I just don't attempt the challenge anymore!

[stupid_chris]

Lol yes it does. Sorry I forget sometimes that they are different mods, even tho they are both brand new I can't even consider building without both of them. I get extremely frustrated when either one of them isn't installed when attempting to build something purely stock, to the point where if there's a rule against any sort of mod I just don't attempt the challenge anymore!

I almost got worried stock did that and I was like whAT. But yeah, it'S just essential idk. RIP Deadbeef. I'm just waiting for the new version to get a bit more stable and for .21 before downloading it. Soon.

[TheZenGuy]

When I downloaded this mod, I tried to save my part. But subassembly doesn't show all of the option of what the module is!

Can you fix it, or am I doing something wrong?

[MonkeyLunch]

This is one of the most essential mods in my opinion, thank you for this contribution. I use this on every rocket build I do. I cant imagine this game without it. Saves mountains of work.

[MalfunctionM1Ke]

I have an issue here, when I load a Lift for my spaceship and I switch to the Ramp, I will only see nightsky and hear whirling wind. Cand End the Flight or what so ever.

Have to kill the game and restart.