Plusck

Eyeballing it? Basically what I said about that roughly eighth of a diameter of the body is the first thing. So in this pic, if you really can't wait for the body to revolve under you, and the space station you're aiming for is about to come up on you, you'll want roughly this spacing (actually, I think you'd probably want to launch a touch earlier... you'll probably average about 3/4 of the velocity of the space station as you ascend... so therefore 1/8th of a diameter —meaning 1/4 of a quarter orbit difference in distance travelled— is only just enough to catch it) and you'd want to start heading in the direction of the orange arrrow (basically 45°). However, remember that that 45° apparent angle is mapped onto a sphere. In reality, where you lift off it will be a bit more than 45° and it will fall as you climb. So I'd aim for about 30° compass heading on lift off and expect it to settle down to 45° by the time I'd got up to a couple of hundred m/s. If you switch to map view as soon as you've cleared terrain, you'll see AN/DN on your orbit as it starts lifting out of the ground. You just need to adjust your flightpath slightly so that AN/DN (in this case, DN) hits the target orbit where you expect your Ap to be. And you don't want to hit the other orbit more than a quarter of an orbit around. Or less, but you'll probably always end up doing that...

It's always difficult, because most of what you want as payload (satellite dishes, crewed parts) are bulky but light. However there is the inconvenience of having CoM "a bit low" like the satellite you showed (but once in space, there is no airflow and much less of a problem with being heavy bottomed)... And then there is the massive issue of having CoM so far down like in your original pic. To be honest, I don't even know how it's possible for CoM to be quite so far down on that first pic. I see you're using mods, but I'm not familiar with them (for example, what is that grey 2.5m cylinder at the bottom? With three orange tanks full of fuel, you should have a good deal more LF/Ox than that. Which suggests that at least one of the orange tanks (top one?) is empty or is in fact carrying something else. Given the Oxidizer figures, the top orange tank and Rockoma x200-32 have been emptied of all oxidizer and maybe even some LF. You can't hope to have a stable rocket if you make it extremely tall and then deliberately get rid of the mass at the top! edit: In fact, looking at the numbers again: - you are trying to fulfil a contract to get 4000 liquid fuel and 8 Kerbals in orbit. - to do this, you emptied all of the Ox from the top orange and top x200-32 tank - you also removed 1/10th of the LF from the top orange tank. So the flipping of the rocket is therefore guaranteed: the top half of the rocket is about 70% air! On the contrary, using LF tanks solves the problem: No fins, no reaction wheels. Bottom tank set to empty first. 4000 liquid fuel up top and the standard contract requirements. With 50% thrust off the lanchpad it has much the same TWR and the same dv as your craft, for 15k less funds and one less SRB. In stock aero, it"s perfectly flyable without SAS. Needs a bit of care at around 8000m altitude to keep it roughly prograde, but shortly after that it becomes aerodynamically stable (mostly empty SRBs giving drag, half-empty bottom tank causing CoM to shift further up) meaning you can just let go of the controls for a while. It becomes unstable again when the SRBs drop but only a touch, and the gimbal is enough to keep you roughly within the prograde circle. I don't expect FAR will make a huge difference to that.

