OhioBob

I'm not sure how to compute inclination change when using electric propulsion. For short high-thrust changes, the formulas are, where the first equation is used to compute the Δv for a stand-only plane change, and the second is the total Δv for a combination altitude change and plane change. Vi is the initial velocity, Vf is the final velocity, and theta is the plane change. I'm guessing that for electric propulsion we probably want to use the second equation. That would mean that a transfer to GEO from a starting inclination of 28.5 degrees (Cape Canaveral) would be about 5.3 km/s. To compute the Δv of the spacecraft, use Tsiolkovsky's equation as linked to and explained by Regex.

That's strange. I'm not sure how to fix it in that case. The only other thing I can think of for you to try is to disable the Kopernicus solar panel module and go back to stock. But I don't know what that will do if you change it in a middle of a save. If you want to try it, I believe there are instructions on how to disable it in the file Kopernicus/Config/SolarPanel.cfg. Better make a backup of your save.

I think you need to do this: Find the vessel. Find the solar panel part. Find the KopernicusSolarPanel module Change the deployed state to EXTENDED. It should look something like this: VESSEL { name = CommSat 1 ... PART { name = solarPanels4 ... MODULE { name = KopernicusSolarPanel deployState = EXTENDED ... Of course that's just the pertinent stuff; there are thousands of lines of other stuff you'll have to wade through. Be sure to make a backup before you change the file.

For a spiral transfer using constant low thrust (i.e. electric propulsion), the delta-v can be estimated by simply taking the difference between the orbital velocities of the initial orbit and the final orbit. For GEO it's about 4.7 km/s, and for KEO it's about 1.3 km/s. This is a little higher than the numbers given by @regex because those are for a two-burn Hohmann transfer. A spiral transfer doesn't take full advantage of the Oberth effect, so it's a little higher. Orbital velocity is calculated using, v = SQRT(μ/r), where μ is the gravitational parameter and r is the orbital radius.

Rescale the solar system to 2.5X.

The trick with Ceti is that it's orbital inclination (9 degrees) is almost the same as the latitude of the launch site (8.64 degrees)*. So if we launch at the right time, we can travel due east off the launch pad and end up in an orbit that matches Ceti's inclination to within a fraction of a degree. We want to launch when KSC it at the same longitude as Ceti's positive antinode. This can be eyeballed in the Tracking Station, but the easiest way to determine launch time is by using KER (and I suppose MechJeb, though I don't use it). Make sure that the orbital category is displaying "Longitude of AN". When that reads 89 degrees, launch. (Theoretically we want to be at 90 degrees when launching, but I've found 89 works better because it compensates for the time it takes to pitch over and get up to speed.) * I actually did this on purpose when I gave Ceti it's orbital elements.

@danfarnsy, glad I could help. Of course this method only works for Iota. I've got a different trick that I use for Ceti.

I've rarely done periapsis kicking, but when I have, this is the procedure I like: Perform the first burn one day prior to the intended departure time with the maneuver node in the correct position for the next day's burn. Burn until the period of the resulting orbit is exactly one day (usually about a 780 m/s burn, depending on initial orbit). This will return the spacecraft to the correct location at the correct time to finish the ejection burn on the second day. The one day orbit has a apoapsis low enough (<5700 km) that there's no fear of accidentally encountering Mun.

Here's what I always do for missions to Iota... The phase angle for a transfer to Iota is about 115 degrees. So launch due east from KSC when the phase angle to Iota is 205 degrees. That is, we're launching when KSC is 90 degrees from the point where we want to place the maneuver node. This will place the descending node of the spacecraft's orbit right where the maneuver node should be. There's no need to wait around, just place a maneuver node at the DN only 1/4 of an orbit from KSC, and off we go to Iota. Sometimes it's not even necessary to do a circularization burn. There is one launch window of this type every day, when KSC is 205 degrees behind Iota. So the only waiting that takes place is on the ground, and it's never more than one day. Yep, use the square root of the scale factor. It's not super precise because there are a few things that this method doesn't take into consideration, but it will get you real close. It should be pretty good for transfer orbits, but I think it overestimates the delta-v needed to launch from the surface of a body.

The first four mods that I install with any new installation are: Kerbal Engineer Redux Kerbal Alarm Clock Transfer Window Planner Precise Node (or Precise Maneuver if you prefer) There are a bunch of other mods I like, but these I consider most essential. I don't even want to play without them. Everything else is optional.

Another life support mod is Snacks. It's a pretty simple way to get introduced to the whole life support thing.

The correct phase angle for a trip to Mun is about 120 degrees. That is, we place the maneuver node on the orbit line at a position that is 120 degrees behind Mun's position at the time of burn. Therefore, when the launch site is not on the equator, what I like to do is launch due east when KSC is at a position that is 90 degrees from where I plan to place the maneuver node, or when the phase angle with the moon is 210 degrees. What this does is it places the spacecraft in an orbit that crosses Kerbin's equator just at the point were we plan to place the maneuver node. In other words, we've created a condition in which the ideal maneuver node position corresponds exactly with the spacecraft's descending node (or ascending node if the launch site is at a southern latitude). Since Kerbin's equator is coplanar with Mun's orbit, this means we're placing the maneuver node in Mun's orbital plane. By ejecting into the transfer orbit while passing through Mun's orbital plane means we can get a good intercept with Mun with minimum fuss and delta-v.

What I was thinking is that instead of flying due east off the launch pad, you start out flying southeast. Then as you start to build up speed, you gradually turn to the east. By the time you really start accelerating, you've straightened out the trajectory and are now heading due east. This will cost more fuel, but it will reduce (or maybe even eliminate) the plane change that has to be done in orbit. It might end up being cheaper in the long run. This could also be done with a regular rocket, it doesn't have to be a spaceplane. Powered turns like this are sometimes done in real life, it's called a "dogleg".

I've been having a similar problem. I've been trying to use HyperEdit to land probe at a set of coordinates that I've gotten from a ScanSat altimetry map. When I enter the coordinates into HyperEdit and kick the land button, I end up over something completely different than what I was targeting. The latitude is correct but the longitude is way off. (edit) I just checked the HyperEdit thread and they are aware of the problem. It's believed that it's likely because of a change in KSP 1.3.1. I suspect your problem is probably caused by the same thing. You're just going to have to wait until the mod authors can figure it out and release updates. If you haven't already done so, you should go to the threads for the mods that you think are affected and see if the issue has already been reported. If not, you should report the problem.

Just a crazy idea here, but since this thing has air-breathing engines, could it possibly be cheaper to fly it to the equator before starting the ascent to orbit?

While the acceleration of a stage isn't constant, the propellant flow rate is (assuming we're not varying the throttle). So we'd get the correct answer if instead of multiplying the burn time of the second stage by the ratio (Δv used / Δv total), we multiplied it by the ratio (propellant used / propellant total). We probably also need to add in a few seconds for staging, therefore the equation becomes Total burn time = burn time remaining in 1st stage + staging time + (total burn time of 2nd stage * (propellant used / propellant total)) or expressed another way, Total burn time = burn time remaining in 1st stage + staging time + (2nd stage propellant used / propellant flow rate) So the trick becomes computing how much second stage propellant we're going to burn. While the math isn't necessarily difficult, it does requires looking up more information than the quick and simple method I showed in my first post. The equation is, mp = mo - mo / EXP( Δv / (Isp * 9.80665) ) where mp is the mass of propellant used, mo is the total starting mass, Δv is the change in velocity, and Isp is the specific impulse.

@The Flying Kerbal, here's the way I often do it. It's not the most accurate, but it's quick and gets me in the ballpark. Let's say we have the following scenario: We need to perform a 1000 m/s burn. The first stage has 400 m/s remaining and will burn for 30 more seconds. The second stage has 1000 m/s and will burn for 120 seconds. We must use 600 m/s out of the second stage's 1000 m/s, so we use that same ratio to ballpark the second stage's burn time: Total burn time = 30 + 120 * 600 / 1000 = 102 seconds. Of course the problem with this is that it assumes the second stage has constant acceleration, which it doesn't. Thus the method underestimates the burn time. I just bump up the result a little bit, which is usually good enough for short burns. There is, of course, a proper mathematical way to compute the actually burn time that I can show you, but it's a lot more complicated then I'm sure most of us would ever want to do in practice.

It's actually far more rare to find a moon that's not tidally locked. It's also very common for planets near to their stars to be tidally locked. It was believed for a long time that Mercury was tidally locked to the Sun. It wasn't until better observations were obtained that is was discovered Mercury is actually in a 3:2 spin-orbit resonance (which is also true of Icarus in GPP).

Well, there are two different mods: Precise Node and Precise Maneuver. So which ever one is giving you the trouble, try the other.

That's odd. Perhaps you can try Precise Node instead.

I find that my rules generally fall a little short for 1.25-meter rockets. I usually have to bump up the proportion a propellant just a bit. But my rules generally hit right about on the money for 2.5-meter rockets.

@LN400, it's pretty easy to do a back of the envelope check of my design guidelines. If we assume each stage is 75% propellant and 25% inert mass, then we can break the whole launch vehicle down into simple proportions: Payload = 3 parts 2nd stage = 4 parts (3 parts fuel) 1st stage = 8 parts (6 parts fuel) TOTAL = 15 parts Specific impulse varies, but let's assume an average of 320 seconds. Then the delta-v is: 1st stage = 320 * 9.81 * LN(15/9) = 1604 2nd stage = 320 * 9.81 * LN(7/4) = 1757 TOTAL = 1604 + 1757 = 3,361 m/s (vacuum) Which is, or course, just about what it takes to get to orbit.

It would be interesting to see how closely my simply rules of thumb line up with your calculations. The guidelines aren't just random numbers that I pulled out of the air. I did quite a few calculations and optimization tests. From that I tried to boil it down to the simplest set of rules that I could easily remember.

The first four I always install with any new KSP installation are: Kerbal Engineer Redux Kerbal Alarm Clock Precise Node Transfer Window Planner I won't play without at least those four tools in the arsenal. And of course there's this, which countless mods rely on to work: Module Manager After that is depends. For that last year I've been playing Galileo's Planet Pack (GPP), which completely replaces all the stock planets with a new solar system. So that requires several mods: Galileo's Planet Pack Kopernicus Modular Flight Integrator Kopernicus/Module Flight Integrator you'll need for any mod that adds or modifies celestial bodies. Then there are the visual mods go really well with GPP: Environmental Visual Enhancements Scatterer Of course those will work with stock KSP as well. Using them in combination with the following will really spice up the look of the stock planets: Stock Visual Enhancements Stock Visual Terrain Then there are other visual mods that add some nice effects: Planet Shine Distant Object Enhancement Real Plume Engine Lighting Reentry Particle Effects And then there are part packs, of which there are many. To name just a few that I like: ScanSat DMagic Orbital Science SpaceY Heavy Lifters One more that I'll mention adds some nice sound effects: Chatterer

My techniques have evolved with time. Back during the time of v0.90 I did things much the way that you describe. I pre-build rockets around certain engines and/or clusters of engines and saved them as subassemblies according to lifting capacity. If a wanted to launch a payload of, say, 10 tons, I would just grab the smallest rocket capable of lifting 10 tons. I've since gone away from that. I now custom build each launcher for each payload, but I adhere as closely as possible to a specific set of guidelines. By following the guidelines I can slap together a launcher pretty quickly, and I get something that's going to give pretty consistent performance. As far as my guidelines are concerned, the launcher is just the part that gets the rest of the rocket/payload to low orbit. So any upper stage used to eject the spacecraft into another orbit is classified as payload for the purposes of design. I also throw in the mass of any fairings, decouplers, etc. So "payload" is everything the sits on top of the launcher at liftoff. The guidelines are pretty simple: 2nd (upper) stage: Propellant mass = mass of payload; TWR = 1.0 to 1.2. 1st (bottom) stage: Propellant mass = 2 * mass of payload; TWR = 1.2 to 1.5. It's not always possible to hit those marks exactly because there are only a finite number of parts to work with. I just get it as close as I can and then make whatever adjustments are necessary to make it work. If there is no 1st stage engine available that will hit within the target TWR range, I'll usually go small and then add a couple SRBs to augment liftoff thrust.