Acet

What I've seen happening in the past is that the drills stop when I restore focus to the the ship, and if I right click they say that it's because they moved. This can happen with standard drills, MKS dust sifters and I used to see it with Karbonite drills when I used it. This is especially bad with bases where a hard component (such as an orange tank) is directly sitting on the ground. In fact, large bases with large hard surfaces sitting on the ground visibly jump when I switch to them, sometimes extremely so. I think this is a problem in KSP's activation of physics calculations on a craft when its landed and focus is switched to it. The best solution I found so far is using landing legs and not locking them. Could it be something like that?

I just did an aerobrake with a C class down to about 48 km and that was fine. The two small active coolers I had open and pointing behind the craft (the asteroid was in front of it all) might have helped. That said, after 3 turns of this I lost patience and used the engines to break the remaining 500 m/s of dV. As somebody else suggested, aerobrakes might be a good idea.

Less launch TWR - 3.86 is way too much. For a liquid fuel launch stage around 1.4 - 1.5 is right. You are probably getting to higher supersonic levels (mach 3+) in the lower atmosphere - you can tell it by the flames around the ship - which is pretty bad for controlling it, especially given that without any fairings the aerodynamic profile at the front of your rocket could best be described as something which wants to get out of the way of the airstream ASAP. Furthermore, an excessive ascent speed means you're wasting too much fuel purely on compensating for aerodynamic drag. You should probably get rid of at least half the engines (drop two side stages, possibly move some of their fuel to the remaining ones) and add an AE-FF1 aerostream proctective shell just below the middle decoupler to make a fairing around the satellite stage.

I do manual landings all the time. Rough guide: - Select a landed ship, flag or kerbal as target. - Quicksave! - Reduce your PE and aim it to the West of where you want to land. The least steep you descent is, the further to the West you should aim. This is because the planet will rotate as you descend so you need to account for descent time and flatter descents take longer. - Put a manouver node at the point where your descent will intercept the planet. Adjust it so that it reduces all speed to zero. This will tell you time and direction that you should fire your engines to stop. - Fire at full power about 10% - 20% AFTER the point when the manoeuvre node tells you to start. If you do it right on the dot you will be too short. At this point your aim is to have your horizontal speed down to zero at the point when the target retrograde markers is exactly centred in the blue side of navigation ball. When this happens it means you're right on top of your target and can simply drop down. - As you're doing final approach (some kilometers from target) you will notice the target retrograde marker moving roughly towards the centre of the navbal. What you want is to make sure it goes to its centre. The way to do this to make small adjustments by firing your engine to make sure that in the navball you always have 3 indicators in a line: your ship's retrograde indicator -> your target's retrograde indicator -> the centre of the blue side of the navball. The closest the target's retrograde indicator gets to the centre of the navball the closest your own retrograde indicator should be of it, ending with all of them at that centre point. You need to think of it as a game where your ship's retrograde indicator pushes the target's retrograde indicator away from it. The furthest your ship's indicator is from the centre the strongest it is pushing the other one way, and if it's at the centre then the push is zero. By firing your ships engines when it's pointing away from its own retrograde indicator you push that retrograde indicator away, with the aim being to keep that 3 indicator alignment i pointed up. - When you're about 500 m away from target you eyeball it for final landing - this is the part where you mostly start ignoring the navbal since as you get very close to it the target's retrograde indicator will quickly drift away from centre. At this point I usually do small burns to send my ship towards the desired landing area and maintain a hoover as it slowly drifts sideways. Once you're on top of where you want to land, aim the ship to its own retrograde indicators and do a controlled burn following that indicator - by aiming at the retrograde indicator rather than straight down you will both kill horizontal and vertical speed. If everything went well, thumbs up, otherwise it's time to load that quick save. I strongly suggest you train in Minmus first, before try the Mun - Minmus has less gravity so everything happens slower and you're less likely to quickly gain tens of m/s of descending speed as result of a few seconds of distraction, which is what happens when doing it in the Mun.

You have to match all criteria at the same time for the contract to complete, so if it says "support 7 kerbals" and "landed in minmus" then it has to support 7 kerbals when landed in minmus (and all the other criteria, including the usual "be stable for 10 seconds") and the contract will complete. What you do after the contract is completed does not matter.

