OhioBob

It interacts perfectly fine with rescales. But how well the rescaled atmospheres behave in game is a function of how good your rescale settings are. For 10x I would recommend something like, @Atmosphere = 1.25 @atmoTopLayer = 1.6

I've never really experienced much problem in JNSQ as long as I use a heat shield. Of course re-entry heating is adjustable via a slider in the game difficulty settings. I usually keep it at 100%. If you have it turned up to more than 100%, that may be the problem. I recommend adjusting the slider rather than changing the heat limits of the parts. With the heat at 100%, I find that reentry from low orbit doesn't even need any ablator, just a heat shield. Heat shields have a max temperature of 3300 K, which is higher than a typical low orbit reentry. So as long as the shield takes the heat and not something else we should be fine. We need ablator only when the max temperature without it will exceed the 3300 K limit of the heat shield. Reentry from high orbit, such as a return from Mun or Minmus, will probably exceed 3300 K, therefore ablator is needed. Ablator lowers the temperature of the heat shield. For example, a heat shield that would reach 3300 K without ablator might only reach 2800 K with ablator. FYI, we don't necessarily need ablator to last the entire reentry. It just needs to last long enough to get beyond the critical phase. When the ablator runs out the heat shield temperature will suddenly increase, but as long as it stays below 3300 K we'll be fine. I usually adjust the ablator mass down if I don't need it all. I use to have some rules of thumb for how much ablator I needed for different missions, but I don't really remember them. The only one I seem to recall is for reentries from Mun and Minmus in stock KSP. I think I use to set the ablator mass to 5% of the reentry vehicle's mass. For example, if the vehicle was 2000 kg I'd set the ablator to 100 kg.

Just copy and paste those lines into a text editor, like Notepad, and save it as a txt file. Change the extension from .txt to .cfg. Then just place the file anywhere inside the GameData folder. There may be but I have no idea what it is. Yes, everything orbits Kerbol. I don't think there's anyway to have something in a stationary position, but at the distances we're talking about, the orbital period would be many thousands of years. It would be moving but very very slowly.

