OhioBob

That looks good except for one tiny thing. The destination orbit altitude should be 2863.3329 km. Remember that that changed when you computed Gael's precise sidereal rotation period. You can get what you need using KittopiaTech. Just select a body, click the "Save Body" button, and it will generate a .cfg file in the folder GameDate/KittopiaTech/Confg. At least the old version did that. I just tried it using the KSP-1.2 version and it didn't work. The .cfg files for the stock planets are also available online, though the files are 11 months old. I don't know if anything has changed or not. https://github.com/Sigma88/Sigma-Dimensions/tree/master/GameData/Sigma/Dimensions/Configs/Bodies/KittopiaExports If you need the data for a mod, you should be able to find what you need in the mod's Kopernicus configuration files. Those files should look similar to the ones above.

You mean something like this + 431.268

Umm, very strange. On my screen I'm seeing the characters "+ 431.268" as a hyperlink (blue underlined). Although I get the hyperlink icon when I hover the mouse pointer over it, it doesn't actually link to anything. When I switch to edit mode I see it as regular black text. I've tried re-typing the text, but every time I click save it turns back into a hyperlink. Oh well, I guess I'll just live with it (even though it's bugging me). (edit) In this post too I'm seeing it as a hyperlink.

I still see one problem. The total Δv for the three-burn method is, 667.652 + 431.268 + 149.846 = 1248.766 m/s That part you got right. First burn inserts you into the transfer orbit, the second burn circularizes the orbit at geosynchronous distance, and the third burn changes the plane to 0o inclination. However, the total Δv for the two-burn method is, 667.652 + 445.933 = 1113.585 m/s In this scenario the second burn is a combination maneuver that both circularizes the orbit and changes the plane. What you did is, 667.652 + 431.268 + 445.933 = 1544.853 m/s, which is incorrect. Combining a plane change with an altitude change can result in a significant savings in Δv; however, getting the timing and angles exactly right to perform a two-burn strategy is more challenging. With the three-burn method you just have to make sure that you are over the correct part of the planet when you reach apoapsis. You don't have to worry about where the nodes are. You just perform the circularization burn at apoapsis, and then you can take your time and perform the plane change when you reach one of the nodes. With the two-burn method you not only have to make sure that apoapsis occurs over the correct part of the planet, but apoapsis must also coincide with one of the two nodes. Also, technically it is the parking orbit that has the 8.51o inclination and the destination orbit that has the 0o inclination. This is because KSC in GPP is located at a latitude of 8.51o N. Unless you fly some sort of dogleg trajectory during ascent, it's impossible to launch into an orbit with an inclination less than the latitude of the launch site. If you fly due east out of KSC, you'll end up in an orbit with an inclination of 8.51o. The plane change is to change the inclination from 8.51o to zero, which is required for a geostationary orbit. I also don't know why you are showing Vi = 149.846. From beginning to end, you use four different orbits in the three-burn method, and three orbits in the two-burn method. Three-burn method Orbit #1: r = 680 km, v = 2278.93 m/s, i = 8.51o. Orbit #2: rp = 680 km, ra = 3463.333 km, vp = 2946.58 m/a, va = 578.54 m/s, i = 8.51o. Orbit #3: r = 3463.333 km, v = 1009.81 m/s, i = 8.51o. Orbit #4: r = 3463.333 km, v = 1009.81 m/s, i = 0o. Burn #1: Δv = 2946.58 - 2278.93 = 667.65 m/s Burn #2: Δv = 1009.81 - 578.54 = 431.27 m/s Burn #3: Δv = 2*1009.81*sin(8.51/2) = 149.85 m/s Two-burn method Orbit #1: r = 680 km, v = 2278.93 m/s, i = 8.51o. Orbit #2: rp = 680 km, ra = 3463.333 km, vp = 2946.58 m/a, va = 578.54 m/s, i = 8.51o. Orbit #3: r = 3463.333 km, v = 1009.81 m/s, i = 0o. Burn #1: Δv = 2946.58 - 2278.93 = 667.65 m/s Burn #2: Δv = SQRT[578.542+1009.812-2*578.54*1009.81*cos(8.51)] = 445.93 m/s (edit) Is anybody else seeing + 431.268 as a hyperlink? I have no idea why it's doing that. Weird.

Well, it is rocket science after all.

578.54 m/s it the velocity at apoapsis of the 80 km x 2863 km transfer orbit. The variables vi and vf are the velocities immediately before and immediately after the second burn, i.e. the circularization burn that takes place at apoapsis of the transfer orbit. Surely you already know how to compute that velocity because one of your spreadsheets shows the Δv of the second burn as 431.268 m/s, i.e. 1009.81 - 578.54 = 431.27 m/s. Just use those same two velocities to compute the Δv with plane change. The velocity at 80 km is irrelevant in this calculation.

The equation to compute the inclination change as a separate burn is, Δv = 2*v*sin(θ/2) where v is the orbital velocity and θ is the plane change angle. For example, at geosynchronous distance, v = 1009.81 m/s, so for a 8.51o plane change we have Δv = 2*1009.81*sin(8.51/2) = 149.85 m/s. If the plane change is combined with an altitude change, then the equation is Δv = SQRT[ vi2 + vf2 - 2*vi*vf*cos(θ) ] where vi is the initial velocity and vf is the final velocity. If we are transferring from a 80 km orbit to a geosynchronous orbit, then vi is the apoapsis velocity of the transfer orbit, i.e. vi = 578.54 m/s. So we have, Δv = SQRT[ 578.542 + 1009.812 - 2*578.54*1009.81*cos(8.51) ] = 445.93 m/s. Without the plane change the Δv is simply, 1009.81 - 578.54 = 431.27 m/s. What you computed is Gael's sidereal orbit period (426 days), not its rotation period. Normally the sidereal rotation period is given, i.e. it is something measured, not computed. (We computed it for the moons because they are tidally locked, i.e. rotation period = orbital period.) From the planet's sidereal rotation period and its sidereal orbit period, we calculate the length of its solar day using the following formula length of solar day = (sidereal orbit period * sidereal rotation period) / (sidereal orbit period - sidereal rotation period) where we just have to make sure that everything is in the same units. For example, Icarus has an orbital period of 319.5 hours and rotation period of 213 hours, therefore its solar day is, length of solar day = (319.5*213) / (319.5-213) = 639 hours. Gael is a little different in that we're given it solar day (6 hours exactly) rather than is sidereal rotation period. We therefore must compute its sidereal rotation period using a rearranged version of the above equation, Sidereal rotation period = (sidereal orbit period * length of solar day) / (sidereal orbit period + length of solar day) We have, Sidereal rotation period = (2556*6) / (2556+6) = 5.98594848 hours. Ciro's radius is 70980 km, not 70.98 km. This makes its gravitational parameter 1.2751483209192E+18 m3/s2.

Just thought of something. If you want to make your orbit geostationary (rather than just geosynchronous), it will require a plain change. For Kerbin the plain change is negligible because KSC is located almost on the equator, but on Gael KSC is 8.51 degrees off the equator. This means that your parking orbit will be inclined at least 8.51 degrees. Your Δv of 1098.92 m/s will get you into a geosynchronous orbit, but you'll still be inclined and will wander a little above and below the equator. To be perfectly geostationary you need to remove the inclination so that you orbit above the equator. If you add a 8.51 degree plane change into your second burn, that brings the total Δv up to 1113.58 m/s. If you perform the plane change as a separate third burn, this adds 149.85 m/s and brings the total to 1248.77 m/s. (edit) Also note that 2863.3528 km is the GSO altitude using Gael's rounded off sidereal period. If you use the exact sidereal period, the GSO altitude computes to 2863.3329 km.

I like that, it has a lot of useful information in it. Some of it looks a lot like my personal notes. We might be able to do something like that, but we're already set up for a more traditional Δv map, so I think we should go ahead and do that first. We can always consider doing it the other way as well. Looks good.

@JadeOfMaar, I'm planning to use this map as a guideline. If you set up your map the same way, then hopefully my numbers will slot right in once I have them.

Sounds good. I have no idea how long this is going to take me to complete. There are a lot of numbers to compute and I've never done this before, so it could be awhile.

I think what I'll use is a median launch window. What I mean by that is that I'll compute the lowest Δv for several successive launch windows, and then take the median of those values. For instance, launch windows for transfers from Gael to Tellumo occur about once every two years. I'll determine what is the lowest transfer Δv is for each of those launch windows. I'll then accumulate data for about 10-20 launch windows (spanning 20-40 years) and take the median of those numbers. This way the Δv map will show a "typical" value if you launch at the optimum time during a launch window. Some launch windows will be a little more and some will be a little less. If you decide to launch at a sub-optimum time (i.e. days before or after the optimum launch window), then clearly the Δv requirement could be much higher. How does that sound? Anyone disagree? I think this makes more sense than just using the absolute minimum Δv that might occur just once every few decades. What good does that really do for you when you're planning a mission? In some cases there could be very high Δv requirements even at a launch window. I know that in the stock game some of the transfers to Moho can be ridiculous. If that should occur here, I'll probably throw out the really bad ones and just use the transfers that are reasonable (assuming that no one will choose to launch during one of those really bad transfers).

Part of it could be that they're figuring the transfer from a lower orbit. You used 80 km, but they could have used 70 km (the absolute minimum). In that case I compute 1111 m/s, so I still don't get 1115 m/s. Also in older versions of KSP, Kerbin's sidereal period was 6 hours (rather than it's current solar day), which made the stationary altitude a little higher. But even taking that into account I still compute a value of only 1111.5 m/s. I don't know where 1115 m/s comes from.

