Kesa

A LKO/ LEO station still is cheaper to refuel from the Moon or an asteroid than to a gateway orbit, so there are logistical losses anyway. Apparently at least, since as Lisias and 5-th Horseman point, you gain from carrying less stuff around, especially smaller interplanetary stages. And not to a point it matters, for refueling from space (in addition to it being cheaper, logistical Dv losses of going to the gateway orbit rather than LKO are less than half coming from the Mun than from Kerbin). Gargamel, you make a very important point that I missed, and kudos for Blackmw for bringing gateway orbit, and providing altitude for a good median one. I'll crunch the numbers probably tonight. I could have sworm somebody talked about a 15,000 km orbit, and I remember that long ago I thought that the border of Kerbin SOI (either side) was the best place for a station midway through interplanetary travels. That was what I had in mind when I said as close as possible to Kerbin. 2.5k km, and even 1.5k km sounds high to me, but I could not have predicted gateway orbit were at 600km, so I'll likely be surprised.

Snark and Bewing nailed down the rescue part. For your future endeavours though, I'm going to adress the "refuel twice" bit. Yes it would likely cost you more fuel than you'd gain. Not only a station in a 19,000km circular orbit is not actually on your path to Minmus/other planets, because you'd go there with an eliptical path, but due to the Oberth_effect, you want to burn as close to Kerbin as possible, for as long as possible. As unintuitive as it sounds, the efficient path from Minmus to Jool involves lowering your PE near Kerbin.

If you aim at Minmus, the KSC is i Minmus rotation plane twice a day. You can inject in LKO with the right inclination and do a hohman transfer without needing to wait. For interplanetary transfer, it's more complicated because launch windows are every years, not every 20 minutes (once in LKO), and chances are Kerbin is not in the tilted orbital plan of your target. If it is, then you won't have plan change to do (but you probably shoud, partially at least, especially if your target has no aerobraking or is significantly less massive than Kerbin). If you do have a plan change to do, then a few methods can be used (which also work for trying to rendez vous two ships efficiently) : Matching plan. Combine your ejection speed with a bit of plan change. Eg. if you're few tens of days before ascending node, burn down in order to reduce as much as possible relative inclinason (it will rise again without reaching zero). then do a plan change at the new Ascending node. Getting an encounter. Push your AN/DN to the rendez vous. Inclinaison change have no impact on where your craft will be half an orbit later, and have maximum effect for 90-270°. So this method is not usable without a midcourse correction burn in a "minimal" Hohman transfer. If the AN/DN manoeuver nodes are close enough to you and to the rendez vous, rather than trying to match plan in two burn as in 1, you can do a plan change mid burn that will pull or push the DN/AN to the rendez vous and should give you an encounter. You benefit mainly from aerobraking, oberth effect and burn combinaition (when you get captured by the planet, you effectively get to match its inclination, but potentially for cheaper than by only a burn midflight). If the AN/DN are midcourse, none of method above work, but that's because you're in a worst case scenario, and a full change plan is actually your only option if you don't wan tto wait for the next launch window, or use gravity assist shenanigans to change plan (EVE is great for that, and it also can be useful to sling you to reach higher or lower bodies). I suspect you're using 1 currently, and I expect 2 to be better though it likely depends a on the situation, and it's worth plotting them both to see which is the best. For Moho for example, the absence of aerobraking, the poorer Oberth effect than Kerbin ad it being closer to the Sun mean orbital plan change might very be more efficient closer to Kerbin and mid course, favoring option 1.

If you are interested in reusability, fully recoverable TSTO are also possible, and probably offer greater playload, though lesser recovery % (like you describe, with chutes deployed while staging). Doing so, a lot of people tend to assume you should circularize before the first stage reenters the atmosphere, but the first stage actually does not disappear until as low as 35 km, which allows to make fairly balanced and stages and should increase playload ratio. One should be able to make fully recoverable single launch caveman Minmus lander that way. https://prnt.sc/jumoe6

