Plusck

Maximum possible mass ratio of stock LFO parts is 9:1 with zero acceleration. Add a Terrier, probe core, docking port and solar panels to an orange tank and this drops to about 7.4:1, meaning you should be able to get about 7000 m/s out of it (but weak acceleration), with about the minimum sort of acceleration that you need to drop from Minmus to LKO and back again with reasonable cosine losses. Deduct 1000 m/s for the transfer from Minmus, and you lose 10 tons of LFO. To get back up to Minmus, you need to keep 2 tons of LFO onboard. So each orange tank coming from Minmus will be able to disgorge 20 tons of LFO, or 62.5% of an orange tank, or 1800 LF and 2200 Ox. What you definitely don't want to do is have anything else on your transport tankers (like mining gear). If you make them much bigger and use a Poodle instead, you'll get a slightly better percentage profit on each run. At the end of the day, the question is: can you be bothered spending all the time and effort doing this? Sending huge fuel-laden rockets up from Kerbin will cost funds but will cost a fraction of the time and effort. Extra tip: rather than either of those options, take a contract for bringing a class D asteroid into orbit around Kerbin, and bring that down to a reasonable level to mine and fill your Kerbin station. Class E would be better but they are a pain to move. Without a contract it will cost you funds to do it, but you might find a good candidate coming in when no contracts are up, and it's always rewarding (I find)...

There is no direct ratio possible, firstly because the cost of getting from the surface to orbit will vary a lot depending on the radius of your planet or moon and your intended orbit. Compare Moho and Vall: Moho has higher gravity (2.7 compared to 2.3 m/s2 at the surface) but Moho is significantly smaller. Therefore it takes much the same dv to get to low orbit (860 m/s to 15km for Vall, 870 m/s to 20km for Moho according to the delta-v map). Despite its higher gravity, therefore, Moho is cheaper to refuel from. The second factor is your TWR when full of fuel. You want high TWR to avoid gavity losses, but you need to maximise their ISP and minimise their weight. Terriers trump Aerospikes on both counts, but only if the local gravity is low enough not to rack up gravity losses. The third reason no direct ratio is possible is because the rocket equation is logarithmic with respect to the mass fraction. For example, a single orange tank powered by twin Aerospikes and loaded with landing gear + wheels + solar panels + bits and bobs (say 8 tonnes dry mass, 40 tonnes wet mass) will get a dv of about 5350 m/s. If you use that as fuel lifter on Moho, spending about 1000m/s going up to orbit then 1000 m/s going back down again afterwards, you will use 11 tonnes LF+Ox getting to orbit, and need to keep 3 tonnes on board to go back down. That difference of 3300 m/s - what you can store in the fuel depot - is actually only 56% of the total fuel load, 18 tonnes. However, add a tonne of dead weight to your lifter and you only lose a bit more than half a tonne of fuel, because most of the fuel is spent when the lifter is nearly all fuel. When mass fraction is high, weight savings give diminishing returns... So basically you're left with: doing the orbital equations (radius, gravity goes in, required dv to get to orbit comes out) then converting that to real dv to orbit depending on TWR (basically a function of time to accelerate to orbital speed multiplied by local acceleration due to gravity) and plugging that into the rocket equation (mass fraction and ISP in, percentage fuel available out)... OR.... a rule of thumb: you need to spend nearly 50% of your fuel to lift fuel from Moho or Vall. Virtually none for Gilly. Virtually all from Eve. And the rest in between.

Well, if they have a load of spare dv, and you plan to spread the smaller relays through the system, then the logical answer is opposing eccentric, inclined orbits (sort of Molniya-like) around Jool. It doesn't have to be a Molniya orbit since you don't care about what you see on the surface of Jool. You would probably be best making them much more eccentric so they spend even less time actually whipping around Jool Pe. And you don't need them going so high above the poles either: you just need them angling in sharply enough so that they never run the risk of being snagged by Laythe. Pe would be much closer in than Laythe, Ap somewhere above Tylo I guess and well above/below the system's orbital plane. Something like this: The rationale? the 100G relay can see a single Communotron 16 from the distance from Jool to beyond Pol's orbit (about 220 Mm). Tylo's orbit is about 70Mm SMA. Bop 130-160 Mm. Therefore each one of the two relays, when near Ap, can see a single communotron anywhere in the system except for the furthest third of Pol's orbit; the only real concern for eclipses is Jool itself. With two relays you can't entirely avoid having them both eclipsed at some point in time, but it will be rare and very short-lived; with the exception of Pol, you'll have direct coverage of all of the moons' north and south poles the vast majority of the time; the inner moons will be covered on both sides the majority of the time; looking from above, their eccentricity should be at right-angles to Bop's eccentricity, so that Bop doesn't lose coverage at Ap. This just leaves the outward-facing sides of Tylo, Bop and Pol without direct coverage. There's not a lot you can do about that, but that's where you just need to use the smaller relays in orbit around the moons you're interested in. Since Pol is the most useful place to have a mining and refuelling base (IMO), I'd repeat the same opposing-eccentric-incliined orbit thing with a duo of small relays there. But that's just me. Maybe there are smarter solutions out there...

