Splicing lifters and spacecraft

[Hotel26]

"If the SPH team played football against the VAB team, it is quite clear which team would win."

This is Goblin on the left and Archer on the right:

Recently, I upgraded both Goblin and Archer, and each time re-assembled their cross-product, Goblin Archer, afresh:

After re-assembly, I intend that the machine:

• be aligned on the pad to lift off and fly downrange (easterly) space-shuttle style, meaning "pull back on the stick"
• separates in orbit with the Goblin gaining first focus
• selecting Archer has both its (nose) docking port and RGU aligned with its wings and prograde (pilot's "up" matches the tail fin)

Getting this to happen in the VAB is a nightmare.  The VAB has a sense of Up but compass orientation of parts seems to vary from part to part and also may be based on how other parts are already aligned.  You just cannot pull off a sub-assembly starting with a dock or RGU, say, give it a twist, re-attach it, then repeat below with a counter-move so that only the target part gets a twist, because it doesn't work actually.

The most reliable method I have found is to take the whole assembly to the SPH and separate, re-orient and rejoin every key part there.

The SPH has a sense of Prograde (the hangar exit) and also Up.

I'm not exactly asking a question, nor sure enough about my strategy to call it a tutorial, but I certainly expect there are going to be plenty of great insights on this topic!  Have at it.

---

Here's the answer to one question implicit in all this, though: "the SPH football team would thrash the pants off the VAB team -- every time!!"

Edited November 20, 2018 by Hotel26

[Hotel26]

One thing I haven't mentioned and it's almost certain to come up: sub-assemblies.

I abandoned using them a couple of years ago when I found that the Load/Merge route is much more convenient for exactly the kind of situation as above.  (As I recall, you could not, at that time, keep a "stock" sub-assembly library for use in any save.)

I may have to go re-experiment with loading sub-assemblies as a route to solving the orientation confusion, assuming it can actually provide a better solution.

(Although one more trip through the SPH on this exercise just worked like a charm...)

Edited November 20, 2018 by Hotel26

[Rocket In My Pocket]

I read this but I'm still not entirely sure what your problem is exactly lol.

I also build my Shuttle in the SPH, the Launcher in the VAB, then join them together; But I've never had any problems with it.

Sounds like you are having issues with control part orientation? I typically use the sub-assembly system myself, maybe that's why I've never had that problem?

[Hotel26]

3 minutes ago, Rocket In My Pocket said:

Sounds like you are having issues with control part orientation?

Yes, that's it; I am.

OK, for grins, I will replay this using a temporary sub-assembly and see what happens.  (I'll report back...)

[Geonovast]

I think if you learn how to use the re-root tool (Which works on parts that are translucent/not attached, so therefore, subassemblies), all of your problems with wither away.

 

[Hotel26]

58 minutes ago, Geonovast said:

I think if you learn how to use the re-root tool

Nope, because I use that already in this process quite extensively.

I tried sub-assemblies and they help inasmuch as moving rockets in and out of the SPH has the cost that you have to get it back into the vertical in the VAB (easy, click on the root node), but then you have to jockey it around to get it back into the middle of the launchpad marker ring -- and that's never fun.

So I think I will use a temporary sub-assembly for this and then discard it afterward.

What did help me somewhat this time was the HitchHiker at the stern of the Goblin.  It's hatch is offset at 45 deg so that the Terriers don't block hatch access.  It's a good marker in the VAB for where the orientation of the Goblin itself should be...

[swjr-swis]

I think key to your issues is that parts in the VAB are by default orientated with their 'belly' to North instead of East. Which makes rockets by default tilt sideways (yaw) on their way to equatorial orbit, instead of tilting down (pitch). This default is pervasive, because even when you rotate the entire rocket eastwards, any time you pull off a part or section that has not been individually rotated before, or when you hit space to reset it's orientation, it will go back to this north-facing default and be off by 90 degrees with the rest of the rocket again.

If you like your rockets (and every sub-section of them) to be orientated East to make gravity turns be about pitching instead of yawing, you're going to need to get into a constant habit of rotating parts 90 degrees, every other step.

Or, you could bat your eyes at @Snark and ask for his VABReorienter mod. It will turn the default orientation in the VAB such that these issues become a thing of the past.

 

Subassemblies do not really help, btw, because they have an even more irritating default behaviour: they forget their root part orientation the moment you save them, and only the root part counts in how the subassembly loads into the editor.

[bewing]

1 hour ago, Hotel26 said:

but then you have to jockey it around to get it back into the middle of the launchpad marker ring -- and that's never fun.

It works a lot better in the VAB if you build everything facing the default direction, make the nosecone at the very top be the root part, detach everything below the root part and put it aside, delete the nosecone (root part), place a new nosecone and move it straight upwards with the mousewheel, give the entire bottom of your rocket ONE 90 degree twist, and reattach it all. That way, it's in the exact center of the pad and you did not have to do a lot of twisting and retwisting games.

 

[Snark]

Hi @Hotel26,

Details below, but the executive summary is that the VAB is just as deterministic and easy-to-build as the SPH.  The problem is that you have the wrong mental model for orientation.  (Not your fault-- it's KSP's fault for being confusing about this.)  As soon as you mentally re-orient yourself so that your mental model matches what the VAB is actually doing, things make a lot more sense.

In short:  Your confusion isn't caused by the VAB not having an orientation (because it does have one).  Rather, the problem is that the VAB has the wrong orientation, and that's what's confusing you.

 

6 hours ago, Hotel26 said:

The SPH has a sense of Prograde (the hangar exit) and also Up.

Yes, and so does the VAB.

• SPH prograde = eastward
• SPH up = skyward
• VAB prograde = skyward
• VAB up = southward

It's perfectly consistent.  Let's say you go into the vehicle editor and plop down, say, a Mk1 command pod.  What happens in each editor?

• In the SPH: The pointy end is pointing prograde (eastward), and the hatch is pointing up (skyward).
• In the VAB: The pointy end is pointing prograde (skyward), and the hatch is pointing up (southward).

Your problem is that in the VAB, you're thinking of up as up.  It isn't.  Kerbin-up is ship-prograde.  Kerbin-south is ship-up.

 

6 hours ago, Hotel26 said:

The VAB has a sense of Up but compass orientation of parts seems to vary from part to part and also may be based on how other parts are already aligned. 

No.  That's not what's happening.  Compass orientation is perfectly consistent in the VAB, exactly the same as with the SPH.

What you're missing is that the VAB definitely has an "up", and it's pointing south.

The reason this causes you confusion is that you're missing that systematic and pervasive bias in the VAB, so things seem random.  "Sometimes I put a thing there and it lines up with parts already placed, but sometimes it doesn't."  That doesn't mean the VAB is inconsistent-- it means you are.

Newly placed objects in the VAB always have their "up" direction facing south, regardless of the orientation of already-placed parts.

And actually, it's even more pervasive than that:  If the ship's facing some other direction than the default, and you detach one of the bottom parts... it suddenly snaps to turn 'round so that its "up" is facing south, and if you want to re-attach it the way it was, you have to actually rotate it!

 

All of this probably wouldn't be so much of an issue if the VAB actually had its default orientation set up in the obvious sane way:  VAB "up" should be west, not south.  "Doing a gravity turn" should consist of pitching down, not yawing right.  But it's not set up that way, and when you try to make your ship built in that orientation, you're fighting the VAB every step of the way.

In short:  Your experience in trying to build stuff in the VAB is exactly the same as if you try to build a spaceplane in the SPH that's lying on its right side rather than right-side-up.  Go on.  Try it.  Confusing, isn't it?

So, given that you do in fact want to build things facing eastward rather than northward, what can you do?

Well, there are a couple of ways.

First, if you want to do it entirely in stock:  Just go ahead and build everything in the VAB with your ship facing north, the way that the VAB inexplicably wants you to.  Then, when you're done, choose the "rotate" tool, and click on the root part of the assembled ship, and then rotate the whole shebang to face the correct direction.

This approach has the advantage of being stock.  It has the disadvantage that you're basically "fighting" the VAB every step of the way, which means that you have to do this silly dance every single time you build a ship.  Actually, it's even worse than that, since any time you want to go back and edit the ship, you need to rotate it back to facing nonsensically northwards, then do your edits, then rotate it back again.  It's stark raving silly.

Or, alternatively, you can just install this mod, as @swjr-swis suggests:

This mod is very simple:  all it does is change the default orientation of the VAB to face east instead of north, which is exactly what you want here.  Do that, and the VAB will "just work" in pretty much the way you expect.  In other words:  The "stock" approach described above requires you to change your mental model (and play style) to match the stock game's.  VABReorienter, on the other hand, changes the game's model to match yours.

Personally, I like the second way better. 

 

Disclaimer:  When I talk rather cavalierly in this post about how the VAB's default orientation is "wrong" or "silly" ... I'm not claiming to speak for everyone, or even for most folks.  I merely speak for me, and for people who think like me.  There are plenty of players who, for good reasons of their own, prefer it the way Squad set it up.  However, I need not go into that because such players are not the target audience for this thread.    For people who have my mental model of the game, the stock setup doesn't work and is irretrievably silly.  And from your writing, it appears to me that you're running into this problem because you have essentially the same mental model that I do.  So, my remarks in this post are addressed to people like that.

[FleshJeb]

1 hour ago, Snark said:

 Then, when you're done, choose the "rotate" tool, and click on the root part of the assembled ship, and then rotate the whole shebang to face the correct direction.

Or Shift-click to grab the whole thing, instead of having to find the root part.

[Guest]

In the VAB, I just build my rockets facing the default orientation (North), then rotate them 90 degrees prior to launch. Ensures that everything faces the right way.

[Hotel26]

What a journey!?

I appreciate the extensive and well-written answers already submitted within this topic.  However, I still had recurring difficulties.

I think I am now able to delineate the specific problem I was experiencing.

In the context of splicing two assemblies, a retrograde-facing dock may be used on one of those assemblies.  Taken from the toolbox, it must be inverted to do this.

I always use 'S' twice to do this, but that unfortunately is a 180-degree rotation around the transverse  (pitch) axis.  This is the problem when this component is used as the attachment point because it defines the frame of reference for the assembly being attached.  Pitch leaves the pitch axis invariant but it moves the all-important vertical axis by 180 degrees, thus inverting "up".  Joining two assemblies at respective parts that have different senses of up creates one winner and one loser.  If both assemblies have control points, these parts have to be mated with identical frames of reference.

I corrected this experimentally by then performing 'Q' twice to roll the vertical axis back to where it should be in the VAB.

Obviously though, instead using 'A' twice (rotate 180-degree around the vertical axis) leaves the vertical axis of the frame of reference untouched.

You can perform an experiment in the VAB to see this.  Take a RC-L01 RGU and perform the following separately:

1. space, 'S', 'S'
2. space, 'A', 'A'

You will observe, from the top view of the RGU, that the orientation of the integrated circuits is 180 degrees different.  And in the VAB, it is in this plane that the sense of "up" lies!

In my assembly, (Spunk and Superhawk), at the splice point, I notably have a Clampotron Sr, an AE-FF2 fairing and a heat shield[*], all of which were mounted in the retrograde direction and had been inverted by me prior to assembly.

The bottom line is to use 'A' twice to invert a part, not 'S' (unless you really have something unusual in mind).

* confusion on my part about heat shields and which face is prograde; it should not have been inverted

                                                                                                         

One feature I'd really appreciate having in the SPH/VAB is to be able to select a potential control point part (e.g. Okto2) for staging with an action of 'Control From Here'.

When A and B are spliced, one uses Reroot to select which vehicle will control and thereby inherit control after separation,  Unfortunately, when returning to the other vehicle, it's control point has been, by default, set to the nearest part to the former attachment point that can take (or define) control.  If this is a rear-facing part, like a fairing, there is low utility.  I hacked around this in this Spunk Superhawk combination by inserting a redundant, prograde-facing dock

Edited January 12, 2019 by Hotel26