OhioBob

Of course, I should have know that. I was copying the syntax for an OPM cfg, but those are new planets, not revisions to existing ones.

According to my notes, my one and only Tylo mission took about 3400 m/s to land, and about 2650 m/s to launch. My designed required a staging event part way through the descent. About the first 2/3 of the dV was with a TWR of about 1, and the final 1/3 of the dV was with a TWR of about 2.5. If I did it over again, I would probably use a higher TWR throughout.

@Sigma88, I've gotten the new timewarpAltitudeLimits to work, but the new flyingAltitudeThreshold value isn't taking effect. I haven't tested it in the game but, according to the Kopernicus logs, flyingAltitudeThreshold still equals the original stock value. Below is a partial copy of one of my cfg files. Any idea why it's not working? @Kopernicus:FOR[10xSolarSytem] { @Body[Kerbin] { @Properties { rotationPeriod = 43200 timewarpAltitudeLimits = 0 135000 135000 135000 135000 1500000 3000000 6000000 ScienceValues { flyingAltitudeThreshold = 25000 } } @Atmosphere { ........ Here is what the log shows: [LOG 23:07:15]: --------- Science Values ------------ [LOG 23:07:15]: LandedDataValue = 0.3 [LOG 23:07:15]: SplashedDataValue = 0.4 [LOG 23:07:15]: FlyingLowDataValue = 0.7 [LOG 23:07:15]: FlyingHighDataValue = 0.9 [LOG 23:07:15]: InSpaceLowDataValue = 1 [LOG 23:07:15]: InSpaceHighDataValue = 1.5 [LOG 23:07:15]: RecoveryValue = 1 [LOG 23:07:15]: flyingAltitudeThreshold = 18000 [LOG 23:07:15]: spaceAltitudeThreshold = 2500000 [LOG 23:07:15]: -------------------------------------- I realize this may not be a Sigma Dimensions issue, but you seem to know a lot about this stuff and have been really helpful so far. I appreciate your help.

Definitely this one... Landing on a mountainside at night with zero visibility and no parachute.

No, it's just something that I created in Excel. If you revert to the VAB, it doesn't cost you any money. I also usually have a sandbox game that I use for testing and experimentation. I also don't consider running a test to get something like ballistic coefficient to be cheating. Surely Kerbals have ways to figure this out without having to launch a costly mission, such as wind tunnel tests. I just consider my hyperedit/revert to be a wind tunnel test, or whatever, using a low cost model rather than an actual spacecraft. I also figure that Kerbals have computers that can run simulations, so I consider running something like aerocapture tests to determine the correct periapsis altitude just part of the simulations that are run in preparation for an actual mission. I don't like to cheat, but I'm also not a purist who thinks that any revert/quicksave is inexcusable. Sometimes it just makes sense that certain data should be attainable without having to fly a full scale mission.

If you return from Jool at one of the ideal launch windows, you should arrive at Kerbin with a hyperbolic excess velocity of about 2800 m/s. I didn't simulate that scenario exactly, but I did run some simulations for V∞ = 3000 m/s. I used three different ballistic coefficients: 2000, 4000 and 6000 kg/m2 (measured at Mach 10). I determined a periapsis range of 27-29 km for BC = 2000, 23-25 km for BC = 4000, and 21-23 km for BC = 6000. Like I said, these numbers were determined by computer simulation, not by in game testing. I can't guarantee how well it will work in the game. (edit) My recollection is that a Mk1-2 command pod has a BC of about 2000 kg/m2 .

I didn't test Kerbin aerocapture in the game, but I did play around with some computer simulations. I came up with periapsis altitudes ranging anywhere from 20 km to 40 km depending on the entry velocity and the BC, though 25-35 km is probably more realistic for most common scenarios. I don't know of anyway to get the ballistic coefficient prior to flight, but you can get it during flight. Just open the Debug Toolbar (Alt+F12), click the Physics tab, and check "Display Aero Data GUI". This will open a panel that displays a bunch of aerodynamic data, including ballistic coefficient. I usually just run a test flight (Hyperedit is your friend), get the aero info I need, and then revert back to the VAB.

I'll also vouch for From the Earth to the Moon. It's a great miniseries, one of my all time favorites. Anybody with an interest in Apollo should see it. I loved the first episode. It focused largely on the Gemini program, which is the period in America's space program that is usually most overlooked by those in Hollywood.

All the tests that I performed were before the inflatable heat shield was available. My test vehicle consisted of a 2.5m heat shield with varying amounts of fuel tanks stacked up behind it to vary the ballistic coefficient. I haven't tried the inflatable heat shield, but with that big surface area it should definitely lower the ballistic coefficient and make aerocapture easier and safer. Of course it is still necessary to target the correct periapsis altitude, which is still best determined experimentally.

Below is a nice summary and explanation of the losses from the book Orbital Mechanics, Theory and Applications by Tom Logsdon. I would say that for most orbital maneuvers you can use your Δv most efficiently by minimizing steering losses and by taking advantage of the Oberth effect.

Aerocapture at Eve and Jool are definitely possible, but there is a fairly narrow window that you must hit. There are two main factors that come into play when selecting the correct periapsis altitude for aerocapture - entry velocity and ballistic coefficient. I performed a bunch of aerocapture tests last December to try to determine the range of periapsis altitude that will work. I used test vehicles with a range of ballistic coefficients and tested them at different entry velocities. Generally speaking, the higher the ballistic coefficient the lower the target periapsis. Similarly, the higher the entry velocity, the lower the periapsis. Therefore, if you are approach very fast with a high ballistic coefficient, then you want to set the periapsis on the lowest end of the range. On the other hand, if you have a realtively low speed encounter and you have a low ballistic coefficient, then you set the periapsis on the highest end of the range. The combination of high velocity and high ballistic coefficient is the most dangerous and the least likely to succeed. The tolerances are small, and in some extreme cases I couldn't achieve an aerocapture at all without either burning up or losing aerodynamic control. Much greater success is possible if you keep the ballistic coefficient as low as practical. All of my tests at Eve fell within the range of 53 km to 75 km; however, for any particular combination of velocity and BC, the range is much narrower. For example, for the lowest velocity/BC scenario, the range was about 64-75 km, while for the highest velocity/BC scenario, the range was about 55-57 km. The median periapsis altitude was about 62 km. At Jool all of my tests fell within the range of 144 km to 171 km, with a median of about 155 km. For the lowest velocity/BC scenario, the range was abut 155-171 km, while for the highest velocity/BC scenario, the range was about 145-155 km. As you can see, a periapsis altitude of 155 km works for almost every scenario, though it's definitely not ideal for the extreme cases. The above are just some general guidelines. The best periapsis altitude is determined experimentally. Just be sure to do a quicksave in case you get it wrong and have to try again. (edit) By the way, the descriptions in KSP Wiki are based on my experiments.

@Sans Solo, there is no single formula that can do this. There is a reason the term "rocket science" is used to mean a very complex and difficult task. I think that most people figure it out by extensive experimentation. I studied the problem by writing a computer simulation and performing repeated simulated launches until I found what I thought was an ideal design. The simulation involved many formulas; way more than I care to explain. There are also different ways to define "most efficient". If by most efficient you mean getting to orbit for the lowest Δv, then that's very different from getting to orbit for the least cost per unit mass of payload. Generally speaking, trying to minimize Δv results in a bad design; you end up with a big overpowered rocket that's a lousy payload delivery system. I generally lean toward maximizing payload unit cost, which results in a very design in terms of TWR. I ended up boiling my rocket design method down to just a few simple rules that I think work pretty well. I describe it here: And below is a thread in which I compared different optimization methods, i.e. least Δv versus payload efficiency.

As others have said, ascending through the atmosphere during launch will result in gravity and drag losses. There is no easy way to compute what these losses will be but, for a launch from the surface of Kerbin, the losses are usually about 1000-1200 m/s. That is, to attain a final orbital velocity of 2300 m/s will require a launch vehicle Δv of about 3400 m/s (computed using vacuum Isp). Even after attaining orbit, you will still find that the Δv you add during a maneuver is not the same thing as the final speed minus the initial speed. This is because during a maneuver your spacecraft is either increasing or decreasing in altitude, and this change in altitude results in a change in velocity. For example, say you are performing a propulsive maneuver to raise the apoapsis of your orbit to intercept Mun. Typically this is about a 860 m/s Δv maneuver. As you burn the engine the spacecraft speeds up and its altitude begins to increase. Because it is gaining altitude, some of the spacecraft's kinetic energy is being converted to potential energy, resulting in a loss in velocity. So while you are adding kinectic energy during the engine burn, some of that is being lost as a result of the increasing altitude. You will find that the difference between your final and initial speeds is less than the amount of Δv added. For instance, the initial velocity might be 2280 m/s, you add 860 m/s Δv, and your velocity at engine shutdown is 3100 m/s. We see that 3100 - 2280 = 820 m/s. Don't worry about this, it is normal. In this example we "added" 860 m/s Δv even though it might not appear like it when we observe the before and after speeds.

Regarding placement of torque, think of it this way... Suppose we have a long truss structure in which we are using thrusters to apply the torque. Straddling the center of mass we have two 100 N thrusters pointed in opposite directions and placed 1-meter from the CoM. Let's say that both thrusters will produce a counterclockwise (positive) torque. Let's computer the total torque, T = 100 * 1 + 100 * 1 = 200 Nm Let's say that we now move the thrusters out to the end of the truss. The thrusters are still 2 meters apart and pointed in opposite directions, but now both are on the same side of the CoM. Let's say that the farthest is 6 meters from the CoM and the other is 4 meters away. The farthest one will still produce a positive torque, but since the closer one has moved from one side of the CoM to the other, it will now produce a negative torque. The vehicle will still rotate around the center of mass, so we compute the torque around that point, T = 100 * 6 - 100 * 4 = 200 Nm As you can see, we still get the same amount of torque at the CoM regardless of where we place the pair of thrusters (provided the thrusters maintain the same relationship to each other). We can slide the pair of thrusters along the truss from one end to the other and they will always rotate the ship around the CoM with a torque of 200 Nm. The same thing is true with reaction wheels - their placement makes no difference.

Realistic Atmospheres, version 1.2.1 I discovered that my changes to the Sun's atmosphere weren't being applied because of a small syntax error in the configuration file. This has been corrected. I also took this opportunity to change the Sun's molar mass and adiabatic index (hydrogen in the sun is atomic, not molecular), and recomputed it's pressure curve. I also tweaked the shape of temperatureAxialSunMultCurve for those bodies that use it. The effect of these changes are so small that it won't even be noticed during normal game play.

Thanks, I'll give that a try. I appreciate your help. I'm already using that version, so I should be fine. (edit) Yep, that worked. Just plain "Atmosphere" did the job.

I just noticed somethings else while looking at the Kopernicus logs. The OPM configuration files assign a value to "albedo" but this is apparently being ignored. The log files show the albedo as that of the template. Does Kopernicus include the ability to create or change the albedo (and emissivity)? Does it use some name other than the internal name? (edit) I just figured it out. Both albedo and emissivity go under the "Properties" node, not the "Atmosphere" node. @CaptRobau, you should fix that when you get a chance. Your OPM planet cfgs have "albedo" in the wrong place.

I'm creating my own 10X solar system (stock planets + OPM) and I'm using Sigma Dimensions to resize and rescale by a factor of 10. However, I'm creating my own atmosphere cfgs, so I'm setting atmosphere = 1. Therefore, it sounds like I'm OK for time warp limits on atmosphereless bodies and for space thresholds; however, for bodies with atmospheres, it looks like I'm going to have to rescale the time warp limits and flying thresholds myself. Thanks for the explanation.

What I'm attempting to do is create my own 10X solar system (for my own personal use, not to publically release). I'm trying to create a realistic life-sized sun. Here's the cfg: @Kopernicus:FOR[10xSolarSytem] { @Body[Sun] { @Properties { radius = 67160000 geeASL = 28.6 } @Atmosphere { maxAltitude = 2000000 adiabaticIndex = 1.667 atmosphereMolarMass = 0.0013 // Atmosphere Pressure staticPressureASL = 1.01325 pressureCurve { key = 0 1.01325 0 -7.93722E-06 key = 200000 0.177858 -1.70200E-06 -1.70200E-06 key = 400000 0.0227106 -2.46141E-07 -2.46141E-07 key = 600000 0.00269285 -2.64773E-08 -2.64773E-08 key = 800000 0.000459660 -3.74476E-09 -3.74476E-09 key = 1000000 9.65349E-05 -7.27962E-10 -7.27962E-10 key = 1300000 1.06851E-05 -7.70443E-11 -7.70443E-11 key = 1600000 1.26058E-06 -8.82037E-12 -8.82037E-12 key = 1900000 1.70515E-07 -1.05113E-12 -1.05113E-12 key = 2000000 0 0 0 } // Atmosphere Temperature temperatureSeaLevel = 5600 temperatureCurve { key = 0 5600 0 -0.006 key = 470000 4000 0 0 key = 700000 5000 0.0045 0.0045 key = 1000000 5800 0.0016 0.0016 key = 1500000 6150 0.0006 0.0006 key = 1800000 6650 0.003 0.003 key = 1950000 7600 0.014 0.014 key = 2000000 10000 0.1 0 } } } } When I do this I get the following in the Tracking Station: (image deleted) As you can see, the physical characteristics have been updated, but I'm still getting the stock atmospheric characteristics. (Note that I'm using Sigma Dimensions to multiply the radius by 10.) I'm using similar cfg files for the planets and their atmospheres are generating correctly. Here's the log for the Sun. If you need other logs, please let me know. (file deleted) And here is the Module Manager cache: (file deleted)

I'd like to report a recent issue that I've had with Kopernicus. I was creating a mod in which I was changing the properties of the sun. Kopernicus allowed my to change the sun's radius and surface gravity, but it wouldn't allow me to make any changes to the sun's atmosphere. Any changes I attempted to make were ignored and I kept getting the sun's stock temperature and pressure. I had no problem making changes to the planet atmospheres, the problem was only with the sun. I eventually gave up and changed the sun's atmosphere using BodyLoader. I'm using KSP 1.1.3 and Kopernius 1.1.3-1. The only other mod that I had installed at the time was OPM.

@Sigma88, I apologize if this question has already been asked and answered. Do the Resize and Atmosphere multipliers do anything to the time warp altitude limits or the flying and space altitude thresholds? Thanks.

@The White Guardian, nice videos. I appreciate you taking the time to do this. I noticed in your Gas Giant video that you don't know what temperatureSunMultCurve does. I recently wrote a tutorial that explains all the atmospheres curves (see link below). In addition to the three curves identified in your video, there are several other curves that few people seem to know about. These curves define things like latitudinal, diurnal, and seasonal temperature variations, which is all explained in the tutorial. When these curves are omitted from the config file, the curves of the template are used by default. Also, starting with KSP 1.1.3, you must assign a value to the parameter staticPressureASL, which is the atmospheric pressure at sea level (it works similarly to temperatureSeaLevel). If you don't give a value to staticPressureASL, the information panel in the Tracking Station will display the sea level pressure of the template.

I thought about that but decided to go with the numbers that my calculations produced. You can always edit the configuration files yourself if you don't like the default values. For instance, in the file liquidEngineAbel.cfg, you will find the following code, atmosphereCurve { key = 0 274 key = 1 265 key = 5 228 key = 25 0.001 } That's the specific impulse at 0, 1, 5 and 25 atmospheres of ambient pressure. Just round off the numbers if that's what you want to do. Of course if you change the 0 value, you should also change the maximum thrust accordingly. In liquidEngineAbel.cfg you should find the following parameter, maxThrust = 171.25 Just factor this by the ratio, New_Isp/Old_Isp. For example, if you change the vacuum Isp from 274 to 275, then maxThrust = 171.25 * 275 / 274 = 171.875 This step is necessary to keep the propellant flow rate the same.

Based on the orbit of your rescue craft, I don't see any problem getting it to Duna. You just have to wait for the correct phase angle. If I'm seeing things correctly, it appears that your rescue craft is currently about 105 degrees ahead of Duna. The correct phase angle is when you are trailing Duna by about 45 degrees. This means you have 210 degrees of catch-up to do. This should take about 500 days. If you have the patience to wait, I'd just do that. I see no advantage to launching another rescue craft because the phase angle still isn't right. You're going to have to wait for either your current rescue craft to get to the correct phase angle, or you're going to have to wait for Kerbin to get to the correct phase angle to launch a new craft. In either case you have about a 500-day wait, so you might as well just use the craft that you already have. (The rescue craft will actually catch up to Duna faster than Kerbin because it's orbit is a little smaller.) The only reason that I'd consider launching a new mission is if you have any concerns about not having enough propellant remaining in the current rescue craft to refuel the return vessel after you get to Duna. As long as you're sure you have enough propellant, I'd go with option #3. (edit) Oops, looks like I'm way too late.

Yeah, you should probably report that. The rounding is a small issue, but more important is the incorrect sign/direction. If the longitudes are to be given as either E or W, then the number should always be positive, i.e. +76.700W. This is because the cardinal direction tells us which way we're going. Saying -76.700W is a double negative that really means +76.700E. If we are going to use +/- signs, then the directions should always be given as E. In this particular example, we should use either 76.700W or -76.700E, but never -76.700W. We know the longitude is west because the "Edit Waypoint" display is showing it as 283.300457301298 (0-180 is east, and 180-360 is west).