HvP

I'm guessing that the lower central portion was first attached to the bottom of the upper half normally (the small white separator was attached to the small inline battery above it.) By selecting the "translate" gizmo you can click the lower part, hold shift, then slide it downwards to open up a gap. Then then you can attach struts between them to make it appear that the struts are holding it together. Once you've done this you can place the other surface attachable parts, like science experiments and RCS thrusters anywhere you want. You wouldn't be able to attach any center node attached parts in the gap between the two sections however because those nodes are technically being used to hold the ship together even though cosmetically there is a gap.

@diggzakk You have found the German version of a problem that has been in the game for a long time. The SC-9001 Science Jr experiment is what you need. Once you put your ship on the launchpad and then right-click on that part you will notice that it says "Observe Materials Bay" (or the German equivalent.) But it is only called that in the menu when you run the experiment. I don't know why they insist on using two different names for that equipment. I assume that "materials bay" is the term that has been translated as "frachtraum". https://wiki.kerbalspaceprogram.com/wiki/SC-9001_Science_Jr. Even in English it is confusing because our contracts ask for a "materials bay" when it requires a Science Jr. I hope that this helps.

Check if you have enough liquid fuel on board. Many of the contracts specify which type of fuel you must have. If it requires 6000 liquid fuel then you must have that much remaining when the other requirements are met, and it does not count the oxidizer towards your goal.

He mentioned that he tried recovering them from both the Space Center view and from the Tracking Station as well.

Odd, there really should be no reason they won't complete. It looks like another bug. I found similar reports in the bug tracker for tourist contracts not completing under similar circumstances: https://bugs.kerbalspaceprogram.com/issues/17982 https://bugs.kerbalspaceprogram.com/issues/17972 I haven't encountered this problem yet myself, but I would highly suggest that you please add your experiences to the bug tracker if you can. There does seem to be a lot of cleaning up to do in the new release. Also, you don't need to hack the persistence file. In the ALT-F12 cheat menu there is a "contracts" section where you have the option to force individual contracts to be marked as complete.

You might double-check the settings page. There is an option called "Fuel Transfer Obeys Crossfeed Rules." If that's enabled then it means fuel won't flow across parts that don't permit fuel crossfeed such as a heat shield or through docking ports with fuel flow deactivated.

Let's not forget the new batch of console players for which it is impossible to just install mods for this information.