The rule for "what apoapsis would be the most efficient for the plane change" is pretty simple: as high as possible! And the maths for plane changes on circular orbits is also (relatively) simple trigonometry. 90° plane change = sq.root(2) x orbital velocity (because it's a 1:1:root 2 right-angled triangle). 60° = 1x orbital velocity (because with a 60° angle, the vectors form an equilateral triangle). There's a good thread on plane change here: So basically, for a 60° plane change it'll be cheaper if you raise Ap to SOI edge. For a 30° plane change you stay where you are (it'll cost slightly more than half your orbital velocity since it's the base of an isosceles triangle therefore 2x sin(15)). As for launching into a different plane from the target orbit: first question is why? Second question is what's the angle difference? If you're launching from somewhere other than the equator that is less than 60° north or south, and want to reach an equatorial orbit, the best seems to be to launch due east, get Ap up to the equator at the target altitude, and circularise there. You'll therefore do the plane change a quarter orbit after your lift-off point. So the same goes for any orbit on a different plane: if for some reason you can't simply wait to launch into that plane, then launch as close as possible to it so that you reach Ap just as you cross the target plane a quarter orbit later. And if it's more than 60° difference, you definitely want to raise Ap well above the target altitude and just raise Pe to the target altitude while changing plane, then burn retrograde to circularise at Pe. Since you are definitely not wanting to get up to orbital velocity before the plane change, the maths is going to be a lot more complicated, but the principle is relatively simple if you compare to the most efficient way to land at that same point from your target orbit: just try to do the exact reverse manouvre. And finally, to rendezvous with a craft on another plane, that really depends on how much of an angle difference there is. When doing LKO rescue contracts, I've found that ideally, you want to take off when the target is about 300-350km away. That means the target is near the end of the sea crossing before the land mass where KSC is located. Or when looking at Kerbin, it's about an eighth of the span of the globe. And I've found that that sort of relative distance works well on all of the moons and planets. To meet a craft in orbit, you really have to rely on the map view once you're sure you've cleared the terrain. Adjust your ascent so that AN/DN is located where your path will cross your target's orbit. Use radial in/out to get the target intercept markers to line up. And then once you've lined up, the absolutely most efficient way to get into the exact same orbit as the target is to fire exactly along the target retrograde marker. No need for nodes or anything. By reducing relative velocity to zero exactly at the time you meet your target craft, you are making the most efficient burn possible by definition. edit: oh yeah, didn't really answer the question about predicting dv and time from launch. To be honest I don't know and I'd be interested to know if anyone has good rules of thumb. That will obviously change a lot depending on your TWR. In my experience, the place that I end up doing lots of refuelling, and therefore lots of ascents to orbit with fuel to join the orbiting station, is Moho. TWR on the way down to the surface is high, so I can consistently get from orbit to my desired spot on the surface for about 1050 m/s (approx 900 m/s actual dv cost, plus 150 m/s gravity losses and steering to land next to my miner). On the way back up, with much lower TWR, I seem to spend about 1200 m/s. So if I had a rule of thumb, it would be approximately 120% of orbital velocity without a major plane change. Time to rendezvous is approximately one quarter of the orbital period of whatever you're meeting. And I'd guesstimate that the cost of matching velocity with the target would be about 80% of whatever it would be if you were already in a circular orbit. So for the Mun, with a 30° plane change, I'd guess 120% x 600 m/s to orbit and rendezvous, plus 250 m/s plane change (80% x 0.52 x 600) at the rendezvous, giving a total of 870 m/s.

Yes, you're going way too fast. If you look at KER's Apopsis numbers at the top left, you have a negative number. That means you are on an escape path out of Kerbin's system. Also just looking at your path, that is way too straight. Again, the number you want at "Apoapsis" (sans capture by Minmus) is roughly 46,000km. That means that your vertical velocity relative to Kerbin is about zero when your ship encounters Minmus. The only speed change needed to capture is therefore the difference between your horizontal velocity relative to Kerbin (which will be very low) and Minmus's orbital velocity (which is apparently 274 m/s). Your ship's path should describe a graceful curve until it just clips Minmus's orbital path and exactly the time that Minmus comes to occupy that spot.

Heh, I actually think the reasons for my myopia on this are tied to when I really started with the "main game" (1.0.5 I think). You could do things indivdually to parts (like lower landing gear), but then 1.1 (I think) broke that and since then I've been fixated on the "placed in symmetry = all do the same thing". Still, to be perfectly honest, when I go beyond 2x symmetry it's because I'm creating an unholy monstrosity that by all rights shouldn't fly. Not even Krikkit One. More like Krikkit 0.9.1.v3. So I'm probably not looking for elegant solutions at that stage.

Yes, I didn't realise this either because I didn't even think it could work, so never tried it. That's because you cannot make individual changes to the settings of any item placed using symmetry. So once you've launched your craft, if you change fuel flow by adding +1 priority on one tank, it will do the same thing on all tanks linked via symmetry (so six of them with sixfold symmetry). I didn't realise that by splitting those tanks in the VAB, it automatically sets priority to the staging number. Sure, if you add +1 to one of those tanks it'll add +1 to all of them, but they'll keep their different stage-based multiples of 10 for fuel flow priority.

Ah well, looks like the only remaining bit of my answer is "elevons or controllable fins". I know elevons don't look right, but they are cheap and they work perfectly. One other thing though: I looked at your pic in orbit and I'm finding it hard to understand what I'm seeing. The payload and the upper stage appear to be connected, but they are connected by a very fine line. Could it be that your roll is actually a phantom movement caused by your controlling probe core moving around inside the fairing? Just a thought...

It sounds very much like OP is placing pairs of separatrons on the boosters, one on each side. Incidentally, if you try placing boosters with sixfold symmetry, will that not make it impossible to set fuel flow correctly with crossfeed enabled? Or require you to place each fuel duct singly? Personally, I always do it with twofold and alt-click to copy/paste each pair.

You don't have controllable fins and you don't seem to have any item with significant reaction wheels. The reaction wheels in the probe core are very weak. Therefore there is absolutely no way to control roll. The Swivel rocket gimbal cannot affect roll since it is in the centre of the craft. I'm not sure that autostrut is really going to help either. I've actually never used it, because I find the usual real struts are perfectly adequate and if things wobble, it's telling me that my structural engineering sucks. @Harry Rhodan is definitely right about the SRBs creating the roll. It does look like they are not actually centred on the decouplers, but even if they are they can shift and, if they both shift the same way radially, they'll make you roll. So in your place, I'd drop those fins and add the smallest elevons or a set of controllable fins. If you'd rather not do that, you need reaction wheels. That size SRB shouldn't normally need struts. At most, one at the bottom (it's always a better idea to put the decoupler nearer the top, so that the SRB is pushed out the way on separation and the airflow will make it peel away cleanly). Just zoom well in between the core and booster in the VAB to place the strut centrally (starting on the SRB with snap on). The only time more than one strut is needed is when your side boosters are really massive and/or made up of a number of fuel tanks.

