OhioBob

Something you can try doing for a challenge is increasing the size of the system. GPP is set up very nicely for this using Galileo's Rescale configs. I like the 2.5x size because it can be played using all stock parts (no need to mod the parts as is required in real scale), but increases the delta-v requirements just enough that rockets and spacecraft take on a much more lifelike design and appearance. No more being able to get to orbit on one large liquid fuel stage. Generally speaking, you can expect to use two stages to get to low orbit, and three stages to escape orbit.

@Cpt Kerbalkrunch, as you said, OPM is an expansion to the stock system, adding four outer planets and eleven moons. That brings the total number of celestial bodies in the game to 32 (including the sun). GPP replaces the stock system entirely with a new set of planets and moons, and a new home world, Gael. Although Gael looks different, it's the same size with virtually the same gravity and atmosphere as Kerbin. It also has two moons, though with fewer biomes. The only thing that makes missions launched from Gael much different than Kerbin is that KSC is at about 9 degrees north latitude, which introduces some new difficulty into the game. GPP has a total of 31 celestial bodies (including two stars), so it's about the same size as Stock + OPM. As an option, OPM can be added as a planetary system around the second star, Grannus, which is a small red dwarf. I would say the big difference between OPM and GPP is that the OPM bodies are all far from the home world. So if you are adding it for new places to go visit, be prepared for long missions that will take years to complete. GPP, on the other hand, will give you several nearby places that you can start visiting very soon with short trips. You'll be able to delve into something completely new and unexplored without having to undertake long missions. So it's really more just a matter of what appeals to you the most. Of course when you install both GPP and OPM, the OPM planets are really far away around another star, taking decades to get there where you'll be cut off from any support from the home world. As far as mods go, the ones I consider most essential are: Kerbal Engineer Redux Kerbal Alarm Clock Precise Node (or Precise Maneuver) Transfer Window Planner And if you decide to play GPP, there are several optional mods that are recommended. Some of these are packaged with GPP and others you have to download separately. Just be sure to follow the instruction carefully. GPP is also on CKAN if you use that. I definitely suggest the environmental enhancements if your computer can handle it. If you add OPM, make sure you use OPM_Galileo, which is updated for KSP 1.3.1. The original OPM is out of date.

Are you using Sigma Dimensions? One of the Kopernicus releases (1.3.0-7 I think) broke Sigma Dimensions, resulting in that particular error message. If you're using Sigma Dimensions, make sure you update to the latest version.

You should probably post questions about a mod in that mod's thread. You're likely to get more help from the developer(s) and or mod users that way. By starting a separate thread like this, it's just a crapshoot whether or not anybody who can help you will actually see it.

Go back one page.

Yep, that's exactly right. KittopiaTech is a tool used by modders to change the configuration settings of their planets in game so they can see the immediate results. It includes the ability to extractor all the existing settings, which is what the 'dump' is.

According to the Kittopia dump, it's "Northern Basin". https://github.com/Kopernicus/kittopia-dumps/blob/master/Configs/Mun.cfg#L48

The surface can be brutal for heating, but the lower the elevation the worse it is. To mitigate it as much as possible, target the highlands. When in orbit, you should try to stay above 300 km. Higher is even better, but the marginal rate of change is mush less above 300 km than below.

