John Cochran

Snark pretty much answered the question. In general, while you're in atmosphere, your center of mass MUST be in front of your center of lift. And with the default way that fuel flows in earlier versions of KSP, this is a problem. With the original "Fuel is taken from tanks furthest away from the engines." This would cause the tanks towards the top to empty first ... Which causes your center of mass to shift to the rear ... which would result in a rocket that's marginally stable upon launch to start out fine and then start flipping end over end later in the flight. Thankfully, that's no longer the default behavior. But if you want your rocket to be as stable as possible, change the fuel priorities so that the rearmost tanks in a stack of tanks are emptied first. Have your center of lift well behind your center of mass. And aerodynamic control surfaces near your center of mass are worthless.

Sorry, gotta do this. Granted, your brother just died. I wish this thread would just end.

I've had a few missions that required an unmanned probe and what you've done is correct. What I believe you haven't done is the "be in control of the probe" portion. You undocked the probe, but you still were in control of the manned spacecraft and not the probe itself. Just switch over to the unmanned probe and wait 10 seconds and you should be good to go.

Granted, you're now the proud owner of a cotton gin that's been tuned to have a frequency of 261.63 Hz when operated. I wish for a faster laptop computer.

Granted. You're now officially insane. I wish for Jeb to stop stowing away on all my new designs.

Slightly off topic, but related. Some years ago there was a study on how to destroy every geosynchronous satellite in orbit. The idea was simple enough, launch a satellite in the same orbit path as that for geosynchronous, but have it retrograde. And the satellite itself would be simply a whole lot of sand and a small explosive charge to disperse the sand into a cloud. After a few orbits, all the geosynchronous satellites would be nothing but junk after being sand blasted by sand with a relative velocity of 6.14 km/sec a few times. The real trick was how to launch the satellite so that the attack wouldn't be expected and to reduce the amount of delta V required. The planned mission would look like a science mission to lunar orbit and while in the vicinity of the moon, it would take advantage of a gravity assist and perform a transfer into a retrograde geosynchronous mission. And the maneuver in lunar space would have been undetectable. So anyone observing the mission would see the launch to the moon, but wouldn't see the return until it was too late and the geosynchronous resources were being sand blasted. So taking a page from that, have your stealthy vehicle look like a remote science mission, and perform your orbital adjustments while outside of view.

You now have a printer that works. However, you're having issues connecting the IBM 1403 printer to your computer. I wish for a grilled ham and swiss cheese sandwich.

How about changing the dpi resolution of your mouse? I'm using a gaming mouse which does have dpi adjustment and whenever I need to tweak my thrust level I lower by DPI to as low as it can go and then I'm able to lower by thrust limit to 0.5% (which is rather surprisingly hard to do with my normal DPI setting) and then after adjusting the thrust, I raise my DPI setting to something more comfortable for actually playing the game.

I would have to agree that the challenge looks both easy and require a lot of patience. Since you're allowed to use liquid fuel to actually build the ship (required to actually get into orbit from Kerbin since the dawn engine has too low of a thrust to even get itself into orbit). Once in orbit, the acceleration of your vessel can approach zero and you'll still be able to escape the planet or moon. So you have two crafts. The lander which is capable of landing and taking off from any system body and the fuel tanker that actually moves from system to system. So figure out how much fuel you actually need to perform the various landings and then push that tank of fuel using a Dawn engine along with enough xenon to go to each planet and moon. You may be able to reduce the overall size of the craft by including a ISRU to make more fuel for the lander.

Granted. However, you really don't want to know what animal the meat came from. Really, you don't..... I wish I knew how the three shells in Demolition Man were used.

You may be thinking of an addon that you used with an earlier version of KSP. For instance, I know that the addon "Docking Port Alignment Indicator" allows you to rename individual docking ports that can then be selected in flight for docking. Have to admit that it's extremely convenient to be stopped relative to a space station about 100 meters away and then be able to cycle through the available docking ports until you find the one you really want to use and then move on in and dock. But the capability to rename dockings ports hasn't ever been in the stock game as far as I know.