Aim at the base, do the final adjustment yourself. I personally do all landings by hand, tough I use KER to be able to see things like actual distance to the ground and distance to suicide burn point, so as to avoid wasting too much fuel. The secret with final adjustment is to make your base (or a flag, landed ship or kerbal) a target and then try and get the target's prograde indicator to be right on the centre of the blue part of the navbar - which means you're right on top of it - and at that point kill horizontal speed and drop. Once closer to the ground it will start drifting so adjust with horizontal speed to keep it centred. The last bit of adjustment can be done visually when you're close enough. Works fine in Minmus (where you can train this with little risk) and is a little harder on the Mun but not that hard to do (I have bases on both and always land manually). Outright crashing is very rare unless I'm trying some kind of daredevil manoeuvre (like trying to time my burn down to the last second), but it's possible to end up a bit too far from the base if low on fuel (which is a frustrating waste of time due to me having to send a ship or rover to refuel) or do a silly mistake like clipping a solar panel on the base, so I usually quick save before doing a landing from orbit, though less often when just doing suborbital transfers.

If you're using KIS/KAS and are up to trying something slightly insane you can bring some solar panels, small probe core, small SAS, battery, mono prop tanks and mono prop engines and turn it into a ship capable of getting into orbit. Just place the parts around it and link to your own ship for refuelling. Not necessarily the simplest way, but likely to be fun trying.

