OhioBob

Also beware that the inner and out radii are in units of planet radii, with 3 implied decimal places. So 24500 and 32500 are 24.5 and 32.5 planet radii, measured from the center of the planet. That's really far away, I kind of doubt that's what you have in mind.

KSP really doesn't like it when it can't find the textures.

I don't know, I haven't done any testing with RealChute. You'll just have to try it and see. That being said, I see no reason why any parachute wouldn't work just as well with these atmospheres as with any other.

What version of Kopernicus are you using? GPP 1.4.0 is not compatible with Kopernicus releases 5 and 6. You have to use release 4.

Actually they do, but it is a subsurface ocean that just produces elevated temperatures. There are no oceans of lava of the surface. (@JadeOfMaar can provide the narrative explaining the presence of the extra heat.)

Interestingly, total solar eclipses shouldn't exist on Kerbin. If you do the math, the apparent size of Mun's disk is about 90% the size of the Sun's disk. Therefore eclipses should be annular, not total. The only visual effect I see occurring during an eclipse it that the sunflare disappears. The sunflare is the bright spot of light seen emanating from the Sun. (If you've ever noticed the sudden brightening of the Sun during sunrise, that's the appearance of the sunflare.) The sunflare disappears when the center point of the Sun is covered. Therefore, when Mun covers up the center of the sun, the sunflare disappears producing an apparent eclipse. This occurs when the Sun is actually only half eclipsed. And since Mun never complete covers the Sun (at least not from the surface of Kerbin), the disappearance of the sunflare shouldn't actually occur at all.

As I understand it, FAR should work with any planet pack or atmosphere. Whether using stock or a planet mod, the same type of data is being passed to FAR, so it shouldn't notice any difference.