I haven't watched the video so I don't know why there's a difference. But my calculations agree with your numbers. If there's an error I think it's in the video.

Yep, those numbers look good. One small thing, however. It looks like you are still using the rounded off value for Gratian's sidereal period. I recommend that you set Gratian's sidereal period equal to Geminus' sidereal period (they are the same since the two bodies are tidally locked to each another). I also can't tell if you are using Gael's rounded off value or the precise value. If you haven't already done so, I recommend that you set Gael's sidereal period equal to 5.98594847925518 hours.

It looks like you're calculating your dV using an apoapsis radius of 2863.3528 km. That's not the radius, it's the altitude. You are transferring from a radius of 680 km to a radius of 3463.3528 km.

Not really. If the map says you need a minimum of 2000 m/s, that means you could really need 2500 m/s if the conditions are suboptimal. You could add a 10% or 20% margin to the minimum and think you're OK, while in fact you're really screwed.

It's my understanding that most of the dV maps show minimum values. Is that what we want to do here as well, or would it be better to show median values? I usually don't use dV maps, I typically just keep notes of my own dV values that I obtain either by computation or experimentation. In my notes I usually like to keep track of a range from best case to worst case.

I've never made a dV map, but I'm sure I can figure one out. Let me work on that. I'm not sure I can make it look pretty, but I can certainly compute the numbers. We may need somebody else's input to make it look spiffy.

