MrSystems

Good advice above ^. And if you're concerned about not finding enough in time (because they're too rare or whatever), you can launch multiple craft that all meet the criteria. Each telescope only finds objects relatively nearby, but you can for instance have 4 Sentinels 1/4 of an orbit apart (use the same flight plan but launch 1/4 of a Kerbin year apart) to 4-tuple your chances.

Once you're settled in to a circular orbit at the correct altitude, you can enter into an elliptical orbit, having its periapsis at the altitude and latitude needed for the survey, with a period such that you'll be in the correct spot next orbit. Say for example the measurement needs to happen at 100°W longitude, 20°S latitude. You notice this orbit that you're crossing 20°S latitude at 0° longitude. So you know Kerbin needs to rotate 100° in the time it takes you to complete some whole number of orbits. As the commenters above said, Kerbin rotates at 1°/min, so you need to complete an integer number of orbits in 100 minutes. You can then burn prograde at 20°S latitude while you're over 0° longitude so that your new orbit is 100/3, 100/2, or 100/1 minutes long. You can use the orbital period formula to calculate what your new apoapsis would need to be, or you can use the tools built into Kerbal Engineer and fiddle with the maneuver node until the post-burn orbital period is the desired length of time.

The easy (and fuel-inefficient) way that @king of nowhere was talking about: Get to circular Kerbin orbit. Click Minmus and Set Target. Look for the AN / DN (Ascending/Descending Node) markers on your current orbit, and set a Antinormal/Normal maneuver node there such that the AN/DN readout shows 0.0°. It should be about ±230 m/s dV, depending on the height of your orbit and how close to equatorial it is. Burn that node. You're now in the same orbital plane as Minmus. Aim ahead of the planet and set a node (about 920-925 m/s dV) the same way you would do for the Mun. Move the node ahead or behind in time to get an encounter.

I wrote some code in kOS a while back to do the flying to orbit, so I have a consistent basis for experimentation as to how to get to orbit cheapest. You could do some experimentation yourself in MechJeb. I have three different rocket profiles: Boosters + LFE at liftoff, separate trans-orbital stage Boosters + LFE at liftoff, no separate trans-orbital stage Boosters only at liftoff, LFE stage, trans-orbital stage Of those, for most rockets #1 is least expensive. #2 is good for a bulky, draggy payload where much thrust is necessary to gain the first 20km altitude (but using a payload fairing and one of the other types is usually a better choice). #3 is good for small, cheap rockets where the cost of radial decouplers would be a significant fraction of the launch cost. When using method #1, for a 75km orbit I usually aim for about 1200-1400 dV in the trans-orbital stage (plus what's necessary after circularization, of course), with a TWR not too much above 0.8. I then try to have about 1,400 dV in the LFE main stage (leaving 600-800 for the boosters), with a liftoff TWR around 1.0-1.2. The boosters provide the surplus thrust at liftoff, to a total of about 1.8-2.0 TWR. The most expensive part of a launch is the liquid fueled engine in the main stage; this method allows you to use a smaller, cheaper engine than with a two stage to orbit design. Example design: payload is two Large Holding Tanks full of ore (combined mass 34T; 34.7T including pod and nose cone). The trans-orbital stage is a Skipper with Rockomax-32 and Rockomax-16 tanks plus a 2.5m reaction wheel, the LFE main stage is a Mastodon with Delta-Deluxe wings, a Kerbodyne converter (the new one, with fuel) and a Kerbodyne S3-7200, and the boosters (which fire simultaneously) are 3 Stompers (I forget if they're from Making History or from the Missing History mod). The liftoff TWR of just the Mastodon is 1.07; with the boosters the total is 1.98 (in vacuum), with a total craft delta-V of 3,531 and total cost of $51,478 (of which $10,150 was the payload). My code put it into orbit with 169 m/s dV remaining, for 3,362 m/s expended. Example:

My comment here might help:

Here's another possibility: try rotating the Bobcat 90°. It has some pretty intense thrust vectoring, but only along one axis. Right now it's vectoring on the North-South axis, and it might help to have it on the East-West axis instead. (You could also, instead of rotating it, try turning the Gimbal setting down a bit and see if that helps.) A third option is to install Kerbal Joint Reinforcement.

Thanks for that idea! I couldn't find any mods that do it for a KSP version newer than 0.25, but I did find this thread that has the config needed to add it to a part myself. The only question is, what part should I add it to? The klaw? I'll have to think about it.

