OhioBob

Yes, look in the KSP Wiki (link at the top of the forum). Each planet has a table that gives pressure vs. altitude.

@Papa_Joe, the download link in the OP is still taking us to v0.2.6.0.

@LopoMetello, your installation, as you've described it, looks fine. Mod installation is pretty straightforward. Most mods, though not all, include a GamaData folder inside the downloaded .zip file. You just copy the contents of the GamaData folder in the download to the GameData folder of your KSP installation on your computer. As Galileo said, Realistic Atmospheres does not make any visual changes. So you won't see any changes just by looking at the planets. Realistic Atmospheres changes the physical properties of the atmospheres. One quick way to tell if it's correctly installed is go to the Tracking Station, select one of the planets, and check the data in the planet information panel. If you see the following atmosphere heights, then it's working: Eve - 55 km Kerbin - 70 km (same as stock, so select one of the others) Duna - 70 km Jool - 400 km Laythe - 60 km

As Snark has already answered, in KSP specific impulse is not affected by the throttle setting. However, I'd just like to add that in real life throttling an engine can have a small affect on Isp. This is because when an engine is throttled, we are reducing the flow rate of mass through the engine. It therefore takes less force to push the lesser amount of exhaust gas through the nozzle throat. This causes the pressure inside the combustion chamber to drop, and a reduction in the velocity of the exhaust gas. We therefore have a small drop in Isp, though in most cases the decrease is probably not more than a few seconds.

Realistic Atmospheres v1.2.3 appears the play nicely with KSP 1.4.2 and Kopernicus 1.4.2-1.

Tsiolkovsky's rocket equation, where Ve is the exhaust gas velocity. But what we use is actually the effective exhaust gas velocity. The thrust equation is, F = q * Ve + (Pe - Pa) * Ae where q is the mass flow rate, Ve is the actual exhaust gas velocity, Pe is exhaust pressure at the nozzle exit, Pa is the ambient air pressure, and Ae is the area of the nozzle exit. The term q * Ve is called the momentum thrust, and (Pe - Pa) * Ae is called the pressure thrust. Pressure thrust is the result of unbalanced pressures forces at the nozzle exit. For a nozzle that is correctly adapted to its operating environment, the pressure thrust is zero, or near zero. To simplify things we introduce the concept of effective exhaust gas velocity, C, which combines the effect of both momentum and pressure thrust into a single parameter, F = q * C The equation for specific impulse is, ISP = F / (q * g0) which we rearrange as follows, F = ISP * q * g0 So we now have two equations for thrust that we can set equal to one another, q * C = ISP * q * g0 dividing through by q, we have C = ISP * g0 So that's the long explanation for why we use ISP * g0 when we solve the rocket equation.

