OhioBob

I've haven't tried rescaling GEP. Let me know how it works. One thing I didn't think about when I made GEP_Primary is that it's quite difficult. It wasn't until I made the delta-v tables that I realized just how challenging it can be. Because Grannus is a red dwarf, the habitable zone is very deep in its gravity well. This places the home world in a small, fast orbit. Interplanetary transfers take way more delta-v than we're accustom to. At 2.5x it will probably be a real challenge. Getting around the Nodens-Belisama system, however, shouldn't be too bad.

I don't think they were overly concerned about realism and internal consistency. They had a certain objective in mind from a gameplay perspective and used artistic license to make it happen. I don't fault them for that. But for Realistic Atmospheres, I have a different objective. That's to make the atmospheres more realistic. I can't make them 100% realistic because KSP is a 1/10th scale solar system. I have to make accommodations for scale, which requires some artistic interpretation in how I'm going to adjust the models to fit the smaller bodies. But for the most part, my atmospheres are determined by what the equations say they should be, not by what I want them to be.

plz don't ask that. The author of this mod is under no obligation to update and doesn't owe you anything.

I don't know if there's a minimum, but I've gone as small as 7000 meters and it worked. Never tried anything smaller than that. BTW, I think your config needs to include a template. I'm not sure it will work without one. Try something like this: @Kopernicus:AFTER[Kopernicus] { Body { name = Peor Template { name = Moho removeAllPQSMods = True // If you do this, you'll need to add back whatever PQSmods you need. } Properties { ...

@Gameslinx, it appears that deleting the launch sites as previously discussed is producing a bug (see the GPP thread for more info). So unless the problem can be rectified, I recommend not deleting launch sites.

I've found a temporary solution to the problem reported by @Standecco. GPP (and GEP_Primary) deletes the Desert Launch Site added by the Making History DLC.* I don't know the reasons, but something about deleting that site is causing the problem. To fix the bug, you just have to remove the code that deletes the launch site. Find the following file: GameData/GPP/GPP_Planets/Gael_A.cfg and delete the following line of code: removeLaunchSites = Desert_Launch_Site, Desert_Airfield, Desert_GroundObjects, Woomerang_GroundObjects Hopefully we'll fix the issue for the next update. * It was deleted because of where is was located and the inability to edit it made it an eyesore that was not easily fixable.

@Gordon Fecyk, another possibility would be to increase Eve's surface pressure and decrease the molecular weight. This would get us close to producing something similarly challenging to the stock game. Of course this would imply that the composition of Eve's atmosphere is much different than the original. It would change it from an atmosphere that is likely predominately carbon dioxide to one that is likely predominately nitrogen. Let's say we made the sea level air pressure 8 atm, and the mean molecular weight 29.6 g/mol (90% N2 + 10% CO2). This is what we'd end up with: The atmosphere would have approximately the same total mass as the stock atmosphere. The air density near the surface would be about the same as the stock atmosphere, so drag would be similar. The height of the atmosphere would be about 60-65 km. Higher surface pressure would decrease engine performance, increasing the difficulty of launches from low elevations.

Possibly. I don't think there is anything more I can do on the issue at this time. I'll consult with the GPP/Kopernicus devs teams to see if we can figure it out.

I'm getting the same bug. But it's not just GPP, I'm getting it with GEP_Primary as well. (edit) Plain Stock seems to be working OK, as well as Stock + GPP/GPP_Secondary, and Stock + GEP. GPP and GEP_Primary both delete and replaced Kerbin, so maybe that is somehow causing the problem. (edit 2) I just did an experiment in which I installed GPP in its entirety, but deleted Gael and kept Kerbin as the homeworld. In that case the recovery button works fine. So, yeah, it looks like the problem is occurring only in scenarios where Kerbin is deleted and replaced by something else.

I actually "cheated" to get Eve's atmosphere up to 55 km. Had I computed it like the other atmospheres using Eve's actual physical properties and given surface conditions, it would have ended at something like 35-40 km. I thought that was way too low, so I ended up doing the computations using a surface gravity of only 1.2 g instead of 1.7 g. That stretched it out to 55 km. I felt dirty doing that because it wasn't "realistic", but it was a gameplay decision. I will not force Eve's atmosphere to 90 km just because we want it to be 90 km. There has to be some justification for it or else there's no point calling the mod "Realistic Atmospheres". The only way to justify a 90 km atmosphere is to make significant changes to the properties of the planet and/or atmosphere. But then it wouldn't be Eve anymore. The only way to increase the height of the atmosphere is to increase the scale height. That means we have to, (1) increase temperature, (2) lower molecular weight, (3) lower surface gravity, or some combination of the three. But if the goal is to make getting off Eve as difficult as the stock game, then none of those options work. Obviously, lowering the surface gravity makes getting off Eve easier. And the other options makes the atmosphere less dense, i.e. less draggy. There is just no realistic way to give Eve an atmosphere like the stock one because the stock atmosphere is very unrealistic. One way to look at it is this... Above each square meter on the planet's surface is a column of air that extends all the way to the top of the atmosphere. We can compute the mass of air in that column by dividing the surface pressure (which is the weight of the air) by the gravity. On Eve we have, 5 * 101325 / (1.7 * 9.80665) = 30,389 kg/m2 But if we take Eve's stock atmospheric model and compute the mass of air by integrating from 0 to 90 km, we find that a column of air has a mass of about 50,000 kg/m2. This means that Eve's atmosphere has more air in it then there is pressing down on the planet's surface. (In real life, both methods of calculation should yield the same result.) In Realistic Atmospheres, an air column on Eve has an integrated mass of about 34,500 kg/m2, which is close to what it should be based on the surface conditions. The result is a little higher than what it should be because I cheated and stretched the atmosphere to get it up to 55 km. (For most atmospheres in Realistic Atmospheres, the integrated mass is 80% of the value computed from the surface conditions. This is because after computing an atmosphere, I compress the height scale by 20% for use in KSP. This is because that's what Squad did for Kerbin's stock atmosphere, and I've chosen to continue the practice.) Perhaps the most realistic solution is to give Eve's atmosphere a sea level pressure of 8 atm, and compute the atmosphere above realistically without modification. This will give Eve an atmosphere with the same mass as the stock game, so a rocket will have to pass through the same amount of air during launch. The atmosphere height will surely be much less than 90 km, but difficulty will be added because of the higher surface pressure. So it will be easier in one regard and more difficult in another, so maybe it's a wash. (edit) I just discovered that when I calculated the area mass of Eve's atmosphere, I did so using an old model. Eve's atmosphere was revised in KSP 1.2. Using the current model and computing the mass by integration, I now get about 69,000 kg/m2. With that mass, Eve's surface pressure should be 11.4 atm.

Sorry, I didn't notice that you left out the ln or I would have mentioned it. You can read more about the rocket equation here, https://en.wikipedia.org/wiki/Tsiolkovsky_rocket_equation

GPP is for all practical purposes finished. As long as Squad's updates are just bug fixes, and Kopernicus continues to keep up with new releases, GPP should work with it. Where things could get messed up is if Squad releases a major update that royally screws up a bunch of mods. If that were to happen, I can see frustrations boiling over to the point where some modders will say screw it and not update their mods. We could become frozen at a certain version number.

We intend to continue providing and maintaining GPP for the foreseeable future. It's not going away, we're just not planning on adding new content.

Exhaust velocity = Specific impulse * 9.81

Two alternative launch sites have been added - the Woomerang Launch Site and the Desert Launch Site (and Air Field). I believe both require the DLC. The location of neither site can be edited, so you're pretty much stuck with wherever they end up. The Woomerang launch pad at least snaps to the terrain, so elevation isn't really a problem. In GEP Woomerang ended up in the water, so I had to create an island for it. The desert site is more problematic because its elevation and map decal can't be changed. In both GPP and GEP it ended up in really inconvenient places and looked hideous (the map decal is enormous and looks like crap if ends up being anywhere other than on a large plain). There was just no way to fix it, so Thomas P. added an option to Kopernicus to allow us to remove it. Since you're not supporting the DLC, I assume you'll want to remove the Woomerang site as well. The code to remove both sites is: @Kopernicus { removeLaunchSites = Desert_Launch_Site, Desert_Airfield, Woomerang_Launch_Site If you wanted to, you could probably keep the Woomerang site even though you don't have the DLC. You'd just need to place a map decal for it, then it should work for those who have the DLC. I just used the KSC map decal and made it fit the site. You could probably use the same code and just change the absoluteOffset to make the decal match the elevation and contours of your terrain. Here's the code if you want to use it: MapDecal { name = Woomerang absolute = True absoluteOffset = 120 // change this to fit your terrain angle = 296 cullBlack = False DEBUG_HighlightInclusion = False heightMap = BUILTIN/ksc_decal_heightMap heightMapDeformity = 15 position = -0.5066573187, 0.7109222286, 0.4877375793 removeScatter = True radius = 700 useAlphaHeightSmoothing = True order = 170 enabled = True index = 0 }

@GrubbyZebra, I just did a flight to Mun and back and it's still working fine for me. Not sure what to say.

When you are getting the black sky, open the debug menu (ALT+F12) and see if you are getting NullReferenceException errors. The fix that I suggested was to get rid of the NRE errors. And when I fixed that, the black sky went away too. So I assumed both problems were caused by the same thing, but maybe not. I'm interested to know if the NREs come back along with the black sky. While trying to debug this problem, I also found a better way to write some of the scatterer configs. So we'll be soon releasing an update that changes quite a few scatterer configs. Maybe that'll fix the problem.

Yep, the constant updates from Squad are a real pain. I think many of the mod authors are dealing with update fatigue. I really hope that 1.4.4 is the end of it. (edit) I just heard that Squad has announced that 1.4.5 is coming. Will it ever end?

We are planning an update soon that fixes some bugs, but other than that, we've just reached a point where it's too difficult to make changes. Understanding and following the code logic is no longer a simple task. Integrating a change in one place can have unintended consequences that may result in hours of debugging. I think we have most of it working now, so I dread the thought of even making minor changes. Long story short, working on GPP is just not fun anymore.

GPP comes packaged with what it takes to make a Kerbol-Ciro binary system. Just install GPP along with the optional mod GPP_Secondary. This will place Ciro in orbit around Kerbol. However, Kerbin becomes the home world and only it will have launch facilities. I don't know if it's possible to place launch facilities on a body other than the home world. But even if it is possible, the GPP authors aren't doing it. Other than bug fixes, we're finished with GPP.

For those who have inquired about the problem of a black sky over Kerbin with some installations, I've found the cause and have a solution. I don't know when we'll be releasing an update, but in the meantime the fix is something you can easily do yourself. Find the file, GameData/GPP/GPP_Scatterer/Configs/Scatterer_PlanetList.cfg Open the file and scroll all the way down to the bottom until you see this: Item:NEEDS[OPM,GEP] = Robau Change the above line to the following and save: Item:NEEDS[OPM,GEP,!GPP_Secondary] = Robau

@GrubbyZebra, I think I've found the cause of the black sky problem. It ended up being something in GPP. I don't know when our next update is coming, but it's an easy fix that you can make yourself. Find the file, GameData/GPP/GPP_Scatterer/Configs/Scatterer_PlanetList.cfg Open the file and scroll all the way down to the bottom until you see this: Item:NEEDS[OPM,GEP] = Robau Change the above line to the following and save: Item:NEEDS[OPM,GEP,!GPP_Secondary] = Robau The problem was that scatterer was looking for the sunflare of a star that didn't exist.

You can get close. But it depends on what format image you are using, because different formats are flipped differently. I use .dds, which is flipped both vertically and horizontally (i.e. rotated 180 degrees) from what you see in game. If you use .png then they are flipped horizontally only. I believe you mentioned a .png image. So in that case the top of the texture is 90o north, and the bottom is 90o south (a .dds is reversed). Everything in between is linearly spaced. So if you are say, 1/4th of the way down from the top of the texture, that's corresponds to 45o N latitude. Longitude works pretty much the same way, but the prime meridian (0o longitude) is 1/4 of the way from left to right. So, for example, if you have a 4096x2048 texture, the prime meridian is located 1024 pixels in from the left edge. Also note that east and west are flipped from the normal map directions. The middle of the texture is 90o W longitude. Knowing this, you should be able to compute the latitude and longitude of any pixel in the texture, or vice versa. The computed location should get you close, but there will likely be some error. You'll probably have to fine tune it to get KSC located precisely where you want it.

Yes, but the variable F implies force. Your equation computes gravitational acceleration. Probably should write it, g = v2/r. But if you use the orbital velocity and radius to compute g, then the above equation will give the value of g at the orbital radius, not at the surface. What I would do is use the orbital velocity and radius to compute GM, GM = r v2 (Note that GM is a constant for a given body. For instance, for Kerbin GM = 3.5316E+12 m3/s2.) And then from that we can compute the acceleration of gravity at any radius using, g = GM / r2 If we want the surface gravity, then just set r equal to the radius of the planet. -------------------------------------- Note, however, that the equation GM = rv2 only works if we are in a perfectly circular orbit. If the orbit is elliptical, as it likely is, then we can compute GM using the Vis-viva equation, GM = v2 / (2/r - 1/a) where v is the orbital velocity at radius r, and a is the semimajor axis. The values v and r can be taking at any point along the orbit; and we can get a by averaging the minimum and maximum values of r.

@KSPrynk, GPP uses scatterer atmospheres when scatterer is installed, and EVE atmospheres when EVE is installed with no scatterer. What you are probably seeing are the EVE atmospheric effects. The configs for that are found in GPP/GPP_Clouds/Configs/. If you don't want GPP messing with the stock planets, you might try deleting the file EVE_StockAtmos.cfg and see what happens.