Attempting to optimize the first stage booster while performing a suboptimal launch is pretty much an exercise in futility. Also a few statements in your posting indicate an incomplete understanding of a few terms. First, the Oberth effect has only an indirect relationship to low altitudes. It is far closer related to velocity. To illustrate, take a look at the formula for kinetic energy. e = 0.5 * m * v2 Notice the v2 component. Now compare the values of the (v+1)2 - v2 for various values of v. For instance, with a v of 0, you get 1. If v is 10, you get 21, 100 gets you 201, a 1000 gives you 2001, etc. The larger the value of v, the greater the difference between (v+1)2 and v2. So, the higher your initial velocity, the greater the increase in your kinetic energy for the same increase in your velocity. Now at which point in your orbit is your velocity the highest? At periapsis. Hence the Oberth effect in that burning at periapsis gives you the most efficiency for your burns. Now, the mention of energy is quite important in getting to orbit. For any given orbit, the total of the gravitational potential energy and the kinetic energy of your craft is a constant. As your velocity decreases (meaning your kinetic energy decreases), your gravitational potential energy increases (meaning your altitude increases). So to achieve orbit, you need to increase your orbital energy to a high enough level and in the correct proportions for the desired orbit. You do this by changing your velocity by burning propellant. There are three axis which you can make velocity changes. They are prograde/retrograde, normal/anti-normal, and radial/anti-radial. Of those three axis, only a prograde/retrograde vector will change your orbital energy. The normal/anti-normal vector changes the orientation of your orbit, and the radial/anti-radial changes the shape of your orbit. This means that any expenditure of fuel to change your velocity vector in other than the prograde direction is wasted energy. Burning in a non-prograde direction is inefficient and you can do better. Now, of course, there are practical concerns that may mandate that your insertion into orbit isn't completely efficient. Such constraints are the TWR or your rocket, the atmosphere, thermal heating, etc. There are also three loss mechanisms for loss during a launch. There's gravity drag, atmospheric drag, and vector losses (see above about burning in a non-prograde direction). You want to minimize the sum of all those losses during launch. The gravity drag can be reduced by burning at right angles to the local gravity vector. The atmospheric drag is reduced by streamlining and getting into thinner atmosphere. And the vector losses is reduced by minimizing any off prograde velocity changes. Because of all that, the most efficient launch is one where you start your gravity turn as soon as possible and then perform a purely prograde burn, reducing your thrust as your altitude increases, eventually tapering off the zero when you reach your desired orbit. During the entire burn you keep the time 'til you reach apoapsis some small constant number of seconds (40 is about right). If you use too much thrust, what will happen is you'll have a highly elliptical orbit when your apoapsis reaches the desired altitude. And then when you circularize, you're going to have make an extremely large off-prograde burn (see vector losses above). Additionally, your burn is going to happen when your velocity is fairly low (see Oberth effect above) making for even more loss of efficiency. The ideal launch will get your craft traveling close to horizontal with your velocity just above orbital velocity for the altitude you're currently at so your orbit gradually grows larger. This makes your burns happen while traveling at a high velocity (see Oberth effect) and the burn will be constantly prograde (see vector losses) and your vector will be at near right angle to the local gravity vector (see gravity losses). But that pesky atmosphere and the heating and drag effects tend to prevent perfect efficiency. You take care of that by increasing the time until apoapsis which means you're burning a bit more than optimal so your altitude increases faster. This will increase your gravity losses since you're further away from the ideal right angle, but it does get you out of the atmosphere faster so you decrease your atmospheric drag faster and get out of the heating effects before you explode.

I don't know if this will help, but for rescue missions, if you go into the astronaut center and look at the kerbals who are assigned, you'll also see those kerbals who need rescuing if you've accepted the mission. It seems the kerbals aren't generated until after you've accepted the contract, but once generated, you can see them in the astronaut complex and if you then decide that rescuing yet another engineer isn't worth the bother, you can then drop the contract.