The key figure you want is "46,000,000 m". Or close to that number. That is the altitude that your Ap should be at when you finish your 900+ m/s burn out from LKO. You may need a normal/antinormal burn halfway out to Minimus to actually capture. If your Ap is much higher than that, you will have to spend significantly more than the usual 200 m/s or so dv to capture. The easy way to do it: just like for the Mun, place a node at the point that Minmus just appears above the horizon in front of you. Drag the prograde vector until you get an Ap of 46,000km. Drop a second node halfway there and add/subtract normal until you get a hit. Right-click the Pe at Minmus and then gently drag and/or adjust the two nodes to get it down to 20km or so. That should give you approximately 200 m/s to capture.

Interesting discussion folks. Once you've got your first satellite up, you can eyeball the rest using manouvre nodes and target rendezvous markers, especially if you get your first satellite there quickly using a radial-out ejection. It'll cost dv to do that, but you should be able to get three out of the four satellites in place relatively quickly: - first one radial out and into the final orbit quite quickly; - second one heading purely prograde, probably not too long after the first satellite gets into its final orbit (six months?); - third one heading radially in, not too long after that. Whatever happens, though, there's not much you can do to get the fourth one into position quickly, unless you start by sending it way higher than Duna at the beginning of the process and bring it back down once the first satellite has started to pull ahead of it. Otherwise it's going to be a nearly 3-year wait.