My method relies on some readouts from Kerbal Engineer. Among other information, it can give the time to impact, the current acceleration of your craft, the surface gravity of the body, and display a red circle where your craft will impact the surface. From a circular orbit, I decelerate about 1/4 of the way around the body so that the red impact circle is just past my intended landing point. I check my craft's acceleration (for this example let's say it's 10.0 m/s²) and the body's delta-v from surface to low orbit listed on the Subway Map (for this example, we'll use the Mun's value of 580 m/s). 580 m/s÷10.0 m/s² is 58 seconds, so I estimate that's how long it would take to slow to a complete stop. With a bit of calculus, you find that 1/2 of 58 seconds, 29 seconds, is how many seconds before impact you would need to begin max deceleration to reach 0 m/s as you hit the surface, assuming 0 gravity. (That number is always 1/2, no matter the body, so you can skip the calculus if desired.) During the time you're decelerating, 58 seconds in this case, you're also being accelerated at the surface gravity of the body. For the Mun that's 1.628 m/s². So you'll also need to burn off (58 × 1.628) m/s = 94.4 m/s of speed you'll pick up while you're decelerating. That's an additional 9.44 seconds of deceleration time in our estimate (during which time you'll accelerate further, so we'll need to be generous in rounding up) (Yes, I know some of that acceleration is angular around the body and doesn't get added to the speed of your craft, but we're rounding up to be safe so we'll ignore that for purposes of an easy approximation) We now have calculated we need to decelerate 29 + 10 = 39 seconds before impact, and you should add a fudge factor of maybe 20% on top of that to be safe, so 48 seconds. Orient your craft retrograde to Surface (not Orbit!) and time warp to the calculated time. Initiate max retrograde burn at the calculated time. Watch the Time to Impact read-out from Kerbal Engineer. It updates to reflect both your current speed and your current engine thrust, so once you've decelerated nearly completely the number will start to climb. This is when you know to reduce the throttle--if the number is climbing you're using too much fuel. Massage the throttle up and down to come to a smooth, slow landing. You should be low enough and close enough to your target that it won't take much fuel at this point. If you accidentally hit 0.0m/s speed, the retrograde SAS hold gets unlocked, so point Radial Out (again, relative to Surface not Orbit) when your horizontal speed gets close to 0. To do the math more precisely requires calculus, because both gravitational acceleration and your craft's acceleration change as you descend, but the approximation above works well enough for video game rocket science. There's also a tutorial in the game, but it doesn't use Kerbal Engineer and therefore incorporates a lot more guesswork and uncertainty.

Limited to 0, though? And the science in the stock game is infinite thanks to contracts and the Mobile Processing Lab. In fact, with the MPL (or a bunch of them on separate craft, rather) you could unlock the entire tech tree without ever leaving Kerbin's SOI.

This is an interesting challenge. I play nearly this way anyway, as I find it a pain to leave Kerbin's SOI without parts from late in the tech tree. Using data from the Wiki, and ignoring any science gained from recovered ships, contracts, Achievements, anomalies, and KSC "mini-biomes", I calculate there are 21,937 science points to be earned doing stock experiments at Kerbin, Mun, and Minmus. 18,468 are needed to unlock the tech tree, Thus, completing this challenge efficiently is a matter of ignoring the most obnoxious 3,469 points. 1,161 points come from being landed or flying at Kerbin; we can discard all of them, leaving 2,308 points to work with. Landing at each Mun biome yields 552 points (ignoring the effects of leveled Scientists); so also one can skip visiting 4 Mun biomes (probably Poles, Polar Lowlands, Polar Crater, and Highland Craters). The remaining 100 points can be spent on not using the Infrared Telescope. The trickiest part of the challenge, I think, would be finding all the biomes without using SCANSat mapping parts, though they don't actually yield science unless you Analyze the scan when it's completed.

Usually the first Kerbol SOI craft I launch in a new game are relays 1/3 of an orbit ahead of and behind Kerbin, at Kerbin's approximate SMA. You can fit them with Infrared Telescopes to scan for asteroids while you're at it.

I just intercepted my first comet, with a craft fitted with all the stock and DMagic Orbital science parts that can do science on asteroids. Not a single one of them would do science on the comet. I get that DMagic might not have been updated yet, but I was surprised that none of the stock science parts were comet-aware. Aside sending a crewed vessel to take a surface sample, is there any way to get science from a comet?

It might be your save--pressure limits are an option that defaults to off. Open your save with a text editor, and look about 200 lines in, under AdvancedParams. Here's how one of mine looks: AdvancedParams { EnableKerbalExperience = True ImmediateLevelUp = True AllowNegativeCurrency = False PressurePartLimits = False <!-- from this line --> GPartLimits = False GKerbalLimits = False <!-- to this line --> KerbalGToleranceMult = 1 ResourceTransferObeyCrossfeed = False ActionGroupsAlways = True BuildingImpactDamageMult = 0.05 PartUpgradesInSandbox = False PartUpgradesInCareer = True PartUpgradesInMission = False EnableFullSASInSandbox = False } You can change it to say PressurePartLimits = True in Notepad , and when you re-load the save the game will respect it.

I was also having an issue with my solar panels not charging. Even the stock OX-STAT, when manually pointed directly at Kerbol in the stock solar system, did not charge. Installing Kopernicus 1.7.3, released yesterday, did not fix the issue. In the file Kopernicus\Config\SolarPanels.cfg is the following note: // This will replace all instances of ModuleDeployableSolarPanel with the Kopernicus version // that has proper support for multiple lightsources // // If you want to keep your ModuleDeployableSolarPanel, add "useKopernicusSolarPanels = false" to the MODULE node // That will stop Kopernicus from replacing it I don't want that behavior while Kopernicus isn't caught up to the version I'm running. So, rather than write a config to add the useKopernicusSolarPanels=F flag to all of my solar panels, I just deleted the Kopernicus\Config\SolarPanels.cfg file and reloaded the game. Problem solved.

The Training mission Asteroid Redirect Part 1 provides assistance with some of these concepts.

Zhetaan gave a really great answer and all his advice is fantastic. I propose here a simpler solution: If you're on the wrong side of the space station, you can just rotate your space station 180° so that the correct side is facing your incoming craft.

Thank you. I'll take a look. Thank you again. I was curious what the most- and least-draggy parts were for the back end of a rocket, particularly as regards engines. Sorting first by diameter and then by Cd_YN×A_YN, I found the following: (note this is for parts in the ordinary prograde orientation, and sticking for instance a nose cone pointing backwards on the butt end of the rocket isn't considered an option in this analysis)