TWR is good, but an efficient launch is even better. Instead of using MechJeb for your launch, try using GravityTurn instead. It's rather startling at how overpowered many rockets in KSP actually are. The thread for GT is here at Word of warning involving GT. Launches with GT are SLOW. But they are quite efficient and you can reduce the TWR quite a bit once you understand where in the flight profile that you really need the thrust. So lighter engines and more fuel actually transported to orbit. You'll still want to use MJ to circularize the orbit and for its other functions since GT just handles launches as efficiently as possible.

Since you want the relay to make certain that the comms for future probes work without problems, why not launch the relay and the other mission at about the same time. Say within a couple of days of each other? There's very few times where you need to make multiple maneuvers in short succession, so start one craft on it's way, figure out the next maneuver node, then switch to the next craft. Wash, rinse, repeat.

Can't say I've have a common satellite name. The most common name I keep using is "YAF" standing for "Yet Another Flag". Used for all the silly "Plant a flag on X" contracts and leveling up Kerbals. For some reason, whenever I have a contract to rescue a kerbal, I send up a lander with a probe core providing control and have said rescued kerbal go on an immediate tour to land on the Mun and Minmus planting a couple of flags before actually returning.

This is a perfect situation for having a synchronous satellite hovering directly over KSC. If you have such a satellite, then you simply make that the active craft, and set the asteroid as its target. Wait until the AN/DN is about to touch (taking note of the inclination), then switch back to the rocket and take off with the opposite inclination. Fairly accurate even with the Mark I eyeball, trival with a mod like Gravity Turn or MechJeb.

This is an old video by Scott Manley, but it ought to answer your questions about what SMA (Semi-Major axis), MNA (Mean anomaly), etc

Two pieces of good news for you. 1. There is a of Kerbal Engineer available that works in KSP 1.2. Hasn't yet been released on curse, but I've been using and haven't noticed any problems. It's version 1.1.2.0. Download the master archive at https://github.com/CYBUTEK/KerbalEngineer/archive/master.zip Unzip it, Go to the "Output" folder and copy the "KerbalEngineer" folder to your GameData folder. 2. Parachutes now have an "Open when safe" option. So you can pretty much immediately stage the parachute as soon as you hit atmosphere and the parachutes will actually deploy at the earliest safe opportunity.

