Editor improvement: allow more possibility to assemble stuff

[Justin Kerbice]

Hi,

As editor will be improved for the next release it would be great to remove some ridiculous limitations which lead to waste a lot's of time in VAB/SPH for very basic assembling:

- sub-assemblies shouldn't need any more a free node ON THEIR ROOT PART, as long as one free node exists somewhere else,

- allow shielded docking ports to be connected (currently they just can be opened, and nothing else !)

- allow docking ports to connect when they are surface attached to something, currently they works only if they are stack connected !

like this (the node of the DP is disabled when surface attached !):

(spaces sucks )

                
                 subassembA
                       -
   VESSEL1-DP- ... -DP-|
                       |


only this works

   VESSEL1-DP- -DP-SUBA-stuff

KSP is allegedly let us build any crazy stuff we want but... we cant do this, we can't do that... all because of issues and limitations, at the end the freedom of building is not as wide as advertised, that's a shame.

[JayKaySss]

Allow parts clipping on symmetries. Sometimes I use symmetry and only 1 of the two sides attach. Also, please add attachment nodes to nodeless parts, especially the plane wings and wing surfaces. I have OCD and I want to snap my parts together perfectly.

[thelionheart12]

Can we please get a better snap-to when attaching rockets to decouplers? Seems like this is a problem that should and could easily have been fixed a long time ago.

[diomedea]

...

- allow docking ports to connect when they are surface attached to something, currently they works only if they are stack connected !

...

I like the idea of providing suggestions on how to improve the editor.

However, am I missing something? Surface-attached ports (Clamp-O-Tron both normal and Jr.) do connect in my KSP with any similar port, if properly aligned.

[LABHOUSE]

I like the idea of providing suggestions on how to improve the editor.

However, am I missing something? Surface-attached ports (Clamp-O-Tron both normal and Jr.) do connect in my KSP with any similar port, if properly aligned.

Like when you open the shield of the docking port in the editor you cannot place another docking port on it while still in the vab.

[diomedea]

Like when you open the shield of the docking port in the editor you cannot place another docking port on it while still in the vab.

Yes, definitely, the shielded port does not connect. However I understand the surface-attached ports case to be about any other port (shielded don't count as they don't connect in any position, their issue has to be different). As written before, I tried with two sizes of the Clamp-O-Tron, and they did connect for me. So, this case may show not a general bug, but a specific problem with the OP install.

[Technical Ben]

Can we please get a better snap-to when attaching rockets to decouplers? Seems like this is a problem that should and could easily have been fixed a long time ago.

Next update will allow manual tweaking via little arrows. So you can quickly place the part and/or then drag/nudge it into place (depending how they eventually add it in). With options like selecting different nodes, even after placing.

[LABHOUSE]

I still want to be able to do it the original way too.

[Justin Kerbice]

Yes, definitely, the shielded port does not connect. However I understand the surface-attached ports case to be about any other port (shielded don't count as they don't connect in any position, their issue has to be different). As written before, I tried with two sizes of the Clamp-O-Tron, and they did connect for me. So, this case may show not a general bug, but a specific problem with the OP install.

Just to be sure: in the BUILDING FACILITIES, "stack node"/connector node doesn't appears on a surface attached DP, so there is no way to connect it to another DP stack attached somewhere else. (At least with the standard clamp-o-tron)

Also, if 2 DPs are connected, you can't surface attach something (a tank for example) to the "outer"/not connected DP.