Neat. I know that doing an Apollo-style lander (leaving all the heavy bits you no longer need behind) is a smart choice, but only ever acted on it when it becomes a necessity to avoid spiralling costs, such as for manned base contracts (on Duna, Laythe and Tylo in particular) or for Eve because there is little choice. So I've simply never really considered the possiblity for my early Mun landings.

Just FYI: if you add a junior docking port, it should sort-of look like a smiley face when it's the right way round. With the standard docking port, the black rectangle is "up". All of the probe cores have their model number stamped on the "back/top of the head" location. So if you imagine that your rover or ship is Superman, you want eyes forward (the top of the probe core when you place it in the VAB, or the side facing the door in the SPH) and the "back/top of the head" (where the part number is stamped) facing the sky. And yes, I do sometimes use the Superman mental picture to sort out what is facing where, especially when landing on airless bodies (he usually comes in feet first, belly to the sky, and rotates forward as he lands).

I try for minimal numbers of relays, since each added craft (especially relays) seems to slow my game a bit more. So I just have two of the largest relays in the Jool system. One in a nearly-polar orbit around Jool between Laythe and Vall. The other in a polar orbit around Poll. And my mothership carries a 2g relay + scanner probe around with it. I didn't give my relays a ton of fuel, so the choice of orbit was restricted by what was easily feasible. Yes, this means that there is a good chance that one side of each moon is eclipsed or facing the wrong way for coverage at any given time, but never for too long and that dockable mobile 2G relay can park in a polar-cum-molniya orbit wherever operations are, for guaranteed sunny-side connection.

That lander looks like it is using a Reliant. KER tells you it has a minimum TWR of 1.5 on Kerbin, meaning a TWR of about 10 on the Mun. You definitely don't need so much power. A single Terrier instead of the Reliant, half the fuel, landing legs without girders (the micro landing legs are just the right size to hold a Terrier above the ground)... all of those things will get you the same dv (which is fine for landing once and returning to Kerbin afterwards). Also, when you're getting the science tree unlocked, you don't necessarily need to take all of the science experiments with you every time. I often leave the materials bay behind on early missions. Sure, it's a good source of science but sometimes its size makes it more trouble than it's worth. Finally, I haven't tried using FAR, but in stock you definitely don't need drogue chutes if the only thing re-entering is a command pod. The single top-mounted mk16 chute is more than enough. And I suspect the chutes are a big reason why your lander is so unbalanced and therefore needing reaction wheels. Balance the craft so that KER's Torque reading is 0.00, and you will have no need for added reaction wheels for that size of craft.

That or a pilot who has at least orbited Kerbin once already. Really there is no shame in using prograde hold for the ascent to orbit, and retrograde hold (on surface mode) for re-entry. And the link for my changes to your ship: https://www.dropbox.com/s/9lwpnw56mat0lv2/test_drag_monster.zip?dl=0

No, it doesn't. I've done this a lot and I tested it just now (results in the album I linked to). All you need is retrograde hold and a balanced craft, and a Pe at the right height for wherever you are coming from (generally about 32 km always works). I'll put up the craft file for the one in that album later. If you look again at your pic of your craft with the KER details visible, "TORQUE" is listed as being 0.67 for your final stage. That means it's unbalanced. It should be 0.00. That could well be what is ruining your re-entry stability.

