Plusck

Interestingly, wingtip vortice control for the benefit of other aircraft was (apparently) a real concern in the design of the Airbus A380 wings. However, it wasn't to be nice, but because airports would never have allowed the A380 near them otherwise. So still a selfish reason at heart

The parachutes aren't helping the drag or stability problem either since they are not centred. Parachutes (unlike most science instruments and some other radially-attached parts) obey "proper" physics. You can put 50 thermometers on one side of a rocket and it'll behave like they were spread evenly around it. Not so with parachutes. You don't need 4 parachutes for 4 command pods. Two main parachutes (and two drogues, to avoid lawndarting) should be more than enough, so attach them in pairs to one or at most two of those command pods.

A bit of a summary of MinimalMinmus's post but: you can stick a probe core, single battery, solar panels, antennae, docking port, minimal heatshield and dual parachutes set to about 0.22-0.25 on the mk1-2 cabin, throw it at Kerbin's atmosphere with Pe of about 30km with everything staged and then go make a cup of tea. From just about anywhere in the solar system. Sure, it's heavier and more expensive than more Kerbal arrangements, but after your 40th time building something in the VAB and then bringing the remains in for re-entry, that subassembly makes for speedier builds, guaranteed contract fulfilment (coms, power etc.), easier docking (enough monoprop for several dockings, just add RCS), and more tea.

OK, that works now Well, you're right about the lower angle to get to orbit. With the current atmospheric model, you basically want to use as shallow an ascent angle as possible without burning up or running out of time to get your speed up. However, with a ship like that, to be as efficient as possibe you should be initiating the turn off the launchpad. When you start building bigger and draggier vessels, you might go back to starting vertically for better control, but for now it is just costing you (not much... but still), viz.: This is massively overpowered, so 65° off the launchpad works well. With a more reasonable vessel (or with a Swivel instead of a Reliant), 75-85° would probably be better. It looks scary later but it's fine as long as it keeps rising: The main worry is science instruments burning up, so you've got to make sure it is still rising quite quickly at the 30-35km altitude. The other advantage of initiating your turn immediately is you don't need much control authority - the shape of the rocket keeps it flying straight, and "follow prograde" SAS doesn't actually have to do any work, meaning virtually no steering losses either. As for the return burn from the Mun, the reason why your best-placed node is there is two-fold: - you're already on an eliptic orbit, so if the return burn happens anywhere other than at Pe then it'll need to compensate for the current orbit. Your return burn actually has to happen at Ap, so it'll first raise Pe up from the Mun's surface before adding enough velocity to break out of the Mun's SOI. Therefore it is actually adding most velocity in exactly the true direction you want to go in.... if you see what I mean. - since there is a reasonable amount of time before you reach that node, the Mun will have shifted along its orbit by the time you get there. Therefore the burn won't be quite as close to the midpoint between the Mun and Kerbin as it looks in your picture. But whatever the reasons, your resulting orbit around Kerbin looks absolutely fine. It really doesn't look like you're doing anything wrong. If you had been in a circular low orbit around the Mun, it would have looked like this: Notice that Ap on my future orbit around Kerbin is very close to my current orbit around the Mun. By the time I start the burn (37 minutes later) future Ap will be right next to where my ship is. When I come out of the Mun's SOI, I'll actually be part of my way down from Ap towards Kerbin Pe. Like this: One of the hard things to do in KSP is visualise where you'll be in your various moving frames of reference. But your pics show that you're getting the right answers, so you're fine.