You can move Grannus farther away. Just add the following patch and change the multiplier to whatever you want it to be. @Kopernicus:AFTER[GEP] { @Body[Grannus] { @Orbit { @semiMajorAxis *= 10 // a multiplier that can be whatever value you want } } }

If it happened in the stable release but not the bleeding edge version, then it may be an issue with Kopernius. Perhaps you should report the problem to the Kopernicus devs.

The link is the correct Kopernicus, I don't know what's causing your freezing problem, it could be anything. Best thing to do is remove all your mods except the minimum required for GPP: GPP Kopernicus ModularFlightIntegrator ModuleManager Then test it to see if it works. If it does, then the problem likely isn't GPP or Kopernicus. Add your mods back until you figure out which one is causing the problem.

No plans at the moment because we haven't discussed it.

Ore is randomly placed for every new game, so a map would be useless.

There may be future updates, but not because of any particular KSP version. The current version of GPP should work with KSP 1.11.1, provided you are using the correct Kopernicus.

As far as I know, nothing requires updating.

This is the first time I've heard of that problem. It has never happened for me.

I have no idea what the problem/solution is.

Ciro's semimajor axis in GPP_Secondary is 7 billion kilometers. If you want to raise it higher, you can add the following patch to apply a multiplier. In this example I've doubled Ciro's distance, but you can make the multiplier whatever you want it to be. @Kopernicus:AFTER[GPP_Secondary] { @Body[Ciro] { @Orbit { @semiMajorAxis *= 2 } } } @Starhelperdude, if you really want Grannus to orbit Kerbol rather than Ciro, that can be done with a patch as well, but there's nothing already written to do that. You would have to invent the new orbital elements yourself. Just add the following and fill in all the missing values. @Kopernicus:AFTER[GPP_Secondary] { @Body[Grannus] { @Orbit { @referenceBody = Sun @inclination = @eccentricity = @semiMajorAxis = @longitudeOfAscendingNode = @argumentOfPeriapsis = @meanAnomalyAtEpoch = } } }

Your best option would be to install GPP_Secondary, which comes with GPP in the Optional Mods folder. You GameData folder should include the following: GEP GPP GPP_Secondary MPE OPM What will happen is this: The OPM and MPE bodies will orbit Kerbol, Ciro will orbit Kerbol, and Grannus will orbit Ciro. And, of course, the GPP and GEP planets will orbit Ciro and Grannus respectively. The only change you might notice is the apoapsis of Soden from MPE is significantly reduced to keep it from entering the sphere of influence of Ciro. No, that option doesn't exist.

It is not required. To play without it, just omit the RationalResources folder.

The first thing we must be able to do to travel interplanetary is to recognize when the time is right to launch our mission. The time when a mission can be launched is called a launch window. Launch windows occur at periodic intervals when the planets are correctly positioned relative to each other. For instance, launch windows to Duna occur about every two years. For a typical interplanetary mission, we attempt to intercept the target planet when it is approximately 180 degrees from that launch point. That is, let’s say we have a clock face with the Sun located at the center, and Kerbin located at the 6:00 position. Our spacecraft will travel around the Sun counterclockwise and intercept the target planet near the 12:00 position. (In practice the intercept point will likely be somewhere between 1:00 and 11:00, but as close to 12:00 as possible.) For this to work, it is vitally important that the target planet be located at the 12:00 position when our spacecraft arrives there. To make this happen, we must launch when the target planet is in a specific location relative to Kerbin. For an inner planet, such as Eve, we must launch when the target planet trails Kerbin in its orbit. This is because the inner planet is in a smaller orbit and is traveling faster than the spacecraft. So in the time that the spacecraft travels 180°, the inner planet will travel more than 180°. Let’s say that in the time it takes the spacecraft to travel 180° the planet travels 225°. In that case we must launch when the planet is 45° behind Kerbin in its orbit. In other words, when the planet is at the 7:30 position on the clock face. For an outer planet, such as Duna, we must launch when the target planet leads Kerbin in its orbit. This is because the planet is orbiting more slowly than the spacecraft and will sweep through a smaller angle than the spacecraft during its cruise phase. Let’s say that in the time it takes the spacecraft to travel 180° the planet travels 135°. In that case we must launch when the planet is 45° ahead of Kerbin in its orbit. That is, when the planet is at the 4:30 position. The angle between Kerbin and the target planet at the time of launch is called the phase angle. For Eve and Duna, the correct phase angles are roughly -45° (behind Kerbin) and +45° (ahead of Kerbin) respectively. Unfortunately those numbers vary because the planets’ orbits aren’t perfectly circular. The orbital speeds of the planets vary, as does the distance the spacecraft must travel to reach the intercept point. Therefore the phase angle may be more or less for a specific launch window. Using the phase angles above should be close enough to get an intercept with the target planet, but it may not be the most efficient transfer. Calculating the exact phase angle for a specific launch window is more complicated than I care to explain here, but if you want to know more about it, additional reading is available here (warning - lots of math): http://www.braeunig.us/space/interpl.htm The easiest way to determine launch windows and phase angles in KSP is to use the mod Transfer Window Planner, or its online version here: KSP Launch Window Planner by alexmoon.

That looks much better. I noticed that things looked a bit off on some of your earlier screenshots as well, but I thought maybe it was because of KS3P. I have no experience with that mod so I didn't know what to expect. But after seeing the Brovo screenshots it was clear that the bump maps weren't working. Yep, I linked to the wrong one. I've fixed it, but you already found it on your own. Fixing the "farm patch" bug is the original reason for the patch. I had pretty much forgotten about the problem of the bump maps not working until I was reminded after seeing your screenshots. I figured it was probably part of the same problem that the patch was designed to fix. I just never connected those dots before now. Belisama uses the same template as Brovo, so it's likely you'd see problems there as well. (In fact, all bodies but Grannus, Sirona and Nodens use the same template) I doubt Kittopia is the problem. There was a time when some of us were doing some testing and it looked like Kittopia might be the cause, but I don't believe that anymore.

@GEPEG_Unconscious, something doesn't look right with your terrain textures. I believe the bump map isn't working. This is something that I often had trouble with when I was converting all the textures over to using the new shader. The screenshot below is what the terrain should look like: I never completely figured out what caused it, but I have some ideas. First, what version of KSP are you using? In some of the older versions there was an issue with the shader not working on certain planet templates. If you're using v1.8.1, this problem would affect Brovo. There's a patch that should fix it (if you haven't already installed it): https://www.dropbox.com/s/wom007ur6bw0hqy/GEP_Patch_011020.zip?dl=0 Another thing that was suspected as being the culprit was having KittopiaTech installed. If you have that installed, I recommend removing it.

Knowing when to do it is the first step in knowing how to do it.

Gravity Turn ceases to control the vehicle as soon as these two conditions are met: (1) the target apoapsis has been attained, and (2) the vehicle is out of the atmosphere. Therefore, it does not perform the circularization burn at apoapsis. Of course that's pretty easy to do yourself. I generally use Precise Maneuver - just place a maneuver node, click the AP button, then click the Circularize Orbit button. All you then have to do is perform the burn when you get to the node.

If I can't talk about transfer windows, there's no answer I can give you. The key to getting anywhere is performing the transfer at the correct time.

It's unlikely that it requires updating. It should work fine as is.

UPDATE Version 1.2.3 Changelog Changed starting position & rotation of Nodens and Belisama. Deleted MyRocksAreBiggerThanYours.dll. Fixed error in GEP_CommNet.restockblacklist. See opening post for download link and instructions. Since the last update (v1.2.2) changed the calendar to have months based on the orbit of Nodens' moon, it makes sense that each month begins at the start of a new lunar cycle. Therefore, the starting positions of Nodens and Belisama in their orbits have been changed so that a new moon occurs on the first day of each month. This also required a change in the initial rotations so that each body keeps the same face pointed toward the other. Also note that the new moon at the start of each new year produces a total solar eclipse (though it's only a partial eclipse when observed from KSC). Beware that this change could break existing saves. Potential problems include: (1) spacecraft currently on the way to Nodens or Belisama will result in a miss, (2) the date and time of future launch windows will change, and (3) the terrain beneath geosynchronous satellites will change. If you fear any of these problems, then I suggest you do not update until you are sure you can do so safely.

I believe so.

You can also download the master. I typically don't recommend doing that as the master is not an official release and could include stuff not for public consumption. But in this case I've found that I can unzip the master without any problems. Just click the following link, then click the green "Code" button, then click "Download ZIP" Profiremu23/RescaleContinued (github.com)