The OP inspired me to do a bit of testing on 1.25m nose cones. My methodology was: start with a flea set to 23.5% thrust (pad TWR ~ 2.11), top with a RC-001S pod, an FL-T100 fuel tank, and various nose cones. I adjusted the fuel in the T100 so the launch mass would be the same each time (2,172 ± 10 kg). I launched straight surface-relative Radial Out from KSC and measured the apoapsis achieved. The maximum speed achieved was about Mach 1.3, so the results should extrapolate to actual rocket launches. The results were: 8,580 m, no nose cone (bare FL-T100). (Interestingly, the amount of drag from the Flea was the same as the drag from the T100) 9,551 m, MK16-XL parachute 12,067 m, Advanced Nose Cone Type A 12,475 m, Small Nose Cone resized to 1.25m using TweakScale 12,844 m, Aerodynamic Nose Cone (the blunt one) 13,702 m, Small Nose Cone on top of an FL-A10 fuel tank 14,063 m, Tail Connector A 14,611 m, Small Nose Cone on top of a "C7 Brand Adapter - 2.5m to 1.25m" fuel tank resized using TweakScale Of the four best options, SNC with empty scaled-down C7 has a mass of 81 kg, SNC with FL-A10 has a mass of 60 kg, Tail Connector A has a mass of 200 kg, and the Aerodynamic Nose Cone has a mass of 30 kg. So I might conclude: If you have TweakScale, use an empty C7 with the Small Nose Cone; otherwise use the Aerodynamic Nose Cone (the blunt one). Also, a mod-maker could improve the stock parts selection by creating a nose cone with the same profile as the C7/SNC.