Ha, I have to copy and paste them too. I create them in either Word or Excel (using the insert symbol feature) and then copy and paste them into my forum post.

For the most part that looks pretty good, but there is one major problem. In the PDF from which you got the data, the sidereal periods of the moons are given in days, while your spreadsheet requires hours. You're therefore off by a factor of 6. For example, the period of Eta is 23.86 days x 6 hours/day = 143.16 hours. Also the numbers in the PDF are rounded off, so that's going to produce a small amount of error in your calculations. Two numbers that are exact are mean radius and surface gravity, so those numbers can be used to compute the exact gravitational parameter, as follows μ = 9.81 * g * r2 For example, for Thalia we have μ = 9.81 * 0.30 * 2700002 = 2.145447E+11 m3/s2 You can also calculate the moons' exact sidereal orbit periods (which also equals the rotation periods since they're tidally locked) using the following formula, P = 2 * π * SQRT(a3 / μ) where a is the semimajor axis of the moon's orbit, μ is the gravitational parameter of the parent planet, and the period P is given in seconds. For example, Eta's sidereal period is P = 2 * π * SQRT(113000003 / 2.145447E+11) = 515274.485557695 seconds P = 515274.485557695 s x 1/3600 hr/s = 143.131801543804 hours For your information, all the semimajor axes given in the PDF are exact except for Gael. Gael's exact SMA is 13,984,359,719 meters. (Gael's SMA is carried out to greater precision because that's what was needed to give it an orbital period of 426 days to match the length of the built-in calendar.) The rotation periods of the planets given in the PDF are all exact except for Gael and Gratian. Gratian is tidally locked to its moon, so Gratian and Geminus both have the same rotation period, which is 38.6727788631767 hours. For Gael, its solar day is set to exactly 6 hours, which makes its sidereal period 5.98594847925518 hours. I'm the person who established all these values for GPP, so if you have and any other questions, I'm probably the best guy to ask. (edit) By the way, after you correct the sidereal periods of the moons, you should find that stationary orbits are impossible around all of them.