There are definitely some things about the tech tree that I'd probably do differently, but what's "great" depends on the individual. If I were to modify the tech tree, I'd rearrange it according to my own vision of what it should be. I would consider your suggestions, but ultimately I'd do it my way, which may not be your way. The only way to guarantee it gets done according to your vision is to do it yourself. @TheRagingIrishman, has offered to write the config for you (I'd be willing to do the same), but you need to tell him under what tech node each part should go.

@The-Doctor, if you just want to move a few parts around in the tech tree, it's pretty easy for you to do that yourself. That way you can customize it to exactly the way you want it. You just need to write a module manager .cfg file and save it somewhere in your GameData folder. The file would include entries that look like this: @PART[solarPanels3] { @TechRequired = advElectrics } @PART[largeSolarPanel] { @TechRequired = largeElectrics } @PART[name] uses the internal name of the part, which can be found from the part's .cfg file. For instance, "solarPanels3" is the internal name for "OX-4W 3x2 Photovoltaic Panels". The cfgs for all the stock parts are in the folder GameData\Squad\Parts\. To change where the part appears in the tech tree, just change @TechRequired to the desired tech. For your changes to take proper effect, you'll have to start a new career or science game. Applying changes in the middle of the game could mess up the tech tree (for instance, a part might appear in both the old and new locations).

I think that if somebody where to create an alternate tech tree, they should just release it as a separate mod. I don't see why it should be specific to and limited to GPP.

GPP is a planet pack. I can't speak for the other developers, but I think changing the tech tree is beyond the scope of what we're trying to accomplish. Aside from adding the new celestial bodies, I believe people should be able to modify the rest of the game as they see fit to match their particular playing style. Part packs, no part packs; life support, no life support; stock tech tree, modified tech tree; etc., should all be left up to the individual player. I don't think GPP should force any particular style of play onto anyone, which modifying the tech tree would do. Rearranging the tech tree as you describe won't just fit GPP, but other planet packs as well. For instance, stock + OPM is very similar to GPP in terms of system size and organization. If someone where to mod the tech tree in this way, it should probably be as a separate addon that can be used with any planet pack. Making it a built-in feature of GPP doesn't make much sense to me. I haven't yet, but if not Iota then the other moon, Ceti is it? Ceti has the same issue as Iota. Both moons are just too small and too warm to retain a substantial atmosphere.

It's more like 120°, or performing your burn at 4 o'clock. Remember that when we're are in low orbit we can see far beyond the horizon that an observer can see on the ground. Mun-rise occurs at a phase angle of 90° for a Kerbal standing at sea level, but for a Kerbal in orbit 80 km above the ground, the phase angle at Mun-rise is 118 degrees.

OK, cool. Thanks for checking it out. I'm not sure why I wasn't seeing it; must have done something wrong.

I recently wrote intensity curves for GPP and I found that I really didn't care much for a linear function. In GPP, as well as many other planet packs like RSS and Stock+OPM, the inner planets are bunched closely together with the outer planets spaced much farther apart, often with their distances increasing exponentially. If a linear function is used in that case, with the zero illumination point set somewhere beyond the farthest planet, there would be very little noticeable change in the light level among the bunched up inner planets. I thought that from a aesthetic point of view, it looked best to have small but noticeable decreases in illumination for each successive planet moving outward from the star. To do this I used intensity curves that look like this one: ScaledIntensityCurve { key = 0 1 0 0 key = 500000 1 0 -2.89E-07 key = 1000000 0.9 -1.44E-07 -1.44E-07 key = 2000000 0.8 -7.21E-08 -7.21E-08 key = 4000000 0.7 -3.61E-08 -3.61E-08 key = 8000000 0.6 -1.80E-08 -1.80E-08 key = 16000000 0.5 -9.02E-09 -9.02E-09 key = 32000000 0.4 -4.51E-09 -4.51E-09 key = 64000000 0.3 -2.25E-09 -2.25E-09 key = 128000000 0.2 -1.13E-09 -1.13E-09 key = 256000000 0.1 -5.64E-10 -5.64E-10 key = 512000000 0 -2.82E-10 0 } Note that the distances increase exponentially (x2) while the light intensities decrease linearly (-0.1). Although this isn't how light intensity varies in real life, I think it produces a nice visual effect in the game. As long as your exponential increases and linear decreases are consistent throughout the curve, the slopes can be computed using the formula, m = X / d where m is slope, d is distance, and X is given by the formula, X = (In+1 - In) / LN(dn+1 / dn) where I is intensity. Any pair of keys can be used to compute X, because each pair should give the same result. For example, let's use, key = 4000000 0.7 -3.61E-08 -3.61E-08 key = 8000000 0.6 -1.80E-08 -1.80E-08 where we have, X = (0.6 - 0.7) / LN(8000000 / 4000000) = -0.1442695 This value of X is then used to compute the slope at any distance. For example, the slope at a distance of 2000000 is, m = -0.1442695 / 2000000 = -7.21E-08 This method gives nice smooth logarithmic intensity curves. The same basic curve can be used for other stars by simply factoring the distances and/or intensities to account for greater or lesser luminosity, and recalculating the slopes. Of course you might not like the way it looks and may choose to use something else. This is only a suggestion.

Stay with 1.3.0-4 until we release an update. Kopernicus 1.3.0-5 added some stuff that GPP 1.4.0 isn't configured to work with.

My biggest rescue came when I landed a crew of three Kerbals on Eve with no plan for a return. I did it just to fulfill several contracts, included landing a base on Eve and planting a flag on Eve. I figured I'd deal with how to bring them home later. The eventual project that I mounted to rescue them was a massive undertaking, but it worked.

It was fixed. 6 hours is now the length of Kerbin's solar day. It's sidereal period is 5 h, 59m, 9.4s.

I might run some further experiments later if I feel up to it, but it's not really something I'm particularly bothered by. In fact, I wasn't even planning to mention it until you wrote. "...with the new kopernicus planets can be illuminated by multiple stars." While that's certainly true when there are no intensity curves and the starlight has infinite range, but I'm not sure it's true when intensity curves are used. At least that's what the few tests I performed seem to imply.

I wish somebody had said that sooner. I had to figure it out by trial and error. BTW, after adding intensity curves it looks to me like a vessel is illuminated only by the star it is in orbit around. For instance, as a test I placed a vessel in orbit around the parent star at distance X and it was faintly illuminated by the parent star. I then placed the vessel in orbit around the faint companion star, but still at a distance X from the parent. In the latter case it didn't appear as if the vessel was being illuminated by the parent. In this intended behavior?

You can stare all you want when it looks like this... Photo by Cameron DaSilva for ABC News

I stared directly at it with my bare eyes for 2 minutes and 38 seconds without any problem at all.

Kerbin time. I don't think Kerbals care how long it takes Earth to rotate.

That's the reason I'll probably never play anything larger than 2.5x. 1x is a lot of fun, and 2.5x makes it feel more realistic, but the large scales just drags the game out too much for my taste.

I have no idea the values of S and CL are. It didn't matter in my calculation because I just assumed the same values are used for both Earth and Kerbin. What I did was, (1/2 * rho * v^2 * S * CL) EARTH = (1/2 * rho * v^2 * S * CL) KERBIN As long as S and CL are the same on both sides of the equal sign, we can just cancel them out.