Fantastic info! Thank you for sharing. I have a question specifically as concerns structural tubes and custom drag cubes. If I wanted to write a custom ModuleManager cfg to fix the tubes, what ought the custom cubes to look like? My PartDatabase.cfg shows the following for the shortest length of the 1.25m tube (annotated as in your example above): Is the problem that the area in the YP and YN dimensions is only PI × (outer_radius² – inner_radius²) when (if the rocket is in a stack) it ought to be PI × outer_radius² (thus 1.227 for the 1.25m size, despite the fact it's 1.217 in all the PartDatabase listings for the other 1.25m parts)? And am I correct in thinking a mod with this "fix" would break (odd, rare) cases where a series of hollow structural tubes with no nose and no tail is used? A second question: how is drag at the trailing edge calculated? On a related note, (thanks to you I now know how to read the drag cubes and where to find them) I dumped all the cubes from my install into a spreadsheet and sorted them by Cd_YP. Drag coefficients for leading-edge parts, and some oddball parts that outperform leading-edge parts, include: Noteable takeaways from the data above include: Never use a Type-B nose cone The Mk1 Cockpit makes a better nose cone than any of the 1.25m nose cones Always use radially-attachable parachutes

I just ran a Duna flyby-and-return mission early in my new career. There might be lower delta-V was to do this, and there are certainly faster ways than what I did, but my method is very simple to plan and did not require much delta-V. Here are the mission parameters: Starting from circular Kerbin orbit at 73km altitude, ... Ejection burn of 1050 m/s on Year 1 Day 227 Minor burn adjustments in Kerbol orbit (~20 m/s) to get Duna periapsis of 80km Arrive at Duna Year 2 Day 47 At Duna periapsis, burn prograde to lower Kerbol periapsis to 13.3 Gm, 483 m/s dV In Kerbol orbit at ascending/descending node relative to Kerbin, burn 32 m/s dV to yield 0 relative inclination In Kerbol orbit at periapsis, burn -190 m/s to get encounter with Kerbin one orbit later Aerocapture at Kerbin at approximately the same (slightly less) relative velocity as an ordinary transfer back from Duna. Total delta-V budget, including the initial transfer burn to Duna, was 1,800 m/s. Mission elapsed time was 3 Years 36 Days.

When you're controlling the debris capsule, EVA the Kerbals inside, one at a time. Have the first one move to the controllable ship and get in. Then right-click on the pod, select Transfer Crew, and move that Kerbal to the other crew cabin on the controllable ship to make room in the pod for the second Kerbal. Then EVA the second Kerbal and have him get in the pod.

Making History has been great. Engine plates certainly make things easier. Also, the Bobcat and the Mastodon end up in a lot of my builds--I just launched a craft where I calculated the most cost-effective solution for a main stage was 5 Bobcats under a 3.75m plate. PSA: All Making History players should get the mod Missing History. What good is a 1.875m stack without a 1.875m reaction wheel, 1.875m probe core, and 1.875m nose cone? (And why were 1.25m plates not included in the DLC?)

I really like this mod! I just installed it yesterday but I wish I had been using it all along. I wanted to know in advance if I had added enough parachutes, rather than hoping for a pleasant surprise when I got out of physics range. So I looked through the source code, did some math, and did some in-game experimentation. The code uses the standard terminal velocity formula, v = ROOT[(2 m g)/(rho A Cd)]. The g used in the code is 9.81m/s² precisely, and rho at sea level in stock KSP is about 1.225 kg/m3, but the area and coefficient of drag for the stock parachutes were not readily available (not surprisingly, the values shown in the VAB and the parts cfg files did not align with expectations). The StageRecovery source code calculates it from the drag cubes, which is not something I am equipped to handle, so I conducted a series of launches varying numbers of parachutes and mass, and wrote down the results. Long story short, these are the calculated Area × coefficient of drag values (in m²) for the five stock parachutes. (The only chute tested more than once was the Mk2-R (n=9, stdev=0.3%).) 102 Mk16 Parachute 411.6 Mk2-R Radial-Mount Parachute 612 Mk16-XL Parachute 14 Mk12-R Radial-Mount Drogue 9.4 Mk25 Parachute (node-mounted drogue) It is also worth noting that TweakScale behaves as expected; a parachute scaled to 200% gives 4× the area of the base model. With that data and the formula, you can calculate the amount of mass you can land under your recovery velocity threshold with a given number of parachutes. Holding velocity constant, mass and area are proportionately-related in the formula, and it can be calculated that: 1 Mk2-R is needed per 1.5447 Mg of mass (not counting parachute mass) to be recovered at 8.0m/s

Two KSP facts: 1) The camera always follows the center of mass of the active ship. The part you place first in the VAB is the "root" of the ship, and as you decouple various stages the active ship stays with the designated root. You can use the Re-Root tool in the VAB to change the root part; in most cases you'll want the root to be the Pod part on the upper-most stage. 2) KSP will mark a craft as "Debris" if it does not have a Pod on it. Therefore, if you decouple and the camera stays with the section marked "Debris", it is because a) the designated root part was on that half of the craft, and b) that half of the craft has no Pod.

I agree with @Zhetaan; I usually make the determination based on the following two factors: Which setup costs less? Which setup is less likely to topple over in flight? Suppose your payload + upper stage has a mass of 50 tons, and you need 2,200 m/s dV from your main stage + booster. If you try to get it all from a liquid-fueled engine with min total TWR of 1.8, you're looking at a Mammoth + 97 tons of fuel, which costs $58,400. If instead you split it to 1,400 dV from the main stage + 800 dV from the boosters, you're looking at a Mastodon* with 43 tons of fuel and cost of $16,600, plus three Kickbacks at a cost not including separators and struts of $8,100, which is about $30,000 less expensive than the other option. (*If you don't have Making History, it would be a Mainsail with 45 tons of fuel, for $5,500 more than the Mastodon but still $25,000 less than doing it without SRBs.) In real life big rockets use boosters for a reason--they're a less-expensive way to add thrust and delta-V at launch. Two more tips: The Small Hardpoint and Structural Pylon, which are in the 'Structural' category in the VAB and unlocked with Advanced Aerodynamics and High Altitude Flight, can be used as decouplers for SRBs and cost much less than ordinary radial decouplers. And the mod SpaceY-Lifters has a great assortment of SRBs that provides a lot more flexibility than the handful of stock options. I made a calculator for use in Excel that will help with planning.