I'm using the cfgs from Galileo's plant pack. You can download the entire package by going to the thread below. The planet with the rings is Tellumo and its small moon is Lili. If you download the package you will find that neither the rings nor moon has any inclination, which was not our original intent. We were forced to settle for no inclination because when we tried to add inclination we couldn't get the rings and moon to be coplanar (as described earlier). For yesterday's experiment, I edited Tellumo.cfg to split the single ring into two separate rings with 30o inclination, and I edited Lili.cfg to add 30o of orbital inclination. These edits are what you see in my previous post. After making these initial edits and loading KSP, I could immediately see the changes and everything appeared as expected. After that, however, things started to go haywire. No matter what changes I now make to Tellumo.cfg or Lili.cfg, nothing changes when I load up KSP. I even reinstalled the original cfgs, but when I load up KSP I still get Tellumo having two separate rings inclined 30o and Lili is still inclined 30o. It makes no sense. It's like its completely ignoring what it in the cfgs and is somehow remembering and using the settings from a previous version.

I don't know, I've never tested it. I generally avoid using visual enhancement mods because of performance issues. I wouldn't think that my edits to the atmosphere node would have a big effect, but I really don't much about SVE and how it works. Perhaps @Galileo can provide some insight.

I'm completely baffled. There's something really buggy going on here that I can't figure out. The first thing I did was to edit the planet's ring to split it into two rings, both having an inclination angle of 30 degrees. I next edited the moon to give it an orbital inclination of 30 degrees. I then started the game to see what it looked like. At this point everything looked OK - I had two rings as expected and everything was inclined 30 degrees. The only problem was that the ascending nodes of the rings and moon did not match. I estimated approximately how much I needed to change the moon's LAN, exited the game, edited the cfg, and restarted. This time the orientation of the rings and moon was exactly the same as before, i.e. changing the moon's LAN did nothing. I tried a few other cfg changes and, lo and behold, none of my edits are taking effect. I even switched back to the original cfg files and no change. The Module Manager cache is showing my initial edits and is refusing to update no matter what changes I make to the cfg file. I tried deleting the Kopernicus cache, the Module Manager cache, and the logs, but everything is recreated with the same wrong numbers rather than pulling new data from the Kopernicus cfg files. For example, here is the ring node from the current (and original unedited) cfg file: Rings { Ring { angle = 0 outerRadius = 2200 innerRadius = 1200 texture = GPP/Tellumo/PluginData/Tellumo_ring.png color = 0.5,0.65,0.5,0.5 lockRotation = True unlit = true } } And below is what is in ModuleManager.ConfigCache. This is the ring node from my initial edit of the cfg file. It refuses to update even though the Kopernicus cfg now includes the above ring node. Rings { Ring { angle = 30 outerRadius = 1450 innerRadius = 1200 texture = GPP/Tellumo/PluginData/Tellumo_ring.png color = 0.5,0.65,0.5,0.5 lockRotation = True unlit = true } Ring { angle = 30 outerRadius = 2200 innerRadius = 1460 texture = GPP/Tellumo/PluginData/Tellumo_ring.png color = 0.5,0.65,0.5,0.5 lockRotation = True unlit = true } } Similarly, here is the moon's current orbit node: { referenceBody = Tellumo color = 0.0,0.0,0.0,0.0 iconColor = 0,0,0,0 inclination = 0 eccentricity = 0 semiMajorAxis = 1455000 longitudeOfAscendingNode = 0 argumentOfPeriapsis = 0 meanAnomalyAtEpoch = 0 epoch = 0 } And here is what ModuleManager.ConfigCache is showing (note that the inclination is 30 degrees): Orbit { referenceBody = Tellumo color = 0.0,0.0,0.0,0.0 iconColor = 0,0,0,0 inclination = 30 eccentricity = 0 semiMajorAxis = 1455000 longitudeOfAscendingNode = 0 argumentOfPeriapsis = 0 meanAnomalyAtEpoch = 0 epoch = 0 } I'm using Kopernicus Release 3, which is packaged with Module Manager 2.7.2. I noticed that the Module Manager thread is showing the most current release as 2.7.1. I tried both versions with the same result. I find it very bizarre that my original edits took effect while every change I've attempted since then has failed. If anybody needs to see the full logs, I can provide those on request.

I'm getting ready to start some tests to see if it will work. If it does, I'll send you the changes.