Seriously, do NOT take too much of Scott Manley's videos into account. A lot of it is simply not valid for current versions of KSP. Last time I checked he still hadn't added a disclaimer to his videos saying that they don't work anymore, but maybe one day he will... To get to orbit cheaply with a decent powered and streamlined rocket (say a Reliant with two FL-T400s and one FL-T100 above it plus two Hammer SRBs on the side, then upper stage with Terrier and one FL-T400, then Mk1 pod with minimal heatshield (remove most ablator) and no monoprop (remove it too in the VAB) - giving about 22 parts and 17.7 tonnes total (no VAB or launchpad upgrades needed) - you want to drop the nose to about 75° on launch, then follow prograde. Your nose should drop through 45° at about 6000m-8000m. With such an aggressive drive towards the horizon, overheating is the main worry but you should end up in orbit with about 3/4 of a tank left in the upper stage. That's over 1800m/s... More than enough to orbit the Mun and then come back. Enough even to land (but not get back to orbit). Or enough to go to Minmus and land and come back. The alternative system for getting to orbit efficiently (in stock) is to use "follow prograde", then switch to map view once you're over 10km / heading below 45° and just use the throttle to keep the time to Ap (you can right click Ap and it'll tell you) constantly between 40 and 50 seconds. Lower is better but heat, again, can become a problem at around 30km altitude with a shallow ascent. To get to the Mun without manouvre nodes, burn prograde as soon as you see it rise above the horizon, then watch the map. Coming back from low Mun orbit (say 20km), you basically want to wait until Kerbin rises well above the horizon. While pointing prograde (and facing prograde with the camera), you should wait until Kerbin is getting near the edge of your field of view, so in fact you are aiming at a point just under halfway between the Mun surface and Kerbin. Burning prograde and watching the map, again, you should easily get a good return orbit with Pe at about 30km.

Can't add much to the two excellent answers above. Except maybe to underline that the 2-person crew cabin really is an essential early purchase in career mode so that you can make money easily with tourist and large base-building and expansion contracts. Unlocking science instruments comes first, of course, but the crew cabin pays for itself in hard cash very quickly. And the advantage of tourists is they can't go on EVA anyway, so you don't even need to worry about having a hatch-bearing pod on your ship if you have the probe cores to do the actual flying.