Distances are measured in kilometer (km), not sure what you mean by "miles". Due to Oberth effect, you want to do you ejection burn as close to Kerbin as possible. TWR is irrelevant. If you don't have enough acceleration, you can split the burn, performing what's called apsis kicking. Even if you absolutely want to make your burn all at once, doing a suboptimal insertion from LKO is more efficient than going into a high orbit and then make an "optimal" burn there. TWR of 1 is more than comfortable enough to make interplanetary ejection burns at 80km in LKO. For a spacce station or something meant to be docked with, I would go a bit higher than the bare minimum, say a circular 120 km one. It makes it easier to rendez vous from Kerbin, as well as from your resupply outpost on the Mun or on Minmus after aero breaking (preferably the latter).

That's to target Kerbin. To target the Sun, land the targetted kerbal on the Sun instead.

I think it's intentional. It feels very weird at first, and is quite annoying when trying to cancel a big overshoot, but it gives a wider range of steps overall, allowing fine tuning by using the "reverse" direction.

You definitely did not give a try of pushing the retrograde vector back to increase prograde velocity, I don't know if I explain the method well, but I encourage you trying it. You got to be patient and methodic with mouse wheel. You got to be patient and methodic anyway, even using one of the mod I provided a link for. The method is dichotomy (https://en.wikipedia.org/wiki/Binary_search_algorithm) which is trial and error but in the fastest possible way. Using mouse wheel, you have to be aware that you can't just roll a little bit when trying to be precise. The control allows you to be precise down to the few hundredth of m/s but still allows to roll a to hundreds of m/s in a couple of seconds, so you can't expect it to be linear, and it is not : rolling three increments at once modifies the speed much more than three times rolling one increment at once do. So typically, you roll by three increments in one way, the first time you overshoot, correct the other way with two increments, and then one increments. If you don't have increments on your wheel, then yeah, I don't think wheel is an option for MN Yes you do have to count the increments, and no it is not as much hassle as it sounds. The hassle comes from the binary search, which you have to do in any case. I actually find mouse wheel faster than MN Evolved, even though a bit less comfortable : whatever arithmetic base use the stock mouse wheel control is closer to 2-3 than the base 10 used in mods and thus more practical for binary searchs. The alternatives to performing a binary search down to the max precision you can get are : - being less precise (a genuine option, precision to the hundredth of m/s, while being cool, is not that much beneficial over precision to the 1 to 10 m/s or so + correction burns) - somehow computing the required velocity (and writting it down with a mod, or even executing the manoeuver directly) - having the manoeuver plotted/computed/executed by a script (the downside are that the script may not exist, and that you don't understand it unless you wrote it ; I do understand Hohman transfer but could not do it the way Mechjeb does it)

You are using manoeuver node wrong. As you realised, pulling a button to increase velocity has more effect than pushing. But you are not using it to you advantage. If you want to fine tune, youd should always be pushing rather than pulling, eg. using the retrograde button to increase your prograde velocity. You should also use a mouse wheel for fine increment. You can be precise up to fractions of a m/s using stock nodes, more precise than practically needed. Manouever nodes are underrated, there is a huge amount of things people do with mods which can be done with manoeuver nodes. On the top of my head : Hohman transfer window (with dummy crafts) Suicide burn direct injection (with dummy craft) What is somewhat lacking IMO is the inconvenience of changing the timing of the MN, for both small and very large time increment. Some modes that improve MN gui are : https://spacedock.info/mod/1087/Maneuver Node Evolved The first one is better IMO.

No problem, I was just being nickpicky (although I also genuinely did not get that you were using gas in that meaning, which is perfectly fine then, I even see it as a nice pun).