@Spricigo is right, even though he may have come across as a bit abrupt. With 2000 m/s still left on your upper stage in LKO, and 2400 m/s in your lander, your ship is able to land and return from the Mun, Minmus, Ike, Gilly. Going to Dres and landing would be challenging. Going to the Jool system would be doable, but you'd be limited to visiting Bop or Poll. So for a Mun or Minmus mission, there is definitely a lot you could pare down. Still, one thing I don't understand is why you're having trouble with re-entry with the mk1 pod on top. I assume you have the HECS probe core availabe, so use it! If you come in from the Mun or Minmus with approximately 30-32km Pe, and have "retrograde hold" set (on surface mode), you should have absolutely no problems: If you revisit that album: https://imgur.com/a/4Zgp1 I did a redesign, cutting out the upper stage altogether, putting a Poodle on the lander and putting the Mk1 command pod on top. It still has enough dv to go to the Mun and back, plus it has no aerodynamic issues, plus it costs about 5k funds less. But still, there is more you could change. Those SRBs are too big and expensive for what they do. Smaller SRBs, with fuel on them to feed the main stack, and less fuel on the main stack, will all cost you less and give you more dv. If you activate the advanced tweakables you can micromanage fuel use across decouplers and make sure you rocket is never carrying too much fuel or empty fuel tanks for no reason.