I can't say it's a real issue, maybe I'm imagining it, but I worry a bit about CPU overhead with too many relays in range all the time. So my approach has been to limit numbers and power to what is actually needed. A single 2G relay can talk to a command module's internal antenna from any height of Mun orbit. A pair of HG-5s can similarly talk to any single Cummunotron 16. [edit: virtually... I just checked the spreadsheet and it says the very edge of the Mun's SOI might not work...] I also only put 2 relays up. Polar orbits are fine, but the chances of there being no coverage at a critical time are quite high - especially if they are too close. Instead, I'd recommend having two relays on the same plane (which might be polar, or at 30° or even equatorial if you don't plan to go right to the poles), but on opposing highly eccentric orbits. So on one side Pe would be around 15km and Ap on the other side would be about 1,500 km, and the other relay would mirror that. That way, each relay spends virtually all of the time out near its Ap. If you only use two relays there will be spots that aren't covered at times but they will be easily predictable and that only really concerns the far side of the Mun twice per Munar orbit around Kerbin. It's impossible to get the poles covered all the time without doubling the number of relays and getting them perfectly synchronised. Two relays on opposite elliptic sides of a 30-45° plane will keep both poles covered the majority of the time.

The easy way is to build the basic elements horizontally in the SPH. Just attach the large landing legs with snap on, along the centreline of your fuel tank / crew module, attach a docking port either end, and you've got a guaranteed standard height for modules to fit together. Then add some motorised wheels (or landing gear + RCS to push it), making sure they don't touch the ground when the landing legs are down, drive up to the next module and put the legs down. For example: https://imgur.com/a/Kv7el Useful tip: when placing engines in the middle, use the translate tool (press 2 in VAB or SPH) with snap on, and try to move the saddle tanks/octagonal struts or whatever you use to attach the engines. It will snap to the exact centre. This makes it easier to keep the thrust dead centre, and also to attach other stuff symmetrically. Unfortunately Kerbals can't move much around. I have managed to right a fallen rocket by making my Kerbal fall underneath it, and when he sprang up he shifted the whole thing, but these days that sort of attempt tends to cause catastrophic damage.

Personally, I'd start with Moho since it's easy to flyby if you leave Kerbin around day 80 or day 300 in any given year and catch it on your second time around the sun. So I'd start by going past Minmus on the way down to Moho's orbit. Correct at Pe to get a Moho flyby the second time round. From there adjust to flyby Eve and Gilly, to send you back up to Duna. Probably the trickiest part of the whole journey. Land on Duna then Ike, then eject to Jool. Use a Tylo flyby to cature and get sent down to Vall and use that to capture slower at Laythe, flying (and getting contract 2) then landing there. Then back up to Tylo to land. Then eject the Jool system via Bop (getting contract 3), on the way to Eve again. Land on Gilly then end on Eve (getting contract 1). So that makes: - Minmus (flyby) - Moho (flyby) - Eve (flyby) - Gilly (flyby) - Duna (land) - Ike (land) - Jool (flyby) - Tylo (flyby) - Vall (flyby) - Laythe (fly, land) (contract 2) - Tylo (land) - Bop (flyby) (contract 3) (- Kerbin flyby to reduce Eve arrival burn?) - Eve (flyby) - Gilly (land) - Eve (land) (contract 1). Total from LKO I estimate at about 7km/s plus a 5km/s lander (with half of that as drop tanks, only used for Laythe and Tylo), plus whatever you need to capture at Eve that last time (which could be huge if you can't aerobrake or step down to it gently via a Kerbin gravity assist). So actually, that makes me wonder whether it wouldn't be best to start with the Eve flyby and Gilly landing, then do Moho-Eve-Duna, so that you don't need any fuel at all after leaving the Jool system and coming back at Eve for that final, non-recoverable landing. And that is one huge ship.

Can't answer your main question, but with a good Tylo gravity assist throwing you straight down and back out to Pol's orbit, you should be able to circularise at Pol for about that amount of dv, no? Or at least put the mothership on a resonant orbit while your mining craft takes the remaining fuel to circularise and land on Pol. Dres needs much more than that just to capture, so I'm not sure that it would be a rational option even if it were possible to mine without a Klaw.

Ahh. Excellent info, thank you. OK so I was premature in screaming earlier (my 1.2 career save has taken second place to playing with a bunch of other things, so I'm far from mining asteroids yet). So the bug that @bewing was talking about must have been what you said - losing mass under time warp with the small drill - and not what I misunderstood it to mean. Oops. Reading the thread again makes it look like we were talking at cross purposes. This is something I've never experienced because I've simply never tried a small drill on an asteroid. So at the end of the day, it is the small ISRU which effectively throws ore away, not the drill (which is just slower). That is good to know.

I made a spreadsheet specifically for this reason. KER was constantly switching between airbreathing and closed cycle modes, and seemed to be getting it all wrong. So if you have a recent version of Excel it might help you too. It should be pretty self-explanatory - put known values in the first (yellow) set of columns and the columns on the right try to fill in the blanks. I can't remember whether the Spark has the correct Isp or the old value though... P.S. The spreadsheet tells me you have 3594 m/s... edit: the Spark was effectively using the old values. Updated it to fit what's given in the wiki. edit 2: there were a few more changes in 1.2 which I hadn't spotted. Updated.

Um, sorry I didn't properly read your reply earlier. So yes, this is a hugely important change and I'm getting ready to scream about it... "Bug"? What? This isn't a bug. It was perfectly reasonable. The drills start running but there is nowhere to put the ore, so they do nothing. There is no mechanism whereby you can spool up the drills before they start pulling up resources. It's perfectly reasonable to consider that the drill has a sensor on the "output" pipe that determines whether it turns idly or digs into the rock. It would be an extremely stupid system that didn't. So if this has changed, consider me to be screaming ; ) My apologies, if bewing is right then someone has messed this up, and I was wrong about it not changing. Aarghh.

It would be a hugely important (and possibly devastating) change, so you should be safe. I suspect we'd have seen screams of discontent on the forums if it were otherwise).

Simple help without knowing what the problem is: make sure you're leaving Kerbin prograde (parallel to its orbit around the sun) hit Duna when it's directly on the other side of the sun from you place a maneuvre node halfway around and fiddle with it until you get a very close pass by Duna (focus view on Duna, using tab or by clicking on Duna and selecting it in map view, then gently move the sliders on the node until you arrive at about 60km Pe above Duna, going the usual direction... or aerobrake if you have retractable solar panels and suchlike)

If there is nowhere to put ore, the drills mine nothing, they just spool up. At least... this was the case in the last few versions. To be honest I can't remember whether I was testing this in 1.1.3 or 1.2 the last time

Yes, to be really careful not to lose mass, lock your ore tanks while the drills are dialling up to their optimal heat.

Good idea - the wiki entries don't give all the relevant facts. The numbers given in the wiki for production on a CB are exact (I checked this for a thread recently - "ISRU is less more" - with a ton of small drills on a good patch on Minmus). So it's definitely 1/5th the production of the larger drills. And a large drill (with no engineer) will produce 0.25 ore/sec on an asteroid. It will not lose mass if the drills are at 100% efficiency, but will lose mass if they aren't. I'd guess that the small drills produce a fifth of that, chucking the rest of the mass away. So yes, there are three things to write into the wiki: ore output from an asteroid, for both the large and small drills (definitely 0.25/sec for the large, probably 0.05/sec for the small); mass loss (meaning ore loss) using the small drill at 100% efficiency (which i suspect will be 0.20/sec x 5kg = 1kg/sec); mass loss (meaning ore loss) using either drill at less than 100% efficiency.

Keeping it simple: "Wings-only route to the RAPIER". I think the Rapier as finish condition would be the first standard (since to get it you'd need to unlock a lot of the tech tree underneath it). You could add higher achievements, but the Rapier seems to me to be the major hurdle. Rules to keep it simple could be simply never to upgrade VAB/launchpad and/or never to use them (keeping it on trust) and/or to destroy them both deliberately as soon as possible (manned bombing run or inverted SRB as soon as the first probe core is unlocked - radical and ugly but could be seen as a badge of honour).

I've just re-read the OP and I feel a "doh" moment coming on... OP says that the "boosters" are fine but the spinning happens with the "liquid fuel" engine. So that does tend to suggest that the problem is simply that the upside-down lander can is the "control from here" point... which is upside down. SRBs don't care where you're pointing since they can't gimbal. So if the problem starts with the LF engines, that does indeed suggest more than just a question of imbalance.

Following what @AeroGav is saying - you can get the "torque" info in the VAB using KER too - a feature it took me a year to dicover. As for the source of you imbalance: Although it might feel less realistic, you really don't need ladders for the Mun. EVA jetpacks work fine. Getting rid of all ladders and rungs will probably solve most of your balancing issues. That drogue chute will be contributing to imbalance too - not a lot but you might want to put a pair on the probe core instead of a single one on the command module. You really don't need anything more than the command pod's internal antenna unless you have a weak tracking station or you're on the far side of the Mun (but then you need a relay, anyway).

The way I do it, using exclusively https://alexmoon.github.io/ksp/: First find out roughly how much time and dv is needed to go from one planet to the next, only putting an "insertion burn" in for the last planet: So from Kerbin to Jool needs about 1300-1700 days, with very little dv difference, really, about 100 m/s or so at the edges. And from Jool to Eeloo needs about 1300-1700 days too (how strange), Then start with your final transfer (so from Jool to Eeloo) and see how much leeway you have for departure: you can leave between the start of year 9 and halfway through year 10... And work backwards to see when you can leave to arrive at Jool at that time: and you find you have to leave in year 6 day 385 or so to get to Jool in mid-year 10. Or you can leave earlier (year 5 day 365 or so) and take longer to get there. Or start with the transfer which has the least leeway, and work forwards and backwards from there. I managed to do a 6-body route for a contract like this. It was relatively painless, all things considered. Apart from that, I don't think you need to worry too much about phase angles and suchlike for the slingshot maneuvre as such. As long as you intercept, you can slingshot. The important part is the fine-tuning so that you enter the SOI and leave it going the right way, to maximise your orbital energy.

Sorry, "necro bump" - the last post in this thread was over two years ago. So you're bringing it back from the dead. I don't want to sound like the web etiquette police or anything, but it's generally better to start a new thread and link the old one, if it's that old. Still, I'm still wondering why you need to zoom in further. Just zooming in normally gets you very very close. If you move the craft slightly off centre, you can zoom so close that you're actually inside any part you choose to examine. The various info available in this thread covers all of the different possibilities (laptops, keybindings and so on) which is why it's only "a bit" of a necro - your question is a valid extension to what was being said here aeons ago. ; - ) But still, I'm not sure what isn't working for you, given the above plus the newer Mac-specific info (since shift-mousewheel is apparently a system-level binding under MacOS).

Well, you got another upvote from me because it's a very valid question, despite the lack of a real answer. Kerbal EVA suffers from quite a few little shortcomings (as another example, I have yet to work out exactly when it is possible to use the thrusters when in map view, and when my Kerbal will instead try to reorient himself - is that "to camera" on map view or where?); I'd be delighted it it got some dev time in future...

Bit of a necro there. I don't understand what you need, though, since zooming (keypad +/-, or shift-mousewheel) in to the maximum takes you very very close to the middle of the VAB/SPH, and if the part you want to zoom to is actually beyond the scope of zoom it's easy enough to move the craft a touch. If anything, it's zooming out in the SPH which has its limits (especially when importing craft from VAB to SPH).