Spricigo

It may be the case that your craft is so that SAS can barely keep it stable following prograde, in previous iteration you got away with it, this time you just steered to much. In any case, there are many possible causes for the issue and, without picture are kind of blindly throwing some ideas. Maybe we get lucky and find some solution, but it is a whole lot more likely if we can take a look at the craft.

Something to keep is mind is that the calculated perfectly efficient maneuver is instantaneous. That means the maneuver will be "inefficient" just because it takes a greater than zero time while you follow a curved trajectory. Even if you hold prograde the slight misalignment between your acceleration and your velocity will add some m/s to the cost of maneuver. Just think about it. If you hold prograde while you burn, the first half of it will be slightly towards an "side" while the second half will be slightly towards the other "side". Don't it seems suspiciously like undoing the previous work?

I'm no familiar with MechJeb's particularities. Does a waypoint works as landing target?

the NCS is not a nosecone, is a fuel tank adapter. If you want a similar mk2 part there is already 2 options (Mk2 to 1.25 adapter, Mk2 to 1.25 adapter long). Maybe those are not exactly what you want, fair enough. Unfortunately "I don't like the options we already have" don't make the priority any higher for the part you requested. ...and there is quite along list of requested parts.

As often is the case, there are a mod

Incidentally, the deltaV lost fighting gravity is sometimes referred as gravity drag. Also notice that low TWR will result in long burn and, which is in itself inefficient (because of steering losses). In fact, the whole issue is that one can only go so far in reducing some cause of inefficiency before something else start to increase.

That's a tricky question you shoot at us. And the only answer we can give without any risk of being wrong or, at least, imprecise is: Depends on a lot of variables. Let's elaborate a bit on that. The Gravity Turn is regarded as the most efficient way to get into a orbit just outside the atmosphere. In a nutshell: give a small nudge towards west shortly after taking off and let the rocket steer itself into orbit and control the throttle to go neither too fast (because aerodynamic drag will be an issue), neither too slow (because some of the power/deltaV will be used to counter gravity until the craft get up to orbital speed). There is also the most efficient way to go from a low orbit to a higher orbit, the Hohmann Transfer. In a nutshell: a single burn prograde to raise your orbit so it touches the higher orbit in a single point, then another burn prograde at that point to match the orbit. In a ideal world, we could just combine both the Gravity Turn and the first leg of the Hohmann Transfer in a single maneuver to have the most efficient way to go to a higher orbit. But Kerbin is not ideal, it have an atmosphere. And the atmosphere will take a toll if you combine the maneuver, both in increased losses due aerodynamic drag and reduced Isp of engines. We also don't have ideal engines (weighting nothing and capable of instantly execute the maneuvers) thus resulting in further losses either way. And all that assuming heating will not be an issue. And it will be different for each different craft you launch. So, the most efficient way is probably something along a Hohmann Transfer right after a quite aggresive Gravity Turn. But I guess most players will not consider trying to find that precise trajectory as the most efficient way to expend his/her game time. Considering the chance of being too aggresive, maybe doing a regular gravity turn and a Hohmann Transfer once in space is a better idea.

It's unnerving that sometimes is tweaking to min that works ...or max to one and min to another. ...or the other way around...or no way! Ahhrrrggg!!!

Maybe something to keep in mind for the next time: always try to have the minimum of whatever that allows the craft to perform the task. Since springs cause issues in some circumstances, players often use structural or wing parts for the higher impact tolerance instead.

The "correct" point of view is the one that coincides with the Navball. The thing is: crafts are often symmetrical enough to make hard to notice when you are in this point of view. Also often is not the PoV that allows to better see what is happening. So, I strongly suggest to do like @AHHans (and many others): learn to use the Navball.

@antipro the, rather unappealing, answer is: not in stock KSP. You probably need to take a look at the mod's thread to be sure it's not a mod version issue or a mod conflict. Also keep in mind that the SoI transitions skew the prediction quite a bit and Gilly SoI is not exactly a large target. So, a more refined maneuver may be beyond what the mods can provide.

There is a weighting system, it takes in consideration which kinds of contract you accepted/completed/failed/declined and try to guess what you want to do. However sometimes it takes a while for it to adjust. Declining some contract of an unwanted kind may speed up that a bit.

Well, well. Memory playing tricks on me it seems... Thanks guys for correcting my mistake.

As far as I know unwanted contracts vanish as soon as I hit decline. You can set the penalty for declining contract to zero, but even if don't is not a big deal under normal circumstances.

It amuses me how often, when it comes to spaceplanes, someone will state a preference for X over Y because they are better in some aspect just for the next guy tell is the other way around in his experience. ...and I suppose now I, the "next guy", don't need to even tell what my preference is.

I actually misread the question so yeah, was meaning something else enterely. In any case, I still remember requests for older versions available on steam popping very often and the answer being "not on Steam". Seems there was some change while I was taking my long break from KSP. May someone tell me since when that Betas on Steam is a thing?

In the wish list of many of us, however Steam will always try to install/update to the last version available no matter what.

in the stock game. mods options include landertrons and smart-part Depending on how much thrust/deltaV is required Spiders or Linear RCS may also b considered.

Some even say we must.

Well, it was more like a implicit hint, however I even provided an example craft. I prefer to be a bit cautious with that suggestion because the combination of very light craft (as satellites tend to be) with SRB only fist stages tend to result in less than optimal launch trajectories. But it is cheap nonetheless.

No wings are necessary for this particular application. It just need to have downward propulsion strong enough to overcome the buoyancy. In any case, both ideas are viable, if maybe less practical for deep waters explodium

Use service bays to toggle extra volume open/close.

My solution for that kind of problem it's to arrange the docking ports pairs so one vehicle has it pointing Up while the other point Down. One of the craft is capable of raising/lowering itself when the other get in position above/below it Most likely to not include robotics parts in the elevation/lowering mechanism while the risk of bug persists.

Nothing useful there? Assuming that you are actually interested avoiding doing the math yourself.

Not sure if english is a right language for the Portuguese sub-forum. Maybe ask a moderator to move your post, or go back to Portuguese (assuming that was the language your previously used. Não tenho certeza se inglês é um idioma correto pro sub-forum português. Talvez peça a um moderador para mover seu post, ou voltar ao português (assumindo que foi o idioma que você usou anteriormente) Anyways, it seems that instead of attaching the part to the decoupler/docking port you attached it directly to the cargo bay. A screenshot may help to figure out if that is the case but I'm afraid that means you need to go back to the VAB to correct it (and redo the whole mission) De qualquer forma, parece que ao invés de acoplar a part no decoupler/docking port* você conectou na cargo bay*. Uma imagem pode ajudar a ver se é o caso mas desconfio que você vai precisar retornar pra VAB* pra corrigir isso (e refazer a missão inteira) *desculpe, nem sei como estão os nomes em português.