You can get all the information from the .cfg files. Just go into the OPM/KopernicusConfigs folder and find the planet(s) you are interested in. The information you want is in the "Properties" and "Orbit" nodes. For example, below is the data for Sarnus (abridged): Properties { displayName = #LOC_OPM_Sarnus_displayName description = #LOC_OPM_Planets_Sarnus_description radius = 5300000 geeASL = 0.298 rotates = true rotationPeriod = 28500 tidallyLocked = false initialRotation = 0 isHomeWorld = false } Orbit { referenceBody = Sun color = 0.870588,0.721569,0.529412,1 inclination = 2.02 eccentricity = 0.0534 semiMajorAxis = 125798522368 longitudeOfAscendingNode = 184 argumentOfPeriapsis = 0 meanAnomalyAtEpoch = 2.88114666938782 epoch = 359.279999999964 } In this case the planet's gravitational parameter or mass is not given. These are computed from radius and geeASL as follows: gravParameter = 9.80665 * geeASL * radius^2 mass = gravParameter / 6.67408E-11

Most of the time my SCANsat maps are fine, but every now and then I get one that's messed up. All the data is there, but for some reason the default position of the altitude sliders in color management are way off. No idea why it happens, but thankfully it's easy to fix.

I had a similar problem once. All I had to do was go into the color management settings and adjust the terrain option sliders. Not sure your problem is the same or something different.

Thanks, but that project page is where I've been going. I use to be able to edit from there no problem. But now it's still not letting me edit anything. Maybe it's this Twitch authentication thing. I had problems with that. It says I'm logged in, but maybe not.

I don't know where else to ask this question, and since I figure somebody here might know the answer, here goes... OK, I'm an idiot. CurgeForge recently made changes, and now I can't figure out how to edit my own projects. As I recall, what I use to do was just go to the project page and it would let me edit stuff, upload files, delete files, etc. But now I've got no owner control at all. I just see what everybody else see with no means to edit. What am I doing wrong? How to I gain access to my own projects to edit them? I see no buttons or options anywhere that allows me to do that.

I agree that for something like calculating the delta-v of a rocket, 9.81 is plenty close enough. But I don't agree with that part about orbital period vs. radius using 9.81 m/s2. Orbital period calculations don't even use g0, they use the gravitational parameter, μ. While the value of μ can be defined directly in a celestial body's config, most often it's computed from given values of surface gravity and radius. We use the formula μ = gr2, where g is in m/s2 and r is in meters. In KSP, g is given in units of standard gravities, so we must convert. We have, g(m/s2) = g(gees) * g0, where g0 = 9.80665 m/s2. I haven't found any instances where KSP uses a different value of g0. Of course I agree that on Kerbin g = 9.81 m/s2, but g is not g0. g0 is a universal constant having the value 9.80665 m/s2, while g depends on where you are. But since gravitational parameter uses g and not g0, for Kerbin μ = 9.81*600000^2 = 3.5316E+12 m3/s2. My point in bringing up the exact value of g0 is if somebody is doing something like writing an Excel spreadsheet to do the calculations, then why not just use the exact value. You type it in once and you're done. On the other hand, if you're punching the number into a calculator each time, then the shortcut of using 9.81 is good enough.

That would take a whole new model, which @Snark has said he's not doing. This mod is just doing stuff that can be accomplished through config files. It's possible to rescale parts, but not reshape them. I.e. it's possible to change diameter and length, but not go from cylindrical to conical. You can you Tweakscale for something like that. Though I haven't checked to see if the DLC parts are tweakable.

I don't know how long you've been playing KSP, but there was a time when they used the rounded off value of 9.81. And in rocket calculations they were actually using 9.82, at least that's what people said. But they cleaned that up with the release of version 1.2. I don't know if you've ever noticed, but take a look at Kerbin's information display in the Tracking Station. It shows its ASL gravity as 1.00034 g. Why such an odd number? The reason is because back when Squad defined g0 = 9.81 m/s2, Kerbin had a surface gravity of exactly 1g. But by making g0 = 9.80665 m/s2, had they left Kerbin's surface gravity at 1g, this would have changed its gravitational parameter. And that would have changed familiar numbers that players had already gotten use to, like geostationary altitude. So instead they left Kerbin's surface gravity at 9.81 m/s2, which in standard gravities is, 9.81 / 9.80665 = 1.000341605 g. They did the same thing with the other planets as well.

There may be another way in which you can save a small amount of mass (and money). Are you using a Mk1 command pod? Many of the command pods contain a small amount of monopropellant, which can be removed if you don't need it. Just like changing the propellant mass in the solid rocket booster, right-click on the part in the editor and move the slider. For monopropellant, just take the slider down to zero. For a Mk1 it only saves only 40 kg, but every little bit helps.

Radially in and out changes the shape of the orbit, but not it's mean radius. For example, To change the mean orbital altitude, you have to use prograde or retrograde burns, often employing a combination of burns. For example, one burn to raise the apoapsis, and a second burn to raise the periapsis. Normal and antinormal change the inclination of the orbit. I.e. how much the plane of the orbit is tilted in respect to the planet's equator. (edit) Looking at the posted image, I see that the different colored orbits and descriptions presume the initial orbit is retrograde (clockwise). That's backwards from what is normally the case. For a prograde orbit, the arrows and descriptions should be reversed, with the green orbit being the result of an outward radial impulse.

Also note that the actual value of g0, and the one used by KSP, is 9.80665 m/s2. Though for most calculations 9.81 is close enough.

I assumed he was talking about 1.4.x. It's all up to Kopernicus. Since it's Kopernicus' practice to version lock, no planet pack will work with 1.4 unless there's a version 1.4.0-1 Kopernicus. And since 1.4.1 has been out for nearly two weeks, it would be pretty pointless to do that.

@flekota, all planet packs are on hold waiting for Kopernicus to update. Be patient.

In Ranillon's initial post he didn't say he was running 1.4.1, he just said that it's a problem the Kopernicus devs should look into before updating for 1.4.x. But I agree there's a subsequent post in which he apparently acknowledges that he was using KSP 1.4.1. @Ranillon, if the solar panel problem you're having is while running Kopernicus 1.3.1 in KSP 1.4.1, then please disregard what I said. I recommend that you do not report that as a issue on the Kopernicus GitHub.

OK, I think I read through your post too fast. When you wrote "OPM from Galileo", the thought that immediately jumped into my head was, OPM + Galileo's Planet Pack. Which had you done that, the OPM planets would be orbiting a secondary star. But I see now you meant OPM_Galileo, which obviously isn't the same thing. Clearly my mistake. In regard to your problem, I've never seen that issue. Don't know what would be causing it. I'm not sure how much the Kopernicus devs really follow this thread. I think your problem is more likely to be seen by the right people if you report it on the Kopernicus GitHub. If so, be sure to includes logs. etc. Read "How to get support" in the opening post.

That's what I thought the answer was going to be. Thanks.

@Snark, I know this is off topic, but you seem to know quite a bit about part variants, so I thought I'd ask. Do you know if it's possible to have a variant that changes a part's stats? For instance, could a variant change a part's maxThrust and atmosphereCurve? This could be used to simulate a low expansion ratio (sea level) and a high expansion ratio (vacuum) version of the same part.

@Ranillon, do you have Kerbalism installed? If so, that's likely your problem. Kerbalism does not support multiple stars, so solar panels won't work near any star but the primary star.

@lajoswinkler, that's correct. Kopernicus is a dependency for Realistic Atmospheres, so until we have a 1.4.1 version of Kopernicus, we're stuck at 1.3.1. Other than waiting on Kopernicus, I don't anticipate having to make any changes to Realistic Atmospheres. I think it will work, but I won't know for sure until I can test it.