Whilst piloting that ship, right click on each chute in turn and deactivate it. Now make 2 new empty stages. Add the chutes to the topmost stage, leave the lower one empty. Trigger the lower (empty) stage, NOT the one after that with the chute. There you go: all ready to stage your chutes. (keep in mind that this only works if the chutes have been activated but not deployed or destroyed - i.e. they're blue on the staging bar). I'm not 100% sure if the activate/deactivate button on the chute dialog whilst on flight is 100% core, if not then it's probably from KIS or KAS.

I'm currently in the same situation and the way I ended up doing it was sending a mission upfront with just the scanner probes for Duna and Ike, outside the optimal window and with a shorter transfer time (thus spending more dV, but since probes are light the extra cost is small) and am now preparing to send a crewed mothership with docked landers. In the past I did the whole loose flotilla at the same time thing, and it was messy because of trying to make sure only one ship is aerobraking at any one time. I've also did the sending of EVERYTHING on one ship thing, which is a pain because you have to design it for, amongst other things, aerobraking without loosing (too many) parts. It's seems to be a good compromise to send the lighter stuff upfront before the transfer window and with a shorter travel time so that it gets there and is in place and working before the main mission arrives.

Maybe the order in which you are firing the engines has changed or the order in which you are dropping spent components is different. Remember that the efficiency of the engines (i.e. Isp) affects dV - all other things being equal, the more the Isp of an engine the more dV you get for the same amount of fuel - and solid boosters are notoriously inefficient (they're only useful because of being dirt cheap), which is why they are usually only used on the 1st stage to be fired. Also liquid engines in KSP have lower Isp values the higher the atmospheric pressure (the thicker the atmosphere around them, the less efficient the process by which they work is) - so that's why you see them listed with two Isp values, one for vacuum and one for Kerbin atmosphere at sea level - and their Isp at any point during launch depends on atmospheric pressure at that height (the higher altitude the lower the pressure and closer their Isp is to the vacuum one). What this means is that the later you fire a liquid engine (when going up in atmosphere), the more its Isp, so if for example you order your stages so that you LFO engines only get fired after the SRBs are spent, then you get more dV (since when they do start using their fuel, they are higher and thus under less atmospheric pressure, so are more efficient). Last but not least, you should strive to drop useless mass as soon as possible. For example, dragging SRBs along once they are spent is a waste of fuel (since the fuel left in the stages still in use is now having to drag up not only the mass of the bits of the ship still useful but also the mass of the empty and entirely useless solid fuel boosters). So purely by changing the order by which things fire (even simply from using LFO engines at the same time as the SRBs versus using them separately) or the time when spent sections get dropped, your dV will change.

Aerobrakes! As I recently found out when figuring how to bring back to Kerbin small but heavy containers from Minmus (mined commodities from MKS-Lite), aerobrakes not only make the impossible possible (in this specific case those things were like bullets and never got below safe chute speed before crashing, even at very shallow entry angles, if I didn't put aerobrakes in them) but because you can turn them on or off at will can also be used during re-entry to fine tune landing. Before this discovery I was also having trouble with that, mostly because different ships now have different ballistic descent profiles, depending on their drag, weight and even which direction they are facing at different points when coming down (on start of descent sometimes it helps to present a high-drag aspect), so one had to figure out for each new ship design when and how steep to start one's atmospheric entry to end up close to the KSC. With the addition of aerobrakes I now have something which gives me quite a lot of control during descent (the difference in drag between ON and OFF can be huge) without the need for extra fuel or near impossible manoeuvres to change the side pointing at the wind. (Edited for grammar fixing and clarification)

From what I've been seeing, for TWRs around 1.3 or less you start to spend more dV to get to orbit, quite independently of one's piloting skills. In my experience in situations where the TWR would otherwise be low yet enough for liftoff, it's often better to replace a Skipper engine with a Mainsail, even thought the latter adds 3t (and thus reduces dV), because you end up using less dV to get to orbit. I suspect this is the result of a similar mechanism to why in 0.9 one tried to get a TWR that resulted in the ship ascending at close to Terminal Velocity: to get out of the gravity well (and from paying the fuel price of simply fighting gravity) as fast as possible but not so fast that the losses due to aerodynamic drag were larger than the gains from it. In 1.0 and the new drag model, means that Terminal Velocity is near impossible to reach, but in the lower atmosphere there is a vast increase in aerodynamic drag losses at hypersonic speeds (when there are flames around the ship) so one tries to ascend through the first 30km or so just below the level at which flames start to appear but otherwise as fast as possible, and that sits at around the 1.3 - 1.5 range for TWR in the launchpad.

In career my mid-size payload (10t - 30t) launch stages tend to be based on a Skipper or a Mainsail with an orange tank on top, surrounded by either solid boosters or a ring of liquid boosters in asparagus configuration. What I've found is that for lower payloads the Skipper, being cheaper and half the weight of the Mainsail, will give me more dV at a lower cost, all else being the same. However if the resulting TWR is too low, the ascension takes longer and the dV spent to get to orbit goes up thus eliminating the dV gain. So as a rule of thumb in this setup I'll use Skippers for payloads were the TWR with it of the last launch stage (after all boosters dropped) is 1.3 or more, and for larger payloads I'll use the Mainsail. Also another thing to keep in mind is that the ISP of an engine gets pretty close to its vacuum ISP at about 10k high, so in some case it's actually cheaper and more effective to use a Poodle (really!) as long as you can use boosters only to get you up to that height (for example for 10t loads).

Shallow dip and a ridiculous number of aerobrakes??? Just wondering, I haven't gone to Jool in 1.0.x yet.

One of these, an Oscar-B tank, a probe core, batteries, antenna, thermometer and a few solar panels = very, very light probe/science-sattelite with 2000 dV You can put one such probe on top of a ridiculous small launcher and, for a total of 5k credits you have something with 6000dv which can put satellites in LKO and all of Kerbin's moons (and also land in the latter), as well as do multiple "put satellite in orbit of..." contracts with one launch. That's all of the exploration, land-in XXX, science from orbit, and most put satellite in orbit of XXX contracts take care of for the early/mid game in career. Beyond that, it's maybe only useful to make a mini-hopper with a chair to move kerbals around in Minmus.

This is considered an attempt at changing the terms of the implicit sales contract after a sale and in some countries, such as Germany, the legal framework says that any such things are null and void. In other words, in most jurisdictions, either explicitly or expected (but never tested in court) if you didn't agree to something BEFORE you paid, then any agreement which is forced on you AFTER payment in order to be able to use a product or service which you bought is not valid in the eyes of the law. In those places, for EULAs to be valid you would have to be provided with the full text of the EULA and agreed to it BEFORE you bought a product or service. However, in some US states EULAs have been considered valid.

Start by getting Ubuntu putting it on a flash disk or CD/DVD-R and booting from it to check if it works fine in your machine. Later when you are comfortable you can move that to a fixed partition in one you hard-drives (last I checked Ubuntu made it easy to move like that) Keep in mind that applications installed in Windows will not run in Ubuntu (there might be crazy ways to make some work under Wine, but that's usually too much trouble), so you'll have to install in that OS anything you want to use in Ubuntu, and yes, that means you'll have to explicitly install the Linux version of KSP in your Ubuntu. As for device drivers, Linux has its own device drivers. For any device drivers that don't come with Ubuntu you will have to search the manufacture's sites for their Linux device drivers. I believe both Nvidia and AMD have Linux drivers for Graphics Boards based on their GPUs.

I just have a full blown miner base in Minmus, including drills, conversion, fuel and monoprop storage. It's serviced by a fuel lifter which distributes the fuel everywhere in the system. I've included a Lab since it can also be used for research and to facilitate getting all research together from multiple biomes. Pre 1.0 a lab was actually required to reset Mystery Goo containers and the Science Jr Materials Bay in your science gathering lander, but now a scientist can do it directly in situ. Even in career mode it's not that expensive to get a base like that up there.

The basic principle in KSP (which is much simpler than real life) is that when you enter an SOI, the vector of the planet's speed is SUBTRACTED from the vector of your craft's speed to give the speed of the ship inside the SOI. Once you exit the SOI, the vector of the planet's speed is ADDED back to make the craft's speed outside the SOI. For example, if you enter the Mun's SOI from the head-on (centre front) your speed inside the Mun's SOI becomes your original speed plus the Mun's speed since the Mun is coming towards you (remember that a vector going opposite yours is negative, so when you subtract it you get a positive value). Similarly, when you enter the Mun from behind, the Mun's speed is subtracted from your speed (a subtraction of a parallel vector takes speed away). When you exit in those positions the reverse happens. Now, this doesn't sound very useful since if a craft enters from one side and come out the opposite side, the planet's speed gets added and then taken away on exit in an equal amount, which is not at all useful. However, whilst inside the Mun's SOI your trajectory will curve due to gravity (the lower you go the more it curves) and you can help that even further with some well placed manoeuvring. This means your craft will not actually exit in the exact opposite point as it entered, with the end result being that the speed which is added/removed when entering the SOI is not the same as the one removed/added when exiting. This can be used so that the end result is getting or loosing speed between entering and exiting the SOI purely from the change in your craft's direction under the effect of that planet's gravity. For example, in the extreme (not really possible in reality, just an idealised "what if"), if you managed to enter the Mun's SOI from the front, turn 180 degrees and exit it exactly were you entered, the following would happen: - On entering, the Mun is going opposite from you (hence negative to your craft's speed), so when that negative vector is subtracted away from your craft's speed it actually makes you craft go 542.5 m/s faster - On exiting, the Mun is going the same way as your craft. Because on exit from an SOI, that planet's vector is ADDED, and your craft's speed vector is exactly parallel, you just got another extra 542.5 m/s of speed. the result of this would be an extra 1085 m/s speed, more than enough to get from Mun orbit to, for example, Duna or Eve. Whilst in reality you can't do an 180 degree turn around a planet purely from gravity (though two well placed small burns would get you close to it), you can get more than 90 degrees when low & slow enough near heavy planets. Those 90 degrees would get you from no speed change on entering SOI (if coming from the 90 degrees or 270 degrees in the plane of that planet) to getting the entire orbital speed of the planet added (if exiting via the front) or taken away (if exiting from behind). You can play with this purely in the Kerbin system by getting just enough dV for a ship to exit Kerbin's SOI and then coming back in again (just reverse course) and trying to use the Mun to lower your orbit for a Kerbin aerocapture. You can also try to return from Minmus to Kerbin via the Mun's SOI, using the latter to lower your orbit for a Kerbin aerocapture or in reverse, go up from Low Kerbin Orbit and use the Mun to push your orbit up to Minmus, although these two are harder to get right since Minmus' orbit is inclined (not to mention not usually worth the time). In the big bad world of Kerbol, the dV savings which can be had are much more substantial, though as somebody pointed out above, you will be trading time for dV.

The only way I managed to correct this was to manually edit the save. If I remember it correctly the kerbal in question will be marked as "FLYING" or "SUBORBITAL" (don't remember which one for sure). Just change that to "LANDED". Or maybe that's the fix for broken saves when you somehow manage to quick save while in a vehicle which is momentarily flying. !!! IMPORTANT !!! Make a copy of your save file before you try changing it by hand

My 3-probe mission to Jool I underestimated the fuel for the mothership, so it only had fuel for a very high Apoapsis Jool crossing. I had to send each probe individually from there in different trajectories into an aerocapture, in such a way so that no two probe had coinciding critical moments where I needed to directly control them. One of the probes ended up doing aerocapture in Layte, another in Jool and yet another in Jool but later thanks to a Tylo gravity assist. All of them reached their objectives, but the only one which I could reuse for more than one Jool moon ended up crashing in Tylo due to its TWR not being high enough.

When trying to capture an asteroid: - The point at which you exit the Kerbin SOI is the single most important thing in reaching the asteroid with the minimum possible dV usage: you can save 100s and 1000s of m/s simply by moving around your burn point a bit or burning a little more or a little less. Corrections outside the SOI are far more expensive. - Include at least one mining drill (aimed to where the asteroid will get after grabbing) and one ISRU unit on your asteroid grabber and you can mine the asteroid to make the fuel needed to move it. This is especially good for C class and above. - Choose asteroids with Solar Orbits closer to the orbital plane of Kerbin. The ones which are higher/lower than Kerbin's orbital plane will end up in high-inclination orbits, which are very costly to correct (in fact that can easily cost far more time and dV than the actual asteroid aerocapture). Other: - You can train your Kerbals to 3 stars by: taking them up to Kerbin orbit, transfer-to and land on Minmus and then plant a flag, fly to just out of Kerbin's SOI and then back in and, finally, pass by the Mun's SOI (no need to establish orbit). If you use your Mun SOI pass to lower your orbit via gravity assist, all this can be made using a bit over 3000 m/s of dV from Kerbin Low Orbit.

That ship had great TWR until docked with the 400 ton asteroid. After that, it had a TWR of about 0.01 Considering that a significant amount of the dV spent in an asteroid redirect is to actually go out there and capture the asteroid before it gets into Kerbin's SOI, doing a ship capable of having a TWR of 0.25 AFTER an extra 400 tons are added to it is actually self-defeating since it would require a lot of tonnage in engines which would have to be dragged around useless until the asteroid is reached. The whole purpose of my big asteroid capture missions is to get nice juicy fuel depots in Kerbin orbit, not to try and beat the Kerbin record of most LF+Ox consumed per-second.

It's not the dV of the burn that counts for heat generation, it's the throttle level plus time length. I've had things like 10 minute burns with 4 NERVAs at max while pushing a Class D asteroid into a Kerbin aero-capture trajectory, and while nothing blew up, seeing pretty much every component on that ship showing a high temperature alarm was enervating, to say the least. By the way, that burn was maybe 300-400 m/s dV - it's just that the asteroid was about 400t in weight.

My bulk kerbal training vessel is a bit like that, with the 3-man command pod and 1 hitchhicker. It was used to train kerbals up to 3 starts, which means landing in Minmus and planting flag, flight to just outside Kerbin SOI and then return to Kerbin passing through the Mun's SOI (no landing on the Mun, not even orbiting). For propulsion and fuel it had a Poodle, one of those 1/2 orange tank fuel things and 4x FLT-400. I did refuel it on the surface of Minmus (since I have a mining op there) but I don't think it was needed since I had a lot of fuel left when I got back to Kerbin. However, this setup would not have had enough dV to land in both the Mun and Minmus on the same trip without refuelling. I'm finding it strange that you managed to burn a whole orange tank just to get to the Mun. With LV-Ns you only need Liquid Fuel. Did you emptied all the oxidiser from that tank? By the way Mk1, Mk2 and Mk3 liquid fuel tanks offer a better dry mass to full mass ratio for carrying liquid fuel around than any of the normal tanks.