Very kind of you However, I forgot to mention the other option to obtain vertical symmetry: use mirror symmetry. It's a bit finicky, but you need to use the R (switch between radial and mirror) and F (switch between parent part and craft) key bindings. Basically, you should start by building a single booster on one of the four cardinal points around the vessel. Then use R and F to place the separatrons with mirror symmetry on the booster itself. Then go back to radial, craft symmetry and grab the decoupler to place pairs of the booster assembly on the craft. If that doesn't work right, start by building your boosters as normal, and stick a separatron on it at the right place. Then make sure that your craft has an open node at the top. Remove and set aside the engine and any fuel tanks below the one which attaches to the decoupler. Then take off the remaining upper stump of booster and attach it to the top of your craft. Re-attach the separatron booster as a pair using radial symmetry (key R). Then once you're done, place it back on the radial decoupler and reattach the bottom section you set aside earlier. Finally, you can do much the same thing by building the booster separately and saving as subassembly or as a separate craft that you then "merge" in. Again, the part of the booster that attaches to the radial decoupler needs to be the "operative" part, i.e. root part of the saved vessel that you merge in, or part attached to the root part that you hive off to save as subassembly.

I found this site a great help in getting my head around the whole idea: http://www.planetary.org/blogs/guest-blogs/2013/20130926-gravity-assist.html Especially the various GIFs:

Objects snap to grid on all three axes if you try to offset them with snap on. Unfortunately, that will often cause a surface-mounted item to sink into the surface. Some items (the narrow-band scanner, the Gigantor solar array) are extremely annoying since they cannot be offset at all (they sink irrecuperably into the part, and refuse to be offset back to the surface), but most things can then be brought back to the right place with snap off in a consistent manner just by eyeballing it. If I need to use a Separatron, I usually just use one on top of the nosecone of the booster or tank in question, pointing slightly up and towards the core of the craft. I've never had a problem with it burning anything vital in the extremely brief time its jet touches the core of the craft. And vertical alignment is not an issue. For asparagus or onion designs, I try to avoid use of Separatrons altogether: (a) radial decouplers well above the CoM of the booster, and strut(s) holding the bottom end tight, and/or (b) fin at the bottom of the booster, assisting early stability and adding a touch of drag on the outside that makes the booster peel away gently. Finally, you can build one booster with vertical alignment perfected (maybe aligned to a feature on the surface texture), then alt-click it to copy it to your other boosters. edit: oh snap. OK Slashy has said much the same thing in a fraction of the word-count

Actually, I just rechecked and my first test wasn't loaded enough. A surface-attached i-beam is weaker than node attachment, once you start putting some weight on it: I-beam using the node attachment on the left. The small tank is occupying the node on the right. In another test with the orange tanks mounted higher, the surface-attached beam wasn't able to withstand the twist and the tank ended up falling off.

Oh, cool. I didn't think to change the stats on the wheels, which is a bit stupid since I've had jittery landers when I've gone overboard reinforcing legs. As you can see from my tests, ruggedized wheels are fine on Kerbin supporting several tons each, so you definitely don't need to reinforce their stats for what you have them carrying on a moon. As for the ore tanks: I don't quite follow your explanation there, and I suspect that this is a source of weakness. It sounds like you:: attached the mk2 cockpit to the node, and then the crew cabin to the exposed node offset the cabin upwards to be flush with the 2.5m parts attached an I-beam to the remaining exposed face of the 2.5m part attached the next 2.5m part to the exposed node of the i-beam. That means that the i-beam has one of its nodes surface-attached (at the front) and the other node is node-attached. I don't know if that is any weaker than node-attaching both ends (I did a quick test and could see no difference in flex when heavily loaded between the two options... see pic below). However it is certainly not good for KSP's aero model since the rear of the crew cabin is fully exposed to the airflow, as is the whole of the front of the next 2.5m part. Still, it is certainly better than using ore tanks to hold the structure together. Clipping ore tanks shouldn't cause a problem. However, instead of doing that, I would suggest attaching the 2.5m and Mk 2 parts all in a line, then offsetting the cockpit up to be flush and the following 2.5m part down to be flush, then reinforcing with a strut or two between the facing 2.5m parts. That way you don't have the crew cabin floating around while clipped in to the following 2.5m part. You can surface attach the ore tanks underneath the mk2 parts and nothing should budge.