I know my post was very much made in jest, but it was intended to be serious too. My gravity turn in that album was intended to show how it can work fine - even with your original rocket format - as long as you take it easy, turn immediately off the launchpad and follow prograde without trying to turn too much in those first seconds. I got to orbit first try with only one hairy moment when it looked like it might flip, but didn't. It wasn't perfect (still 1200 m/s to add at Ap) but it was certainly better than flying straight up to 15km. However, if you add just a couple of those short 1.25-2.5 adapters, it makes a huge difference to the drag. I added three (one for each jump from one form to the next) but I think it would have been fine not using the second one (under the lander's fuel tank). See here: No need for advanced nose cones really. I don't think they help much in this case and they are expensive and heavy. Instead of those hydraulic manifold thingies, I used the smallest radial connectors up top and a strut at the bottom of the boosters. And I added elevons but really I don't think it was necessary and that added another couple of thousand funds. Total: 34k And the whole process of getting to orbit is pictured here: https://imgur.com/a/4Zgp1 That leaves over 2k dv still in the upper stage. Steady as a rock even at 500m/s at 10 km altitude.

No reason to regret. It prompted me to see how possible it is to do this in KSP. I didn't get very far. Jet engine gimbal is not great. No control surfaces give a broad enough actuator range to do anything "supermanouverable". Still, I did end up making myself a whiplash-powered highly manouverable plan that can get to over 55km altitude on a third of a tank of fuel, and constantly maintain about 30° off prograde in flight with reaction wheels off. Not "super" but not too far off

lol, yes. I built and tried the ship. Gentle gravity turn (not enough to be really efficient) worked fine until about 500m/s but gimbal was enough to recover. Still left me with 1200m/s to burn at Ap though.... So I tried adding more nosecones.... That didn't really work out: So back to the drawing board... and this one is great. Really stable with the fuel up top. Just remember to land on a flat surface : https://imgur.com/a/kXE8C

[Edit: the first part of this answer is incorrect, since it refers to high manouverability and not supermanouverability...] Make your plane very light, make the control surfaces large and as far from CoM as possible, and avoid any kind of fixed fin. For example: [continuing the edit:] Supermanouverability is basically going to the extreme of making an aircraft very nearly impossible to control. So that means making CoM and CoL coincide almost exactly or even having CoM slightly behind, using canards at the front, and using a gimballing engine. The problem in KSP is the impossibility of having engine gimbal and control surfaces do opposite things. You might want to try making SAS-only control reaction wheels and then fly manually while telling SAS to do the opposite (like, radial out on SAS while pushing the nose towards the horizon. No idea how well that will work. [edit 2:] Actually you can have control surfaces do the opposite to what you are telling the plane to do, in the VAB/SPH. You can also (IIRC) use action groups to force this to happen. You will have a terrible time trying to fly your beast, and you can't use SAS since it will just lose control instantly, but with careful use of trim (alt+WASDQE) you might be able to pull off some of those Su-35 tricks. A simpler option might be to add a second set of control surfaces that don't control pitch/roll/yaw but which are tied to an action group to "deploy". Then you can use action groups to make the control surfaces and engines do opposite things...

Navigating and driving a rover is hard (and driving sometimes impossible, depending on how the game interprets wheel movements) if you don't have a forward-facing control point. Simplest solution is to add a junior docking port. The location of a site with a waypoint is actually very slightly under the point at the bottom of the indicator. With a forward-facing control point, the waypoint should be clearly marked on the horizon on the navball when navigation is activated. When you are at the site, the waypoint should be at the navball zenith (or nadir). I reckon you need to sort this in two stages. First: does navigation ever work (icon on navball, able to aim for and reach a waypoint) and second: what is the difference when you try for this contract. To save yourself from having to send up a new rover (since clearly you can drive this one around), try just creating a waypoint near that "parking place" (ideally in the direction your lander pod is facing) using commnet and see if you can get it to show on your navball.

Physics classes often use water waves to explain wave behaviour for sound and light. This can do terrible damage if your physics teacher doesn't make it abundantly clear that: this is to illustrate the concept of wave motion and the sorts of effects it has (reflection, refraction, interference etc.) the wave that you see is not an accurate representation of what is actually causing the wave. Rather, the water wave - that sinusoidal wave shape - is a great visual indicator of the phase of each part of the wave over time: the wave function of light indicates its vibrating electromagnetic field. The crest of the wave is peak field strength in one direction, the trough is peak field strength in the other. (edit: or maybe minimum field strength... yes, probably better that way for most intents and purposes) the wave function of sound indicates how compressed the air is. So the "crest" would be maximum compression, and the trough would be maximum dilation. A more accurate representation of sound would be: .. . . . . . .. . . . . but it is a pain to draw... the wave function of water waves indicates where in the circular motion of water each individual molecule is at. Water doesn't compress well, so it tries to get out of the way of whatever is pushing behind it. The easiest place to get out of the way is into the air, so the pressure is eased in that direction. The crest of the wave is the point that all of the water in the column below has moved up out of the way, and is exerting peak pressure downwards due to the weight of that column. the wave function of AC electricity is very similar to sound, if you replace "compression" with "electric pressure" a.k.a. "voltage". The big difference with water waves compared to every other wave is we can see it at each part of the cycle at once. That leads to the misconception that waves are actually sinusoidal in shape... but they aren't.

A screenshot just at the time you're talking about would help a lot to work out what's happening. The normal, relatively efficient and easy way to land on the Mun is to burn retrograde in low orbit until the path hits the surface about a quarter of an orbit later. To make sure the next bit gives the right time, burn at full thrust only. You then place a node on the surface and drag it retrograde until the orbital path starts going backwards. That should give you slightly less than 600 m/s to burn, and will tell you at what time you will hit the surface and how much time you need to come to a stop... As you approach the surface, make sure the navball is set to "surface". When you are about 2/3 of the time away from the node, burn retrograde at full thrust (ignore the maneuvre target). You should end up going very slowly a few hundred metres above the surface. Cut the engines, make sure "retrograde hold" is still on, then gently power up the engines so that you fall increasingly slowly as you approach the surface. Cut the engines the instant you touch the ground. The main problem is that if you burn too hard and start going back up, the "retrograde hold" will make your ship flip around and face the wrong way. The game protects against this by deactivating retrograde hold when you reach less than 1 m/s. However, if you never actually come to a stop, you will end up spinning around as you describe.

As GoSlashy says, there are a lot of factors to consider. All things considered, I'd expect most players will find the Poodle to be the "best" engine... if the mass and form of the craft allow it to be used. Or maybe the Rhino for bigger ships, it really is a beauty. Or maybe the Terrier because it is just so damned useful. Or maybe the Nerv. There is no substitute if you need to propel Kerbal-sized objects to extreme ranges, like a 180° inclined orbit somewhere near Moho. Only the LV-N can give your command pod the requisite 15km/s dv with acceptable burn times and launchable masses. Personally, I love the Aerospike. It's a shame that it has no gimbal, meaning that it really needs a perfectly balanced craft, but that's part of the joy of designing the ship it will power. But if you're trying to return from the surface of Eve you need to mix Aerospikes with Vectors, there is no other reasonable option. I really never touch the Vector for anything else. And when it comes to launching craft from Kerbin, I have a very clear preference for the Skipper. It's so much cheaper than the alternatives for that size of vessel, and I know it loses some of its power and ISP at low altitudes but it very quickly recovers and it is far, far cheaper than the far heavier alternatives (i.e. Mainsail... never liked that one at all)...

This is good advice if you want ideas about how to invent stuff. It is terrible advice if you want to do things well with the current version of KSP. A lot of the tricks don't work any more and won't help. Basic advice like "how to get to orbit" is just plain wrong. There is (in my opinion) only one thing that you need to do to solve all your problems: go to Minmus! Science from Minmus is worth much more than anything from Kerbin and more than from the Mun. Landing on Minmus is easy if you aim for the flats (0 altitude!). Getting to Minmus is not too hard: start burning from a circular orbit when Minmus is just about to appear behind Kerbin. Raise your orbit to about 46m metres, then make a course correction about halfway out. Once you've got a ship that can get to Minmus (really no harder than the Mun), can reliably get to orbit and can reliably hit Minmus with a burn from orbit (a bit harder), and can EVA on the surface, your science will skyrocket, your Kerbals will easily gain two stars and you will be ready for interplanetary trips to (at the very least) Duna and Eve.

I've tried a few strategies. My overall take on it is: it's broken... "Leadership initiative" sounds good and should be good for early-to-mid career if you know what you're doing (i.e. can launch cheaply and successfully)... but it doesn't pay out much at all and can end up costing more than it's worth. I've ended up getting negative rep on completing a significant contract with it activated in KSP 1.2 (return from Moho), and I don't trust it to be fixed in the latest version. On a new career run-through I tried to combine strategies to maximise science and rep... but I couldn't even put two 40% strategies together because it would "exceed 100%"? Wat? The percentage calculations are therefore broken if 2x 40% magically exceeds 100%... (this is with medium difficulty, so maybe the "medium" multiplier changed the result, but that still means the calculations are broken). So my final take from it is: yes, once you've completed the tech tree, you might as well convert all science to rep and funds. Not that you need much extra funds by then but it's nice to feel Musk-ish. I've tried to make it work for me, but it hasn't been really useful yet. The idea is good, but it still needs work to give it a purpose, especially in early career when you really want a fund or science boost (but can't because it costs too much to implement).

Thanks for picking up on that. My phrasing sometimes could do with being clearer, since I did say the only mod I have is KER and I used the stock cheat to set the orbit, but it got a bit lost in the other things I was saying So to be clear: I don't have HyperEdit installed and haven't for the last couple of versions of KSP. Last install was fresh 1.3.1 + latest KER + custom flag (I like flying the Saltire).

ok, well, no more success in getting the bug to work there. I meant, rather, a quicksave with your ship in position in Munar orbit, in a situation where, if you stage immediately, the bug will appear. It is very odd that you're getting this on a clean, clean install. I've only used HyperEdit to place ships on the surface a couple of times. I've often used it to put ships into different orbits, but now stock cheats let you do exactly the same thing I haven't felt the need to download it. The only mod I have installed is KER. Sorry if I can't be much help here. Happy to test anything you want to throw out there, but so far all I can do is give hints about what it isn't. edit: For examples, things it isn't: MacOS X 10.11 (El Capitan), Mac Pro with Radeon 5770 graphics card, running stock 1.3.1 + KER. That old bug report talking about graphics card is interesting. Also what is interesting is that the first report in that crash pic is the 7200 fuel tank (the white one) crashing into the 2.5=>3.75m adapter (near the top of the stack). In other words, the "debris" assembly is superimposed on the remainder of the ship before the game realises what is happening. Ejected fuel tank hits adapter, ejected separatron his upper stage separatron, ejected engine hits upper stage engine, adapter hits solar panels...

I tried your ship. OSX 1.3.1. Used stock cheats to "hyperedit" to a 100k then 20k Munar orbit in sandbox (medium). Tried going orbital, suborbital, escape orbital, prograde and retrograde... no dice. The ship worked just like it looked like it should... Maybe a quicksave of your ship just prior to a successful reproduction on your end... mods permitting. Though the failure to reproduce in stock tends to suggest that some mod somewhere is causing this.

You're right. There wasn't really anything to disagree with other than the tea-quality-value principle of the thing And yes, of course lighter, cheaper and more powerful solutions can be used to achieve the same purpose. At the end of the day, the only "real" relative advantage that the mk1-2 has going for it is partcount.

Can't agree with you on that. The one thing that you can say without a doubt about the Mk1-2 is that it is over-engineered. A design committee clearly got involved in the process: - for the pilots, it works perfectly well both as upwards-facing rocket pod and forward facing flight pod; - the most indestructible crewed pod available; - would have been more comfortable as a two-pilot pod, but since there's space for a third man, why not? As long as he doesn't mind the view and as long as the other two guys don't eat beans for lunch; - decent amount of torque, enough to avoid the need for added wheels for any circa 3k-dv final stage. And this is where the tea comes in: you can design new and funky builds to do the job better in any given situation, probably, but there is always going to be that nagging question of "is it going to survive first try?". And "is the part count going to hurt?". Whereas with the Mk1-2, you just put the kettle on and send someone off to the warehouse with a (reinforced) forklift to get one off the shelf. One part, multiple functions, plus a tasty kickback for the foreman (which means tastier tea, of course). And when your Kerbals are off on a 2-year trip to Jool, do you really want to squish them into a can barely big enough to hold their helmets? Of course not. And you can be sure that the Mk1-2 pod has the full tea-making kit installed as standard. And the third guy there to go make it (if only to escape from that bloody seat for a while).