I've been using a simple spreadsheet that calculates orbital heights and resonate orbits with same for dropping off equally spaces satellites to use as a commnet. Decided to convert the spreadsheet to google docs and make it available to the public here. https://docs.google.com/spreadsheets/d/1SJcB8x4P4t25jtWR-0TS-06R8Dq5OSslS5R964H32UM/edit?usp=sharing The sheet is only lightly protected in that you'll get a warning if you attempt to modify a field that I didn't intend on having modified. The cells that are intended on being modified have yellow backgrounds. Additionally, the sheet displays the synchronous orbital altitudes for each planet and moon (background goes red if the orbit is beyond the SOI of the planet or moon) and additionally, gives a "holding altitude" if you wish to precisely position a synchronous satellite over a specific location on the planet. For instance, let's assume you wish to have a synchronous satellite directly over the launch pad at KSC. The longitude for that launchpad is at 74°33'27" W. Using the spreadsheet, you can see the "Target Underneath" row and get your satellite into a circular orbit with an altitude of 10,343,473 meters. Then wait until you're directly over KSC. Once that happens, perform a retrograde burn to drop your periapsis to 2,862,940.708 meters and when you reach periapsis, circularize your orbit and you should be positioned directly over KSC. If 10,343 kilometers is inconveniently high (after all, it's high enough to be captured by the Mun), you can put a non-zero integer value into the extra orbits cell and instead of circularizing the first time you reach periapsis after your retrograde burn, you add in the number of extra orbits you specified. For instance changing extra orbits from 0 to 1 changes the holding orbit altitude from 10,343 kilometers to 5,673 kilometers. The bottom of the sheet has the calculations for the resonate orbit required to deposit satellites at a desired altitude. It performs the calculations for performing an insertion at the apoapsis of the resonate orbit or the periapsis of the resonate orbit. Just get your bus into the proper orbit and then release and circularize each satellite when the bus reaches the desired apoapsis or periapsis. In any case, suggestions and improvements are welcome.

As far as I know, once Squad assigned the Kerbals the three professions, only pilots got SAS. Now there are some probe cores that have SAS and if I'm sending up a scientist so that I can use Goo and Materials experiments more than once I always have that ship with a Probodobodyne OKTO or better to actually provide the SAS support (if I'm going to actually land, I'll use a Probodobodyne HEXS or better. I really want that retrograde hold capability).

Just simply pay attention to your network design. I decided to disable all the extra ground stations and have KSC as my only ground station. Since I'm fairly low in the tech tree right now, my most powerful relay is the RA-2 (2 million kilometer range). My network is still limited to just the Kerbin system with 3 synchronous RA-2's in orbit about Kerbin. I know I didn't need to go to the effort of making them synchronous, but having a satellite stationed directly over KSC has some nice advantages over just communications. If I want to launch into Minmus's orbital plane, I switch to the satellite over KSC, target Minmus and then wait until the AN/DN approaches the satellite. Then switch back to the craft on the launchpad and take off with the correct inclination. No mess, no fuss, and nearly perfect match every time. In any case, those 3 RA-2 form the core of my expanding network. Around the Mun, I have 3 more satellites, each with 4 HG-5's acting as a relay. They can get a signal strength of about 99% from any of the RA-2's in orbit around Kerbin and they serve to provide control and science reports for probes and ships working around the Mun. And the network has also expanded to another set of 3 satellites each having 4 HG-5's around Minmus. Unfortunately, there was an ... incident ... upon inserting the 3rd satellite and one of it's HG-5's was destroyed leaving it with only 3 HG-5's. But the signal strength from Kerbin to Minmus was unsatisfactory so there's a 4th satellite in a highly eccentric polar orbit with a RA-2 (orbit has periapsis of 15 km and apoapsis of 2000 km so that it's rarely blocked from contact with Kerbin. This satellite serves to get a 100% strength signal from the Kerbin RA-2's and then relays that signal to the constellation of HG-5's to service any other probes or ships in the area. So to date, there are 10 relays in the Kerbin system. 3 RA-2's around Kerbin itself. 3 sets of HG-5x4 around the Mun and another set of 3 HG-5x4 around Minmus (one damaged) and a RA-2 around Minmus to boost the signal so Minmus has a 100% strength signal. Future plans are to add some powerful relays in highly eccentric polar orbits around Kerbin as the tech for RA-15's and RA-100's gets unlocked. Figure on an apoapsis of about 84,000 km and a periapsis of about 80 km. Those to be built relays will form the core of my future interplanetary network.

I don't see any reason it shouldn't be doable. Kerbin has a 6 hour day and no inclination so daylight should be 3 hours give or take. Chasing the terminator sounds like a bad idea to be completely honest. Simplest approach I can think of is to take off at sunrise and head in a straight line anywhere for one and a half hours. Then turn around and come back to KSP and land upon arrival. If you don't have to actually land at KSP, then the fastest approach I can think of is to take off at sunrise and head due east as fast as you can. As sunset approaches, land where ever you happen to be.

Yes, KSP is a GAME, not a job. However, with that said, different people find different things "fun". Designing rockets may be fun for some people. Planning overall structures to be built on remote body may also be fun. And some aspects of the game just aren't fun for some people. So why not skip past those parts that you consider drudgery? Can I land manually? Yep. Do I find that part of the game fun and interesting? Nope. I find it purely mechanical and boring. Why should I act like a robot when I have a robot available to do that task for me? There are a LOT of different aspects to KSP and different people will find different levels of "fun" with each aspect. Should they be forced to manually perform every aspect because that's part of the game? I say "no", so let them automate those aspects that they find annoying, or in other words "not fun".

I had a contract to haul something with a speed of about 1500m/s under 5000m of altitude. I tried a few times going horizontal with insanely large boosters and wasn't able to hit the target speed before running out of fuel, then hit upon the solution. I instead went vertical to about 40 km to 50 km and let the rocket come back down vertically. Before I hit the target altitude range, I then lit the final stage...