Well, I tried a few variations with large numbers of ruggedized wheels (more than your example), and I still haven't managed to blow up my ship. I used the SPH and I mostly didn't use autostrut, but I tried autostrut on a number of parts and it didn't make any difference. However, there are a few things that I noticed as I was trying to copy some of the features of your build: radial attachment: the wheels bug out in the editor when taking a perfectly acceptable bogey built via node attachment and then trying to attach it to a radially attached part. Specifically, taking a node-attached tank + wheels and moving it to a radially-attached part made the wheels switch to radial symmetry (but not the rest of the tank or other parts attached to it. Pic below. This may indicate a source of problems... but still once I finally got the wheels right it didn't explode or anything. crew cabins: crew cabins can't be attached radially. Therefore in that last pic (not the one that doesn't work, oddly...) the front sets of wheels must be attached through the nosecone. This has to be weak. But the game didn't object to that one, so that's odd. ore tanks: you should never use ore tanks to support any significant weight. Their structure is extremely weak, whether attached radially or by nodes, far weaker than fuel tanks. It looks like the backbone of your craft is made up of a series of 1.25m ore tanks. This is asking for trouble. or instead, did you node-attach the cockpit and 4-man crew cabin, then offset them? This would also be weak, but I tried doing just that and had no serious issues either. [edit: rereading your last post, no, you didn't do this. But you are using ore tanks as backbone, which is not going to help] clipping: I didnt try to reproduce it but you have a lot of parts clipped in. However, I can't see anything that would really cause a problem with clipping. balance: I can't see what is on the other side from the drills, but it certainly can't be balanced. So, sorry I can't really help. Could it simply be part count that is causing the problem? Edit 2: Hang on a second... Judging by the way your craft fell apart on the launchpad, you have attached one modular girder to the surface of the fuel tank, then put wheels on it, then attached a series of them by node attachment the length of each section. If you do this, you really have to make the middle set of wheels the first ones that you surface attach, otherwise you're creating a long lever arm of girders to support the weight of the craft. Remember that when you surface attach a line of objects, only the first part will actually be attached. The rest of the parts are clipped but there is no structural strength there. Also, to get the spacing of the wheels, your surface attachments have to be only just touching (or not really touching) the 2.5m parts which are a science lab and a hitchhiker can. I just tried this out. Attaching radially and offset slightly from the science lab was ok. Not ok was when I tried to do the same with the hitchhiker can. It didn't explode, but it was jumpy and not happy. That may well be what is causing your craft to fall apart.

Finally! I'd even go further and say that you should ONLY use pitch trim (well, virtually all of the time anyway) and no SAS to fly planes in KSP. Still, one does have to bear in mind that KSP was never intended to be a flight simulator. Realistic is attaching one set of flight control surfaces /engines to one set of controls. Rudder is not so useful in KSP since its main uses in the real world (cross-winds, unequal buffeting of prop wash, preventing side slip when turning) either don't apply or are not a significant problem in KSP. Planes are that sensitive in the real world, too. Get your CoM wrong in a small plane (heavy passengers, too much fuel) and you can very easily crash and die. Happens all the time. The advantage of the real world is that you have force feedback stopping you from slamming the controls all over the place (though pilots have memorably managed to do just that with the rudder and broke the tail off a passenger jet a few years ago, killing everyone in the process).

The easy way to do this is to switch ships using the hotkey ("[" or "]" I think), right click the docking port in question to bring the window up, then switch ships again. The window from the docking port should be still up on screen allowing you to select the docking port.

I intended to cover that when I said that at 30km "you'll take much longer to hit the ground than if you had simply stopped and dropped from wherever your Ap is". Coming in fast for a 30km Pe, when you're actually at 30km then Pe is already far under the surface, and Ap might well be somewhere around the 70km mark. Now, if you'd actually stopped and dropped from 70km, Ap would now be much lower (due to drag slowing your descent) but you'd be heading far faster towards the ground because your retrograde drag would not not be trumping gravity like it does when you are going fast.

Have you put your probe core in hibernation?

The short answer is: Mythbusters got it wrong in that "bullet drop" experiment. They failed at physics and their experiment wasn't sensitive enough (or wasn't set up correctly) to show how. Basically, drag is proportional to the square of velocity. If you drop something vertically, gravity accelerates it and drag limits the acceleration until it reaches terminal velocity. If you fire something very fast (far above terminal velocity) in a straight line, gravity will likewise try to accelerate it downwards. However, from one instant to the next, that vertical acceleration is being dampened by the drag force squared which includes that vertical component. Therefore, your fast-moving projectile cannot accelerate downwards as much as a slow-moving one. Sounds counter-intuitive, but it's the reason why a fast re-entry to a 30km Pe gives you plenty of time to slow down to parachute speeds. By the time you've reached 30km, Pe is well under the surface of Kerbin but you're still going far faster than terminal velocity, so you'll take much longer to hit the ground than if you had simply stopped and dropped from wherever your Ap is. Still not convinced? Consider two ships. One dropping vertically at terminal velocity (which we'll call 300m/s), and the other (for the sake of a 3-4-5 triangle) with an added horizontal component of 400 m/s giving 500 m/s total. For the ship falling vertically, drag exactly equals gravity (by definition since it's terminal velocity). Drag force is (some constant x) * v2 and therefore at this precise instant it is 90000x and is equal to the force needed to accelerate our craft upwards by 10 m/s2, counteracting gravity. However, if we compare to our ship which also has horizontal velocity, drag force is 250000x. Therefore, since acceleration is directly proportional to force (divided by mass, which is constant here), our acceleration is 25/9 * 10 = 27.77 m/s directly retrograde. Since this is a 3-4-5 triangle, the upwards acceleration is therefore 27.77/5*3 = 16.66 m/s. At these speeds, we can approximate and say that one second later, our vertically-dropping ship will fall by 300m. The angled one will travel a total of 486m (500+1/2at2 = 500-14m) but will only drop by (300+1/2(10-16.7)) 296.7 m... Of course, when the vertical component of velocity is much lower and the thing you are firing has low drag (like a bullet), the effect is less significant. Easy to miss over a distance of 100m or so. Not so easy to miss when you're dropping 70km down from orbit.