Dv and Rocket equation is a very bad indicator for cost efficiency of first stage. For non reusable small to medium-big launchers, using SRBs in the first stage almost always reduces the cost of the launch, while augmenting its mass. If you use both SRBs and LFO engines, which is justified for mainsail and above classes of launcher, you are going to stage them at some point, and you might as well ditch some empty tankage. Macollo uses that technique in the video below to beat this challenge : which consists in building the cheapest non reusable launcher (in fund per ton of playload in orbit). and it does use fuel tanks on top of SRB, and even does in a way which decreases drag, not increase it. Also, as said above, in addition to the space shuttle being basically just that, Lfuel tank carried by SRBs, it has been cosidered for an heavy (Saturn) Rocket launcher. SRB are actually very cheap IRL too. Their solid propellant is not solid gas (an oxymore btw, at least in standard conditions), nor an unstable solidified gas, but a solid propellant possibly completely unrelated to any liquid fuel. For example, gunpowder is the earlier rocket solid fuel (and the earliest rocket fuel), used by medieval China and Corea. Now both solid and liquid fuel are relatively very cheap, and usually amount to 1% of the price of a launcher (several percents in KSP, still not the main part). A solid rocket booster is just solid fuel wrap in metal or whatever. You ignite the bottom and it burns, and because of the shape of the wraping, it will produce thrust (it can even produce a varying, though predetermined, thrust). That make them extremely simple, reliable, and cheap. A liquid fuel engine on the other hand... They vary a lot in complexity, some can gimbal, some can throttle, some can be ignited several times or indefinitely (most can't). But what makes almost all of them more complex than a SRB is that after ignition, you have to pump fuel into them, and sometimes even pump filler (eg uncompressed helium) into the liquid fuel tank to maintain pressure and fuel flow (the few exceptions are engine who use the acceleration of the ship to push fuel into them ; they may make for simple design themselves but require other engines to be fired). That makes them much more complicated and thus expensive than their solid counter part.

Really nice! If you're into coding, you should definitely check if you don't already know it (no sure it's stable or recent). It lets you writte program to act on the rocket, like, for example a PID SAS with the correct input and behaviour.

I can see why you say that and I guess I even agree Rocket equation tells you should get rid of dead weight ASAP, stage as often a you can. Ideally, you should be throwing fraction of fuel tanks as they get dry, and fractions of engines as you no longer need them. In practice, in KSP, the wet to dry ratio of tanks is the same from oscarB to the Kerbodyne, meaning if you want, you can have many tanks for one engine, meaning if you follow the rocket equation, you'll be dropping drop tanks in between regular stages, where you drop engines. I challenge you to make the rocket of 18t with a detachable empty mk1 pod and a chute as a playload, a single reliant as an engine, and the biggest possible Dv Drop tanks is not about carrying useless engines, it is about dropping useless tanks (save for things like the Space Shuttle or Adeline, which are about both, for understandable reusability reasons - and fit the launcher category). IRL, one drop tank is often too many drop tank, if anything because big fuel tanks have a better wet/dry ratio, or because simplicity cost and reliability supercede mass optimisation, but in no way because of the rocket equation. And even then, the point of drop tanks for aircraft is more flexibility, modularity, than efficiency. I can understand using them for a similar purpose for a generic partially reusable nuclear interplanetary stage, which receives various amounts of fuel depending on the destination, in both RL and KSP.

Have you tried to detach the bombs when landed?

You are activating torque system (RCS or action wheels) which will alter rotational momentum of the ship. The command and its effect is independant of referential, they are relative to the ship (causing him to pitch down, or to slow a pitch up -or the opposite if like me you changed the control because a keyboard is not a joystick, up and down being define by the control point of the ship). The referential is just a way to describe things here, but has no bearing. Both descriptions are valid, but the one where the ship rotates is the simplest, and the one used in the coding of the game. Yep. Orbiting describes a mouvement of the CoM, without precision, it is a translation (eg no rotation). Yes. Except for landed vessels, I'm pretty sure the game engine computes orientation and rotation, in an inertial frame of reference, which never coincides with the spherical coordinate system atached to the body your orbiting, the one that corresponds to what the Navball is showing you. For the very reason it never corresponds to an inertial frame. An accurate description of what the SAS system does. A stability assist is hard to get done right, and it was initially bugged. The goal of SAS prograde is to reach prograde as fast as possible, which has the side effect of locking the craft to prograde. To work as you expected it to work would require that the SAS system : Assumes that you want to minimize the amount of energy spent, which generally is not the case. The biggest use of SAS prograde is for a gravity turn, and you want your craft to point forward as soon as possible when you hit the SAS button, because taking a more economical path may result in rapid unpllaned dissassembly. Knows the period of the orbit, and knows it is a circular one. You can't assume that. SAS can't know this information. Ok, technically, it could "learn it" with minimal memory and computation required, and don't necessarilly need to know it (see below). Knows that is the most stable result. Studying the stability states of a system is an hard problem, and not one to be solved by a SAS. So in short, SAS gets its job done (helping you in flight) and stabilizing a space station at a non zero momentum is not a task it was designed for because the game assumes you will time warp anyway. Now if we look deeper, SAS should, in theory at least, be able to do what you'd want it to do (though I would not count on it in practice. Tools like SAS are typically PID controllers, (Position Integral Derivative), and it happens that a PID controller, or even a P controller could stabilze a station the way you'd want it (but the three point above holds if you hold prograde in weirder situations, like elliptical orbit, target relative velocity...). Problem is, such a controller would need parameters fine tuned to work for very slow orbital rotation, and probably would not work well in more common and critical situation with much shorter times and bigger rotations, like atmospheric flight. If your observations are right, which I believe they are, I suspect what's happening is the following : KSP prograde SAS is a PD controller, the Position coding the difference between the prograde and the forward vector. In a traditional PD, the Derivative should be the derivative of P, but for computation saving purposes, the Derivative is the angular momentum, which the game has anyways to compute the motion of your ship. That precisely causes the problem you're describing. But I can't be 100% sure it's not just a matter of parametrisation, SAS parameters being calibered for flight and lacking precision.

He says it's inefficient compared to dropping both the tank and the engine, not compared to not dropping anything. I expect drop tanks to be mostly used for launchers and landers. Anyway, they can help make the mission more fund efficient (albeit more massive or costy upfront), due to recovery of the most expensive parts. Airbus has (had) an interesting take on reusability with Adeline and it inlvolves a drop tank.

My first career ever looked like what someone described a earlier in this thread, unlocking the whole tech tree in less than an ingame year without ever leaving Kerbin SOI. I don't think it is necessarilly a bad thing. The game tends to work on the assumption most players will only land once on each body rather than scourge the Mun and Minmus out of their science points, or that they will want to have a lot of science to go interplanetary, namely Nerva, and possibly big command pods landing legs and ladders. And this assumption tend to be true from what I've witnessed other players doing. For a completionist like me, custom settings do wonder. I'm currently working with science at 10%, funds at 20 and penalities (building upgrades) at 200. I have to scourge every bodies of their last point of science, and I get to utilize fully each and every part or building upgrade feature as I unlock them. Many complaints about career can be solved by carefully choosing a custom difficulty setting that suits you. I also get to appreciate the variety of ealy game decision available. Rocket-Plane-probe, but also VAB or launchpad first? Or even science complex before upgrading them both. Do I postponed patched conics to get that upgraded launchpad one mission earlier? or manouever nodes? I see people complaining about landing legs and mobility echancer coming too late in the tree, but the truth is : you don't need them a beginner don't need to see them (he should focus on getting into orbit) you don't want them in a sub 30 part craft you can make them out of modular grider segments. So you can think of landing legs and mobility enhancer as better lighter version of what you are given from the get go. I think the Rocket-Plane-Probe part is quite well done in the current tech tree. Also, I like the interconnections. It may seems like the branches are less definite (compared to the OP's proposal), but it lets you jump from a branch to another more easily, and still allows you to beeline a particular branch. The rocket part is a bit expensive science point wise, with three different branches for big engines, small engines and fuel tanks, but the payoff (being able to go to other bodies with ease) is huge, from the very beginning of the branch. The plane part won't get you to space and won't get you many science points, but test contract will help compensate that in a unique way, and the funds gain from increased reusability will help getting building upgrades faster. The Juno and the wheel might come a bit earlier, but that's not a necessity, the rocket node you have to unlock for the Juno more than pays for itself and the Juno node, even in the hardest difficulty setting. The probe part starts a bit late in my opinion. For a lot people the lack of SAS on stayputnick is a big nono. Good for them, but it also enables very unique kinds of mission, like piloting a craft without SAS, or dropping it from a manned vessel in a Mun assist toward an exit of KSOI while the manned craft accomplishes orbit around the Mun. The problems I have are the following : You gain access to it too late. You only really benefit from probe core once you got tiny engine You gain access to okto only one tier later, in a tech which also contains the first solar panel, which might be considered staple. To solve 1 and 2, I think stayputnik should be on level 2. I think it's good to keep tiny engines in their own level 4 node, they are too good to be cheap and enable a big number of design, manned and unmanned. 3 will be exacerbated if you implement a life support mod requiring electricity like USI-LS, making solar panels more of a necessity, and stayputnik even more transtory. An idea to solve it could be introducing low tier high storage non rechargeable batteries. It would considerably lower the need for solar panels, which are an expensive tech early on, and would open ideas for missions running on a limited amount of energy supply, like many RL missions are. In a way, fuel cell is a form of non rechargeable battery, but it comes late, and is not convenient for data transfer, where you want huge amount of EC available immediately.

Done in KIS/KAS, which may be interesting inclusion to stock. But the truth is, for the example of application you cite, bringing a brand new satellite probably would be less of a hassle than setting up rendez vous with old ones, and might even be more efficient as well if said satellite is smaller than the manned craft doing the maintenance. Roles were a bit poor when they came out but they feel alright IMO. Pilots are great early on for SAS, and later on to pilot drones (unmanned craft with no conection to KSC ; you can even roleplay or use a mod to simulate communication delay, forcing you to have pilot on site to do any complex task). Engineer are the least useful early on, since your landing legs are not supposed to break and still work when they do (only the spring is locked), but they can repack chute. Later on, they are the most useful, running drills and ore refineries. Scientist are very useful to recycle experiences, maybe too useful, and they can be used in a lab later on. I would not be against some tweaking to the science system, most of all, I think scientist, given they are most likely geologist (keologist?) and a bit biologist, could be able to detect biomes. No. Routinely repairing stuff can be a chore for some, I would leave that for a mod (there's one if you're interested). The game could introduce finner degree of destruction than part exploding and joint breaking, but that would remain a very minor feature, since nobody would deliberately slam their vessel into their station (and if they do on accident, they would possibly make things worse by trying to perform an EVA, b etter to encourage newbees to reload here). You can do all what you describe in the archive. Archive does lack a way of visualizing science you don't have though, but in my opinion it's fair, since you don't have it. Having such a visual is not of the utmost importance for small ship since you should do all the science the ship can do as soon as you enter a new biome, but it could be an interesting feature for science labs. Also, any of the science mod that ease the tedium of science gathering could be implemented and attached to a skilled enough non piloting on board scientist. It no longer would be sandbox. In my first career game, I spent a lot of time doing the same atmoshperic contracts over and over, not because I needed them, not because I liked them, but because I was proposed them. I could have used my time differetly, and now I know better than to accept every contract thrown at me. Sandbox mode, more than every other mode, should be void of any reward system pushed to the player, so that the player gets to define his goals himself. Some player use their sandbox to build trains and never leave the ground, let alone the atmosphere. They would not be rewarded by any sane point system you could imagine for a game called KSP, yet I'm sure they feel some sort of accomplishement. If you're the kind of person who craves reward system, then sandbox is supposed to be just that, a place to test your craft. By the way, you can transfer crafts from one save to another if you're wondering. To emulate what you are describing, start a new career mode at lowest difficulty settings and enough starting funds and science to unlock everything, and rejoice each time you receive a message telling you broke a new milestone (land and distance record, then for most bodies flyby, orbit, spacewalk, docking, suborbital, landing, walking).

Welcome aboard! With a heat shield, you should not need to burn off your velocity. Dropping from such altitude, your landing site is chaotic (very sensitive to initial conditions). If you want to pinpoint land on an planet with an atmosphere requires you co circularize first (so one or two pass at 40-50km, then kick your periapsis back past 70 km). From there, it's a matter of trial and error to find the good trajectory to land where you want (that trajectory depends on the craft). Some control surface or lifting surface improves your precision a lot, but even the lifting body and the variation of drag depending on the orientation of a rocket can help, especially if acted upon early on (very small aerodynamic forces in high atmosphere, but there effect carry on and multiply over time). You also might be interested by the mod called "trajectories"

Jetpacks (barely) work on Duna. My Kerbals like ladders a lot. If you can go in and out of a plane without jumping on Kerbin, you should be able to do the same anywhere. Who cares? It's a single player game. Part clipping mainly allows more aestetic crafts but does have in game effect : it allows to make craft that are smaller (eg for career mode), more stable, and sometimes less draggy I think. In some settings, like some challenges or career mode, it can feel cheaty. If it makes things more interesting to not use clipping, don't use it, it's really up to you. Theorically yes, it is the exact same Dv cost, assuming a Hohman transfer. However, you can get some of that Dv for free, if you use aerobraking to get captured and lower your apoapsis. To know on which trip you spare the most, you have to factor the relative position of the planets (the high burn of a Hohman transfer is smaller than the low burn, so Duna aerobraking saves less than Kerbin) as well as their mass (Oberth effect reduces the capture burn Dv that a Hohman's transfer would predict, Kerbin's effect more so, but Kerbin LKO also is a much deeper gravity well than LDO). Overall, using aerobraking makes Duna to Kerbin 340m/s cheaper than Kerbin to Duna (I used a KSP map). You can assemble it from parts, using docking ports and claws and whatnot. drop the fairings, and ascent very gently (using airbreathing engines I guess) while in atmosphere. Put it between two rockets, rather than on top of one. Autostruts and gentle ascent helps. Use a mod to assemble it in situ. (KAC, interplaetary launchpad, and I think one of the USI ones, don't quote me on that, but you find them if you want them). Are you using a mod like real chute? Spread angles sounds like the angle the parachute have between them, rather than simply stacking on top of each other. Purely aestetic if I'm not mistaken. Don't know about CanopyMaxRotationRate Yes. What you heard is outdated. KSP aerodynamic is very basic, but does take into account front drag, skin drag and supersonic drag. Performance wise, it's easy to overlook them as they seem to just add cost and mass, wheras adding more fuel and booster can solve some aerodynamic problems. But there are situation where they do improve the performance of your craft, by a lot. Stability wise, there are a couple of situations where a craft is simply unflyable without nosecones or fairing. Keep them in mind before adding tons of struts, reactionwheels and gimballing engines. I don't know where you heard that, and if you doubt that, you probably already have a clue as to what they can be used for. They are best used for craft eexpected to do very long burns, possibly without the ability profit much from oberth effect. Is there any point to play sandbox mode? You can play your career game just like you play your sandbox mode and do things just because they are cool. At least that's what I do. Career mode is generous enough (even on custom hardest mode).

The key clues are the word "anomalies" and the fact that you have only one marker. I don't remember the contract wording, and it is possibly a bit poor, but the idea is that a anomaly has been detected, and they want you to check. They only know the approximate location of the anomaly and know they'll ask you to check several places, but can't tell how many and where until they got more informations, which requires you to go to the first waypoint (at which point they got enough information only to tell you to check the second, and so on). A rover or a rover-hopper should be able to deal with however many waypoints they find suitable to force you going through. You get a very small penality if you decline or cancel the contract, and a significant one if you let the deadline pass (which is usually 5 years later). There are nobody nothing to rescue or tour somewhere, so it's impossible to fail unless you want so (since you should cancel the contract before the deadline rather than letting it fail).

A direct ascent is always more Dv efficient than circularisation + transfer burn. This is because both trajectories have the same apoapsis (or ejection velocity, corresponding to your destination), but you make your burns closer to the planet in case of direct ascent (and have a lower periapsis, which only matters if the target trajectory is an ellipse, ie within Kerbin SOI). Circularisation however lets you plot the perfect launch windows (although your craft won't be able to perfectly fire it due to limited TWR), so it avoids potential losses from an imprecise direct ascent. Direct transfer to Jool is not as hard as it sounds though. You can have one or several probes in very low Kerbin Orbit and plot the transfer for them to have an approximate time as to when to launch your rocket and what velocity you should aim for. Caution, direct ascent is NOT vertical ascent. Vertical ascent is a particular case of direct ascent, and a dubious one. Using a typical rocket, with TWR < 2 for the most part, you have no choice but to take the same ascent profile as a regular rocket, possibly even flatter, doing a gravity turn, being at 5-30° by 35 km up, and instead of waiting for the apoapsis to circularize, continue accelerating until you're on the transfer trajectory, which is technically a Hohman transfer, but with periapsis lower than 70 km. That way can use the very same typical crafts you would use for a circularisation + hohman transfer, you just fly them differently. Due to gravity, it is always better to go as horizontal as possible, no matter your thrust to weight ratio. If you want to exit Kerbin SOI with some ejection speed, your direction does not matter. The Vis-viva_equation tells you the speed you need to have at Kerbin's surface, and adjusting launch time allows you to have any ejection angle using any launch angle. So only gravity losses matter. Using vertical ascent, you'll have gravity losses equal to Dv/TWR But using a constant height ascent, your gravity losses will be lesser than Dv(1-cos(1/TWR)) ~ Dv/2TWR^2 << Dv/TWR Lesser because you'll be helped by centrifugal forces as you go. And as a bonus, you'll accelerate a bit closer to the planet than with vertical ascent. Vertical ascent requires huge TWR in order to be viable, which means taking off from a small body where you happen to have high TWR already, or using a dedicated craft, with heavy, expensive engines. It is the easiest direct ascent to plot though and possibly easier than circularisation if you can't use manoeuver nodes or equivalent. Constant height ascent can be done even using a non overpowered craft and requires many times less overpowering than vertical ascent if you want to reduce the gravity losses to near zero. If the body you take off has an atmosphere, or if your target is in the SOI of the body you take off from, vertical ascent may or may not have a small additional edge to compensate. If the body has any rotational speed, it is a big pro for horizontale ascent, although I expect retrograde horizontal ascent to still beat vertical ascent for ascent burn of more than 30s on most bodies in terms of Dv efficiency. Finally, IRL, engines are significantly more powerfull than stock ones, compared to their mass and size, so using modded engines, including low tech realistic ones, it can be quite easy to push your TWR in the tens of G's where gravity losses no longer matter, without building an expensive pancake whose mass is mostly engines, so that's one more points in favor of the viability of vertical ascent (but such powerful engines don't necessarilly have the best Isp). I am not sure what to think about 45 ° direct ascent, it seems to me that it misses both the efficiency of a mostly horizontal direct ascent and the simplicity of a vertical ascent. Maybe it's as good as you get trying to do an horizontal ascent if your first stage is too powerfull, but then I think you would gain from toning the first stage down and adopting a flatter trajectory. TL;DR : Direct ascent is a bit more efficient than circularisation in theory, but harder to get right. With very few exceptions, horizontale (once atmosphere is cleraed) (direct) ascent is strictly more efficient than verticale (direct) ascent but harder to get right (and more efficient than any non horizontale ascent). Vertical ascent requires a dedicated crafts with high acceleration.

So I'm currently working on a stock magnetic rail using docking port for their magnets. I only started some test and probably won't have the patience to push the concept very far, but I thought it might be a good idea to share the extent of my knowledge to spark some ideas, and to debunk others (I had a lot of misconceptions which once debunked makes Maglevs look much more easily doable). The setup I tested for now is one docking port facing downward anchored to Kerbin (the "rail") and one facing up ward (the "train"), at some variable distance, with some variable ballast. The variable distance is measured in increment, a very rough mesurement which corresponds to moving once an object using the offset tool with the maj key pressed. I tried clamp-o-tron snr, clamp-o-tron and clamp-o-tron jr, in matching pairs. Vertical stability. There are stable region where the train can stably levitate. It goes against my prenotion that docking ports were simple magnets which get more and more attracted as they get closer (in that case, no stable levitation, if it goes a bit too low, it falls too high it rams into the rail and docks). The magnet force is really small, maybe null when the port are right next to each other, increases to a max value when the ports are 2 increments appart, and fades at 4-5 increments. It follows that there can be 1 stable equilibrium. Lateral stability. As expected, levitation is latterally stable. Magnet force. 4.4kN. Magnet force does not depend on the size of the port. Forget aboubt clamp-o-tron senior. 4.5 to 4.5 kN is the max I could get, but the stability region looks very small, 4kN should be safe. It means a clamp-o-Tron jr can pull 20 time it's weight, same force to mass ratio than the ass kicking 48-77s spark engine. I haven't tested the minimum force before it docks, but 2kN is also possible, although stability region looks smaller than the one of 3kN. I only found one place in the web where this idea is ever mentionned, but it is a very promising redit post showing a mostly working prototype. Finally, although mono rail should be possible, I would advise put two in a mickey hear configuration for increased stability (but needs testing). I can share upon request the craft file I used for my test, but that's not much really.

Infernal robotics have any kind of powered and unpowered liaisons, rotators, translators, pivots... That's most likely not the simplest (nor the most compact) solution to your problem, but that's the mod which will offer the greatest possible control over adjusting.

The main source of sustained wobbling (one initiated manually) is when your control center is far from your torque modules (and have SAS on) : If you control your ship from the tip of a long arm, it will detect small oscillation that only affect the tip of the arm, and will try to stabilize it by using torque on the whole vessel, giving it inertia. If the vessel is big enough, the effect of the correction will take time to be felt, which leads to systemetic overreaction. For moderately size craft, like yours seems to be, it often increase the period of oscillation, so it reduces the overcorrection, and "stabilize" in a gentle wobble. But for bigger ships with especially bad configurations, SAS and wobbling can reasonnate and be in opposition of phase, leading to an over increasing wobble and eventually the self dissassembly of the station. There might be other causes of minor wobbling, generally not as dramatic as the one explained above. Solution : Control the station from a part as close as possible to its center of mass. That part, whose orientation is used by the SAS, is less likely to oscilate randomly and thus reflects more accurately the rotation of the station as a whole. Move reaction wheels close to the center, and desactivate those that are far from the center. That way, your torque parts actually contribute to the rotation of the craft, rather than to its wobbling. Likely, you probably want to desactivate RCS thruster from a ship docking to your station. (Allocate a action group to toggle attitude control of your vessels). RCS thrusters are more efficient far from the center though, so next advice is especially important for arms reaching away from your station containing them. Use as few parts as possible for the skeleton of long structures. Long grider segment rather than regular ones, MK3 Bay for stations whose sole purposes is to be big... Use struts (auto struts). If all else fails, desactivate SAS, and use time warp to stabilize when needed. From the picture you gave, 1. and maybe should suffice to solve your issue.