Judging by your screenshots you're going in the right direction, that's half the battle. If you have the inclination right then all that's left to do is put your apoapsis and periapsis in the right place. But, it's important to understand what the directions on the NavBall do when you burn your engines in different directions. Burning prograde raises the opposite side of your orbit, and burning retrograde lowers it. Burning normal inclines the half of the orbit in front of you "upwards" in relation to a line passing from the midpoint of your burn through the center of mass of the body you are orbiting. Burning anti-normal of course reverses the incline of that half of your orbit. (Most people make the mistake of assuming the inclination changes are relative to the equator, but that's just how they are measured. The effect on your orbit is always in relation to the direction of your orbit, we just usually do them to adjust our relation to the equatorial plane.) Burning radially-out will raise the part of your orbit 1/4 away around in front of you and lower that part of the orbit 1/4 of the way behind you (reversed for radial-in.) It has the effect of sliding the whole circle of your orbit one way or the other. THIS is the best way to fine tune your orbit quickly. The advantage this has is that it allows you to change your apoapsis and periapsis without actually being at either. I suggest you experiment with burning radially. Look for that blue circle on your navball and see what burning in that direction does to your orbit. You can also point some degrees between the prograde/retrograde and radial markers to further fine tune the orbit if you're up for a lot of practice. And as @GrouchyDevotee said, these maneuvers should be done at the points where your orbits intersect. Because you won't be able to move the exact point you are at in any significant way you should start in a place this is already at the right height (at the height of the target orbit.)

Thank you @bewing for following up on this thread. It's so easy to overlook since most of us tend to dock with relatively small craft with center stack attached docking ports on the front. I'm not surprised the bug squeaked through until now. And big thanks to @antipro for some extremely helpful demonstrations of the problem. Hopefully, it won't be too hard to address in further bug patches. The best thing you can do in this situation is manually align the station's docking port with your smaller craft then just set it to SAS hold position (not target tracking). Then switch to your smaller craft and rotate it into a straight line with the station's docking port before coming in close for final docking.

Correct, that looks like the only way it works right now. Control points only track targets properly when they are aligned with the root part's axis. I tested this by placing different types of docking ports, command pods, and probe cores around a cylindrical test vehicle. If my root part was in the central stack then only the docking ports at either end of the stack held the target properly when at close approach for docking. Any docking ports or control points that were offset from the central stack or aimed radially outwards do not track properly. HOWEVER! If you use the re-root tool to make a radially mounted docking port the root port then that docking port DOES track the target correctly. Further testing shows that when SAS is tracking a target it will align your navball to face in the direction of whichever control point you've selected BUT it will use the base of the root part of the craft to determine "center" for tracking purposes and calculates the angle from the target to the base of the root part - instead of the angle from the target to the selected control point. This means that if you are using a large ship and its root part is placed at some lateral distance from the docking port you are controlling from then the SAS will keep turning your ship to bring the base of its root part in line with the target - which causes the docking port you are trying to use to continue to point away from the targeted docking port. @bewing I have updated the bug-tracker for this issue to include the above steps to replicate the problem. Maybe you have some thoughts on this. Again, for SAS "hold target" tracking the angle from the target docking port is being calculated to the base of the root part of the ship being controlled rather than calculating the angle to the selected control point.

There's always going to be at least one stage reported in MechJeb, even if it's zero, just to at least show you that you have zero delta-v available. If you mean the one that gets added once you go to the launchpad, then it goes away as soon as you press the space button. As for the flooded KSC... haha, nice work! It's a known bug in the Scatterer mod and seems to go away the next time you change scenes. https://forum.kerbalspaceprogram.com/index.php?/topic/103963-wip131-scatterer-atmospheric-scattering-v00324-28012018/&page=243

Yea, that sounds like the culprit! Most people start with the command pod and work downwards and I'm sure MechJeb was designed with that in mind. Just use the re-root tool to root to whatever you intend to be the last pod to consume fuel and I think it should work as expected. Happy flying! edit: not trying to be selfish, but if you can confirm that this fixes your problem, go ahead and mark my last post as the best answer so that other people with the same problem can see how to fix it.

Ok, I think I've figured it out after taking a look at my own install. In the VAB MechJeb seems to calculate fuel usage inward toward the root part (or something like that.) Using the re-root gizmo (the one that looks like a Z next to the rotate tool) you can choose a new root part for your rocket stack, and when one of the parts in the middle of the stack is chosen as a root part it will drastically reduce the reported delta-v. It's as if MechJeb stops calculating the fuel contribution of tanks above the root part. When you launch the same ship it seems to correct this error and calculates the stages normally again. The first part you place in the VAB automatically becomes the root part unless you change it with the re-root tool. I would recommend making sure that your final command pod is always selected as your root part if you want MechJeb to report correctly in the VAB. It's usually best practice to start building from your topmost command pod first and work downwards and this is probably the assumption that MechJeb uses. This also explains why your stages reported differently when you merged the ship in the VAB. This may be intended behavior, I'm not sure but maybe @sarbian is already aware of this result. The zeroed out stages represent those staging events where you press the space button but don't necessarily have a delta-v number associated with them. For example, staging a decoupler or activating an engine for the first time. The stage that shows the engine activation isn't shown in the VAB but it gets added to the bottom of MechJeb's delta-v list on the lauchpad. You can see that zeroed out stage disappear in MechJeb's delta-v list if you set throttle to zero and then hit the spacebar on the launchpad. Also, MechJeb is automatically taking elevation into account even when on the launchpad. In the VAB the numbers are calculated for 0 meters elevation, but depending on the height of your rocket some engines could be 100 meters above sea level when resting on the launchpad. This will only minimally affect the delta-v stats but it does explain some small discrepancies. I hope this is what was causing your problem. Do let me know if it helps.

@putnamto I think the ghost stages that are all zeroed out might represent your fairings which I'm guessing were in their own stage before you disabled the staging for them. Just as an experiment: what happens if you reassemble the ship without the fairing components?

I'm wondering if it might be a complication of fuel flow priority being changed on those Rockomax tanks. I don't know how MechJeb or KER handles fuel flow priority, but it could have a huge impact on delta-v if that large decoupler had its crossfeed enabled.

@putnamto have you tried seeing what the KerbalEngineerRedux mod shows? For all I know the two mods may just draw their deltaV numbers from the same code but seeing how a different mod shows the stage dV might give a clue as to where the discrepancy lies.

Confirmed, I'm getting the same behavior on my system using a recreation of your test vehicles. This appears to be a stock bug that I was unaware of. Off-axis control points do not correctly aim at target when under SAS control. It seems to be a problem with the stock target tracking and not the docking ports themselves because MechJeb WILL target correctly under the same conditions using it's "Smart A.S.S." targeting controls. It appears to be a continuation of this bug in the bug tracker. I've added my own report to the bug tracker now and would suggest you do as well if you'd like. For now it looks like the only work around is to do the docking without SAS target tracking assistance or use the MechJeb mod's "Smart A.S.S." controls to do the orientation instead of the stock SAS.

Excellent videos showing the problem. Are you running an older version of KSP by any chance? I seem to remember a bug like this being addressed in a changelog somewhere. In the meantime, I'm going to do some testing on my setup and get back to you.

I see what you're saying @GrouchyDevotee and it's true that what you're describing is the preferred docking method. But the original poster says that he can't get other test vehicles to aim correctly either so I think it would be worth it to try and track down what's actually causing the problem. Just to be clear @antipro it is normal operation that the two ports won't necessarily be aligned square to each other, but they should at least point at each other. Do the station or your test vehicles ever move or do they just sit still? And if they do move, do they ever point at the target marker on the navball?

I think the problem is shown in the second screenshot. The station's SAS is set to hold target, but you can see from the navball that the SAS is not aligned with the target marker at all. The pitch/yaw indicators in the lower left also show that the station isn't even trying to move to align with the target. For some reason SAS control isn't functioning correctly, and I'm not sure why.

Can we see a picture of these test craft, too?

@antipro Let's try and work the problem from the ground up. Do you have sufficient control authority to turn? That includes reaction wheels and electric charge to run them or sufficient monoprop remaining. Also, do you have the MechJeb mod installed? It has its own version of SAS that if selected will override the stock SAS directions.

@antipro I would strongly recommend that you try installing one mod that will go a long way to helping you with docking. https://forum.kerbalspaceprogram.com/index.php?/topic/40423-131-docking-port-alignment-indicator-version-670-updated-053117/ Docking Port Alignment Indicator gives you an extra window with orientation guides to help you point in the right direction for docking. Be sure to watch the video in that link as it will give you detailed instructions on how to use it (make sure Youtube's annotations are turned on to see the video text.) Edit: I see from your pictures that you actually mean the station SAS isn't rotating properly to automatically face the target. I see no reason for that. I still recommend the above linked mod, but it is used for manual docking control and won't fix your SAS problem, sorry. I need to have a think about this.

You shouldn't be concerned about making copies as long as you aren't sharing it with anyone else. Squad, the company that developed Kerbal Space Program, has officially endorsed making multiple copies of the game for personal use. The FAQ on the KSP website specifically says: "Can I install the game on more than one computer? Certainly, you can download and play the game on all of your personal computers with the same license. Even if some are Windows and some are mac computers." Also, if you are using Steam to download KSP and plan to use mods in your main saved game then it's recommended to always run KSP directly from a backup copy in another location and install the mods on top of that copy - not your Steam copy. That's because new updates to the game aren't always compatible with mods that haven't caught up yet and autoupdates in Steam may break a modded game. In this case you will be running the game directly from the KSP executable file in the new folder outside of Steam. KSP has no DRM and is intended to be run freely without needing the Steam interface.

The larger part you are trying to attach your small plates to is not on the center of axis. The root part you lay down first defines the center of axis, and the other parts will get mirrored to either side of that. But I assume you put down two large plates first, then attached two more on one side of those. KSP sees this arrangement as: * One large plate as root part; one large plate attached along the center-line behind it; one large plate attached radially to each of those in the center, but only on the left side; no plates mirrored on the right side of the center-line. In other words, KSP treats your first column of large plates as the center line. So KSP can't mirror your smaller plates because as far as it understands there is nothing to attach them to on the other side. As an experiment, try this. Place down a long I-beam first as your root part. Now attach the large plates to the side of that in mirror symmetry. You can now attach your small plates to the edges of the large plates in mirror symmetry because it will all be mirrored around the I-beam along the center line.