Yes, thinking about it a bit more, it would really only be useful for quick reference if you changed scale completely. As it is, the level 1 DSN is 2G, so the first column would be identical anyway. You can use the second column to approximate a 100G relay just by seeing where your "x2" marks fall (then adding a touch.... ok so this is starting to sound increasingly less useful already...). So the only "quick reference" thing that is missing is the range of a 15G relay, and I don't suppose it's a good use of your time to add a whole new section and clutter just for that.

This is great. Thanks. Now that you've done all the hard work... could you do a second one with three more columns to the right giving the same results for the 2G, 15G and 100G relays? Pretty please? This would not only be immensely useful for masochists playing without the DSN ground stations, but also for normal people placing relays around planets, just to get the numbers.

I find it odd that a few people have mentioned problems stability or slowing on re-entry with mk1 + crew cabin + heat shield. Are you using FAR? I've never had a problem with stability after getting the first "retrograde hold" capable probe core. And I've never had problems with slowing either - a 30-32 km Pe for re-entry works just fine each time. I set my chutes to open at 0.23-0.25 pressure, which means between 8000 and 9000 metres, and the combo never has a problem. I generally reduce ablator to about 40-80 units, btw, if that changes anything (unless going further than Eve/Duna). The only time I've had a problem with slowing has been on suborbital hops, or coming in from LKO when impatient and reducing Pe to well under Kerbin's surface.