Also node snapping should be tweakable, they tend to snap too much on the wrong node (I can't count how much time I stick 2 parts into one like batteries banks, or a batteries bank into something else because the top node of it snap to the node of the other part ! Annoying !!

[diomedea]

Just to be sure: in the BUILDING FACILITIES, "stack node"/connector node doesn't appears on a surface attached DP, so there is no way to connect it to another DP stack attached somewhere else. (At least with the standard clamp-o-tron)

Also, if 2 DPs are connected, you can't surface attach something (a tank for example) to the "outer"/not connected DP.

Also node snapping should be tweakable, they tend to snap too much on the wrong node (I can't count how much time I stick 2 parts into one like batteries banks, or a batteries bank into something else because the top node of it snap to the node of the other part ! Annoying !!

Well, something seems to be working differently, can you see the stack node with both the DPs in the image below? (both the one surface-attached, and the one going to be attached to it):

Rest assured I have no add-ons to change how nodes work in that KSP install.

About attaching anything radially to a DP, no you can't do that, but you can't do that with anything, not just with docking ports. There are parts that are defined in the nodes attachment rules so to allow other parts to be surface attached to them, but the contrary rule so to allow parts to be attached by their surface to a node does not. If that was what you intended to suggest, you should rephrase it.

About the snapping being too easily done on the wrong node, do you know that with KSP 0.25 they made possible to exclude radial nodes from attaching just by holding the Mod key down (Alt key on Win systems) ? That should help for almost every need with attaching parts.

[Justin Kerbice]

@diomeda: this case works, the other one (opposite) didn't !

And I didn't know about this exclusion feature (thanks to the lack of doc maybe), but it looks like to doesn't match (again) what I wrote, the issue comes from both top & bottom stack nodes which are too big/too "snappy" for batteries banks especially.

[diomedea]

@diomeda: this case works, the other one (opposite) didn't !

And I didn't know about this exclusion feature (thanks to the lack of doc maybe), but it looks like to doesn't match (again) what I wrote, the issue comes from both top & bottom stack nodes which are too big/too "snappy" for batteries banks especially.

Maybe you should express better what the "opposite" case is? I already wrote there is no attachment rule allowing a new part to be attached to an existing one by its surface (instead of the rule allowing to attach a new part to the surface of an existing one), so the "opposite" case you mention is either what I already wrote about being impossible (and asking you to rephrase, it still is hard to get what you mean) or is a mirrored situation of what I showed, but to me those mirrored situations work as well.

About the exclusion feature, I know the case of the two stack nodes (top and bottom) of a low part being too close and so easily snapping the other way round (yes, most evident for batteries). That is why I wrote the exclusion feature being helping in almost, instead of in every case. But with a minimal amount of care I always could set those parts as intended, and I reckon some users like to have the possibility to connect parts by the "wrong" stack node.

[Justin Kerbice]

This is what I mean:

my case: in tue upper left

yours, which is ok in the main part of the pic.

Why "case 2" doesn't work whereas "case 1" do ? It doesn't make any sense from a user's point of view ! It's a huge unjustified limitation IMHO.

[diomedea]

The case you are presenting can be obtained if the root part in either subassembly is the tank, not the DP. Unless, you have an add-on that changes how the editor work. There is no way otherwise that you can make those subassemblies beginning with a DP.

Now, we all know that a subassembly can be connected only by its root part. So, very clear the DP can't show connecting nodes.

So, you want subassemblies to connect with whatever other part is presented to an existing assembly in the editor? That would mean to keep a number of nodes open (at least every stack node still unconnected) and would make the editor perform much worse than now, quite probably would crash because of the amount of transformations required about all those nodes while moving the subassembly.

Or, the alternative would be to build that subassembly with the DP as root. And then we are back to the fact already explained in my previous posts, no rule currently exist to allow attachment of new parts by their surface. That would require to implement a new attachment rule, that I think may be feasible. But, must be worded this way to make it understandable.

BTW, it seems you may also appreciate to find where these attachment rules I keep talking about are: about half way of this wiki page.

UPDATE: don't know why I did not think of that before. Have a look at the sequence below. Doesn't it make what you want?

Javascript is disabled. View full album

Curious about how I made it? Just by using SelectRoot. And if that is enough to solve your problem up to KSP 0.25, I believe the editor improvements in 0.26/0.90 are already set to include what you need.

Edited November 4, 2014 by diomedea
update added

[ringerc]

I couldn't make DPs snap together either, even when stacked (0.25). Maybe the basic first port you get doesn't support it? (Not at the PC with the game right now, can't remember model name).

Aren't they too fragile to bear much of a load anyway, and inclined to shear under load? I've seen people warning that they're so weak that moving a station has to be done very carefully to avoid shearing the docking ports, and people using scary hacks like tri-stack connectors of docking ports for strength.

(It'd help if it was easy to add a vertical decoupler between two parts that're already joined together somewhere else, but the game seems to have real issues with having one part connected to another by multiple decouplers, it only wants to snap the first one in place, the other just sits there, connected to one surface and touching but not connected to the other.)

[Justin Kerbice]

@diomeda: my bad, I forgot to mention in the case I shown is not about sub-assembly, I just take a tank, stack it to the probe core on the left, put the DP on its surface, then "unstack" it and try to connect the 2 DPs.

I know SelectRoot, just don't really use it that's much. And it's good for you maybe to speculate on the next release but looking at what they made "from" Enhanced Navball plug-in (the single arrow indicator is very poor)... I can't really be optimistic on what they could achieve with SelectRoot or others on their own.

@ringerc: that's what strut connectors are made for, I usually use 3 or 4 around a DP connection, and it's as solid as a nodes connection.

[diomedea]

Ok, got that. So you first build a vessel section attached to the probe core, then you detach it and try to reattach by the DP. And however, that section's first part is the tank, so is the only part to have nodes active, is effectively the root part for the section you are moving.

One of Squad developers or a modder would probably tell the correct name for that, I get the editor defines as "protovessel" each section it manages. But the rules for protovessels are quite the same as for crafts or subassemblies. Each craft has a root part, and other parts are attached to it (never the reverse) or to one part already attached; so a craft definition is actually similar (topologically) to a tree, new parts branch out from existing ones.

But the system has a few limitations: one, as discussed, a tree can only be "planted" by its root (I can reiterate, but am sure you agree, it would be absolutely terrible for performance to allow nodes on other parts be active while joining a section).

Another limitation exists IMHO: only one node effectively joins a part to an existing tree, is not possible to have a part joining multiple times (generally, with a number of different other parts), in what would be considered topologically a "loop". There are advantages in certain situations using closed loops (most notable with joints, only one is effectively keeping a vessel together with any single part; if you are familiar with ConnectedLivingSpace you probably found you can't make a looped living space), so I would like to see them implemented, however I guess most of KSP internal routines would require a deep revision (e.g., the one that checks for fuel available to engines).

However, back to your case, I can only recommend to use SelectRoot. Sure you need to plan in advance, define the subassemblies and change their root parts, then you can build the vessel from the main section and join each subassembly in turn. I never had an issue with that add-on, and when an add-on is such good, IMO Squad could directly use that. And however, let me tell there is no need to suggest to have that feature (back to the OP, now that the case is pretty well defined): Squad already has plans for it.

About how Squad implements things: everybody here has an opinion, you tell the ENB is better, but you rank among the seasoned players. Squad looks at how to make features intuitive for new players too, and certainly the navball arrow is more so and less confusing to them than the ghost markers used by ENB. But besides opinions, KSP is good for being so moddable: if any feature can be improved over the stock ones, some modders will do. SelectRoot (possibly with some updates) may remain a valid add-on, if the same feature was worse implemented in stock.

[Justin Kerbice]

@diomeda: ok thanks. But, called me stubborn donkey if you wish , why DP + tank stacked = DP connection works, and DP on tank surface = DP connection doesn't work ?

In a strict player point of view: stack or surface attachment is the exact same thing, parts are connected together, what mess is hide behind is not player's business, and that's one of my first post's points. This is where deep thinking and effort have ot be put to make the life of the players easy and prevent us to play the boring game on "how to get around this other issue" while building.

[diomedea]

Well, at least I got a thanks, I was beginning to doubt I would ever succeed in that .

So, in the latest posts we kept discussing more on ways to make possible the case you presented, and some of the mechanics involved in vessel building (behind-the scenes). Believe we can scratch that as accomplished.

Now, back to what seems to be involved in your consideration: from a player standpoint, stacked or surface-attached should not make a difference. Certainly that consideration did not bother me much, and I did not get it as your goal before. So, thanks for showing what it was in the end.

I did a bit of experiments to see if tweaking the attachment rules for those tanks and DPs used in the showcases above could provide the ability to surface-attach a tank to the back of an existing DP, but to no avail. Perhaps it could be achieved by modding stack nodes with the DP, but I feel the end result would not be as desired.

So it really seems like to obtain what you suggest, a different rule/attachment mechanic is required. But with that, I'll let developers (or modders) to consider how best to implement it, and avoid to get myself into further technicalities.