I did the atmospheres for RSS, so it already has realistic atmospheres (but I got a decimal point in the wrong place on Triton, giving it an atmosphere that's 10 times too thick). I also did atmospheres for a few other mods, such as OPM. Galileo mentioned Sigma Dimensions for rescaling planetary systems, such as scaling RSS down to stock size (SSRSS), or when scaling a stock sized system up to real scale. Sigma dimensions has the ability to rescale atmospheres realistically, but only if the user knows how to correctly use the settings to achieve the right result. I can vouch for SSRSS. And for scaling up a stock sized system, I recommend Galileo's rescale configs:

As Galileo explained, this just modifies the already existing atmospheres. While I'm considering releasing additional optional atmospheres, I'm not going to include any bodies that I think are too small and/or too warm to have atmospheres. After all, this mod is called Realistic Atmospheres. Whether or not a body can retain an atmosphere long term is a function of escape velocity and temperature, so it really just comes down to math. The only other bodies in the stock game that I think can realistically support substantial atmospheres are Vall and Tylo, and I think Eeloo might be able to retain a thin atmosphere. If I add any atmospheres it will just be those three bodies. Moho and Mun are not under consideration.

@Fireheart318, I think I see the problem. You're missing a bracket after the first line. You need to do this... @Kopernicus:AFTER[Kopernicus] {

Mun doesn't have an atmosphere, so you shouldn't need the @. That's used when you're changing something that already exists. It looks to me like it ought to work. Maybe it needs temperatureSunMultCurve. Try adding this: temperatureSunMultCurve { key = 0 1 0 0 key = 3500 1 0 0 } Also, change "maxAltitude" to just "altitude". I think those can be used interchangeably, but maybe not.

If you want a green atmosphere, try something like this: lightColor = 0.6,0.5,0.55,0.5 I haven't tested that so I don't know what it will look like, but it should be green.

The stuff you see in the information panel is read from a separate set of parameters (it doesn't get the data from the curves). You'll need to add this: temperatureSeaLevel = 250 staticPressureASL = 101.325 The best way to know if it's working is to land a probe there and see what happens. You can add color using lightColor, but it's not very intuitive. It is a wavelength that uses a weird inverse function. The best way to get the color you want is to use KittopiaTech.

My last post got merged with the previous one; I don't think you saw the addition. Go back and read the second part.

Temperature is needed to compute the air density. You're going to at least need temperatureCurve, of course you can just give it a constant value if you want. You can do something like this: temperatureCurve { key = 0 250 0 0 // give it whatever temperature you want key = 3500 250 0 0 // change altitude to match the height of atmosphere you want } In addition to temperatuerCurve, you're going to need atmosphereMolarMass. That might be enough to make it work. If not we'll have to figure out what else is missing. You might also need adiabaticIndex (used to compute speed of sound). Try this: atmosphereMolarMass = 0.029 adiabaticIndex = 1.4

You have to write a Kopernicus config that adds an atmosphere node to Mun with all the appropriate temperature and pressure curves. Of course first you have to understand what the curves are, what they do, and how to write them. This article explains in detail each curve: I would recommend for any atmosphere that you at least write the curves: temperatureCurve temperatureSunMultCurve temperatureLatitudeBiasCurve temperatureLatitudeSunMultCurve pressureCurve The others aren't as important, you can do without them.

The Rhino is both expensive and heavy for what it provides. I consider it one of the worst engines in the game in terms of both mass and cost efficiency. That doesn't stop me from using it, however. Although it rarely gets any love, one of the best engines is the Twin-Boar. I think it tends to get overlooked because its specific impulse doesn't knock your socks off, and just how good it is in terms of mass and cost efficiency isn't immediately apparent because its numbers include the fuel tank. If we subtract out the fuel tank (which is effectively a Jumbo-64), we begin to see just how good it really is. Compared to other engines in its size class, here's how it stacks up: Twin-Boar Mainsail Rhino Cost 11,250 13,000 25,000 Mass 6.5 6 9 Thrust, SL 1,867 1,379 1,500 Thrust, vac 2,000 1,500 2,000 Isp, SL 280 285 255 Isp, vac 300 310 340

I don't think there's anyway to do that. You can't just have an air in the bottom of the craters. For instance, you can't have air in the bottom of a crater at 2,000 meters elevation without having an atmosphere everywhere below 2,000 meters.

The lunar ascents actually took only about 1,850 m/s.

I would be perfectly content with such an answer.

There's a middle ground that I think is the most appropriate response. "If you are looking for a mod that can perform those calculations for you, then I recommend KER. If you want to perform the calculations yourself, then I suggest you look at Tsiolkovsky's rocket equation. If you need further help, just ask." I think the first assumption should be that the person meant what they wrote.

For most of the part packs I've used, I think the authors have done a pretty good job of trying to give their parts characteristics consistent with the stock parts. There might be something like larger tanks and engines than those found in stock, but they have the same mass ratios, similar specific impulse, etc. As long as they fall on the same performance curve as the stock parts, I wouldn't consider them overpowered. Many parts packs just fill in gaps or are an extension of the stock parts. Of course that doesn't mean that some parts aren't overpowered, I just have seen many examples of that in my experience.

I have no objection to mods, but there is one thing that annoys me. That's when somebody asks a question like "how do I calculate the delta-v of my rocket," and the first answer they get is "install KER." The person asked "how do I calculate...," not "is there a mod that can do this." While I have no problem informing the person that there's a mod that can do the work for them, that doesn't really answer the question that was asked. While mods are a convenience, they are not a substitute for understanding how and why things work they way they do. Some people just want to understand the underlying physics and mathematics even if they use mods to do the tedious work most of the time.

I haven't tried MechJeb yet. I use KER because I want all the data it provides, but I still like flying my own ships for the most part, so I've stayed away from MechJeb. The only flight task that I've started to get tired of (after performing hundreds of them) are launches. Especially since I design all my rockets to the same standards, they all fly about the same. I've started using Gravity Turn. It may not be the most efficient the first time, but you can tweak each successive launch and dial it in.