OhioBob

There has often been rumors of suicide pills, but I've heard several astronauts flatly deny that that was the case.

They actual began deviating from a free return trajectory starting with Apollo 12. Apollos 8, 10 and 11 all flew free return trajectories, but this type of trajectory was very constricting on the lunar area that would be accessible for exploration. Starting with Apollo 12, NASA started using hybrid trajectories. With a hybrid trajectory the spacecraft was initially injected into a trajectory that retained all the characteristics and safety features of a free return. But after the spacecraft separated from the launch vehicle and the propulsion system was checked out, a mid-course maneuver was performed to place the spacecraft on lunar approach trajectory that was no longer a free return. One of the problems with Apollo 13 was that at the time of the accident the mid-course maneuver had already been completed. The first burn that had to be perform was to place Apollo 13 back onto a free return trajectory. As I recall, Apollo 13 performed three burns total using the LM's descent engine: (1) to place them back on a free return trajectory, (2) the PC+2 burn to pick up speed and shorten the journey, and (3) a burn to correct the entry corridor.

Alter the mean anomaly at epoch. That's the variable that tells us where a satellite is in its orbit, it's mean anomaly, at the specified epoch. Mean anomaly is measured in radians, where 360 degrees = 2*pi radians. So let's say you want to space four satellites out 90 degrees apart, place them at mean anomalies of 0, 1.5708, 3.1416 and 4.7124, making sure the epoch is the same for each.

If I were you, I'd just do a complete GPP reinstall.

I don't know which mod does the best job because I don't use them all, so I don't have a basis for comparison. However, I sometimes use Gravity Turn. It allows each new launch to learn from the prior one to eventually zero in on a very efficient ascent. I think it does a pretty good job.

You don't need a "command pod" on everything, only on stuff that will carry a crew. The answer as to why you need one should be pretty obvious, the Kerbal needs a habitat with life support and all the controls and instrumentation needed to fly the ship. For vessels not carrying a crew we need a "probe core". The probe core is the brains of the spacecraft. In real life every spacecraft requires on onboard computer (often referred to as the command and data subsystem) that is overall responsible for the management of the spacecraft's activities. It maintains timing, interprets commands from mission control, collects, processes and formats telemetry data, and manages fault-protection and safing routines. I've always presumed that the probe core is the spacecraft computer.

If you're a probe guy, then maybe you should try this... I've seen several threads like this, and the thing I've noticed about tech trees it that that everyone has an opinion and nobody's opinion is the same. Somebody will come along and argue that "it's just common sense" that the tree should be arranged in some particular fashion. The next guy will come along and say the same thing but will propose something completely different. If it were so obvious that the tree should be arranged in some specific way, then everybody would agree, but they don't. It's all depends on a person's particular style of play, and there's nearly are as many different styles as there are players. That's why I proposed you consider rearranging the tree yourself. The chances that there's an existing tech tree out there that does exactly what you want is probably remote. If a particular tree doesn't look the way you think it should, that doesn't make it wrong, it just makes it different.

Although that may be generally true for most mods, Kopernicus is version locked. It simply will not work if the versions don't match. This is by design.

Just be sure that the Kopernicus version number matches the KSP version number. For instance, if you're using KSP 1.3.1 then you must use one of the 1.3.1-x Kopernicus versions. It won't work if the version numbers don't match.

https://github.com/Kopernicus/Kopernicus/releases/

I think the intended use of the Dart is probably for a SSTO. The real advantage of an aerospike is that it gives good performance over a wide range of ambient air pressures, i.e. both sea level and vacuum. This advantage isn't all that obvious in stock KSP because the delta-v requirement to get to orbit is so low - we're not really penalized much for using a different type of engine. But in real life, where is takes three times as much delta-v to reach orbit, the advantage is more apparent. An aerospike can burn from liftoff all the way to orbit while providing good ISP the entire way. A bell nozzle can't do that - at some point during the ascent it's going to be performing suboptimally.

The change was actually introduced back in Kopernicus 1.3.0-5, but it had a glitch in it. Version 1.3.1-3 simply fixes the glitch to make it work the way it was originally intended. I learned of the change a month ago and fixed GPP proactively so that verison 1.5.88 would work with the new Kopernicus. GPP 1.5.88 should work with Kopernicus 1.3.1-2, but older versions of GPP will not work with Kopernicus 1.3.1-3. If you are using Kopernicus 1.3.1-3, you must use GPP 1.5.88.

I've never used anything other than the stock tech tree, so I can't recommend any alternatives. But even if there are others, that doesn't mean you'll be happy with them either. It's very unlikely that somebody else is going to share your vision of what the tech tree should be. It's very easy to move items from one technology to another, so why don't you considering customizing it just the way you want it. All you have to do is install ModuleManager and write a .cfg file that changes the required technology for the parts that you want to move. A sample cfg might look something like that below. You just have to look up the names of the parts and technologies by looking through the existing .cfg files in the GameData/Squad/Parts/ folder. After you're finished, just place the cfg anywhere inside the GameData folder. The next time you start a career game, all the parts will be moved to the new techs. @PART[longAntenna] { @TechRequired = engineering101 } @PART[mediumDishAntenna] { @TechRequired = precisionEngineering } @PART[commDish] { @TechRequired = automation }

The following thread provides a little more explanation about sunlight intensity curves. Kopernicus 1.3.1-3 fixed all the bugs, so the curves are now working as they should.

Do what the instructions say. Install, Kopernicus (including ModularFlightIntegrator and ModuleManager) RSS (RealSolarSystem folder only) RSS Textures Sigma Dimensions SSRSS Kronometer Although RSS by itself is not up to date for KSP 1.3.1, SSRSS uses its configuration files. You must install the RealSolarSystem folder from the RSS download.

Thanks, @Sigma88. You're solution works great. I'm just sorry I had to waste a couple hours chasing down the source of the problem. I don't know if it's the source of your problem or not, but I just noticed another error in your config. timewarpAltitudeLimits requires 8 values, you have only 7.

I've got a problem that just doesn't make a lot of sense to me. I've got one body in an eleven body planet pack that won't create a cache file. The body loads up in the game just fine and everything looks OK, but I get only 10 out of 11 .bin files in my cache folder. This one body just refuses to produce a cache file. Its cfg is essentially identical to the others. In fact, I tried recreating the cfg from a copy of one of the others that is known to work, but still no cache file. All the logs look good from what I can tell. The only difference that I can see in any of the logs is that the Kopernicus logs for the bodies producing cache files include the following, [LOG 23:21:19]: Brovo is using custom cache file 'C:/Program Files/Kerbal Space Program 131 GPP 1588 GEP/KSP_x64_Data/../GameData\GEP/Cache/Brovo.bin' in 'C:/Program Files/Kerbal Space Program 131 GPP 1588 GEP/KSP_x64_Data/../GameData\GEP/Cache' [LOG 23:21:19]: Body.PostApply(ConfigNode): Loading cached scaled space mesh: Brovo while those lines are missing from the log for the body for which I'm having the problem. Does anybody have any ideas on what could be causing this problem? Help please. (edit) Here's a new test I just tried. I took one of the working cfgs and made a copy of it with a new file name. I then made minimal edits to the file, changing only the body name, the cache file name, and the referenceBody. With those changes only, it produced a cache file. I next made additional edits to the "Properties" node; changing description, radius, geeASL, initialRotation, and timewarpAltitudeLimits. I then deleted the cache file and restarted. With these additional changes, no cache file was generated. When I reverse those changes and go back to the previous properties settings, the cache is again generated. How can those few simple edits to the Properties affect whether or not a cache file is generated? (edit #2) OK, I've isolated the problem to the radius, and I'm pretty sure I know now what's happening. By coincidence my body's radius just happens to be exactly the same as the template. As long as I use a radius that's different from the template, I get a cache file. But when the radii match, no cache file is generated. Is that intended behavior? Should no cache file be generated when the planet radius matches that of the template? I can say from my experience here that my body doesn't look right when no cache file is generated. It looks much better when I force Kopernicus to generate a cache (by changing the radius just a little bit). I suggest that you edit your code to force the generation of a cache file even when the radii match.

My first advice is to use the most up to date versions of everything. It ought to work with the new versions, so using outdated stuff isn't really helpful. Install the most current versions and then provide the information requested by Galileo. Someone should then be able to figure out what you're doing wrong.

Oceans will always be at zero elevation because its the datum that defines the ocean surface. (Though there are OceanHeight and OceanDepth parameters that I don't know what they do. Perhaps if those are set to non-zero numbers it would change the elevation of the ocean surface.) If the surface is generated entirely by a heightmap, and if the darkest color in the heightmap is pure black (0,0,0), then the lowest surface elevation will be zero. If the darkest color in the heightmap is some shade of gray, then the lowest surface elevation will be >0. If PQS mods are used to generate the surface, then the lowest point could be almost anything, positive or negative. If the planet maker wants the low point to equal zero, then they have to find where the low point is, measure its elevation, and apply on offset to bring that point to zero. I actually did that on an early version of GPP, but then one of the Kopernicus updates changed something that altered the elevations and messed it all up.

That's not necessarily the case unless the planet maker took special care to make sure it's the case. It may be true for the stock bodies, though I don't know if anyone has ever verified that. For non-stock planets, you can't assume the datum is located at the lowest point on the surface. The elevation of the surface in relation to the datum depends on how the terrain is generated. Placing the datum at the low point may require that the offset be manually adjusted.

@suomynonA, what's this? Is that path correct? Why is it not using the GameData folder? texture = AdvancedExploration\Ringo\PluginData\Ringo_color.dds

@Galileo, @JadeOfMaar, we probably need to add this somewhere in the instructions. It says it in the Rescale! instructions, but I doubt most people will read that far. As far as the GPP instructions go, it should probably go under either the KSC++ heading or the Scaled Version heading, or maybe both. Something like this: KSC++ 2. If KSC++ in used combination with a one of the scaled versions of GPP, the third-party mod KKtoSD must be downloaded and installed. Scaled Version 2. If one of the scaled versions of GPP is used in combinations with KSC++, the third-party mod KKtoSD must be downloaded and installed.

I'm currently using GPP, but I was previously using stock + OPM. While I thought OPM was a nice mod and I liked having the outer planets as part of the solar system, I never got around to launching a single mission beyond Jool, mainly for the reasons you explain. I still had stuff going on in the inner solar system that I didn't want to abandon just to time warp ahead the years needed to get to the outer planets. I tend to agree with you... If a person wants to undertake a serious exploration of the OPM planets, they really need to forget about everything else and just focus on that. The same thing is true of the outer planets in GPP. Otho is GPP's Jool as far as distance and travel time is concerned. Visiting the planets beyond Otho presents the same problem as the OPM planets.

There's a lot of math here, but you can also take a look at this... http://www.braeunig.us/space/interpl.htm#gravassist

@suomynonA, I think I found the problem. The following is a partial copy of your planet cfg: @Kopernicus:AFTER[Kopernicus] { Body { name = Ringo cacheFile = Ringo/Cache/Ringo.bin Template { name = Laythe removeAllPQSMods = true } Properties { description = Likely candidate for habitation radius = 5737010 geeASL = 0.96 isHomeWorld = false tidallyLocked = false rotationPeriod = 57600 timewarpAltitudeLimits = 0 5000 20000 35000 50000 100000 300000 ScienceValues { landedDataValue = 7 splashedDataValue = 2 flyingLowDataValue = 1 flyingHighDataValue = 1 inSpaceLowDataValue = 6 inSpaceHighDataValue = 5.25 recoveryValue = 6 flyingAltitudeThreshold = 50000 spacealtitudeThreshold = 400000 } } } ScaledVersion { ... The close bracket right above ScaledVersion closes the Body node. ScaledVersion and everything that follows must be inside the Body node. Remove the close bracket right above ScaledVersion and replace it with one at the very end of the file. I also don't know what's up with your Atmosphere node, but it has massive amounts of unneeded tabs and/or line breaks. I don't know if that's messing anything up or not, but it probably should be cleaned up. Below is a cleaned up version of your atmosphere code if you want to use it. Atmosphere { ambientColor = 0.4,0.4,0.5.1.0 lightColor = 0.4,0.5,0.6.1.0 altitude = 79000 enabled = true oxygen = true temperatureSeaLevel = 275 temperatureCurve { key = 0 273 0.00000E+00 -2.64000E-03 key = 12500 240 -2.64000E-03 -3.20000E-03 key = 25000 200 -3.20000E-03 -2.40000E-03 key = 37500 170 -2.40000E-03 -1.60000E-03 key = 50000 150 -1.60000E-03 -6.00000E-04 key = 75000 135 -6.00000E-04 -4.00000E-03 key = 80000 115 -4.00000E-03 -1.87500E-03 key = 88000 100 -1.87500E-03 0.00000E+00 } temperatureSunMultCurve { key = 0 1 0.00000E+00 -6.00000E-05 key = 20000 -0.2 -6.00000E-05 1.33333E-05 key = 50000 0.2 1.33333E-05 0.00000E+00 key = 60000 0.2 0.00000E+00 -5.00000E-06 key = 70000 0.15 -5.00000E-06 -5.00000E-06 key = 80000 0.1 -5.00000E-06 -2.50000E-06 key = 88000 0.08 -2.50000E-06 0.00000E+00 } temperatureLatitudeBiasCurve { key = 0 13.99 0 -0 key = 38 0 -0.7092 -0.7092 key = 90 -52.01 -1.1519 0 } temperatureLatitudeSunMultCurve { key = 0 5 0 -0 key = 38 4.36 -0.0322 -0.0322 key = 90 2 -0.0524 0 } temperatureAxialSunBiasCurve { key = 0 -0.49 -0.006 -0.006 key = 35 -0.6 -0 -0 key = 125 -0 0.0105 0.0105 key = 215 0.6 0 0 key = 305 0 -0.0105 -0.0105 key = 360 -0.49 -0.006 -0.006 } temperatureAxialSunMultCurve { key = 0 0 0 0 key = 38 0.5 0.02 0.02 key = 90 1 0 0 } temperatureEccentricityBiasCurve { key = 0 3.82 0 -7.64 key = 1 -3.82 -7.64 0 } pressureCurve { key = 0 6.75838E+01 0.00000E+00 -1.07907E-02 key = 3000 4.15609E+01 -6.83774E-03 -6.83774E-03 key = 6000 2.51810E+01 -4.27159E-03 -4.27159E-03 key = 9000 1.50171E+01 -2.62929E-03 -2.62929E-03 key = 12000 8.80550E+00 -1.59304E-03 -1.59304E-03 key = 15000 5.06343E+00 -9.53362E-04 -9.53362E-04 key = 17000 3.45620E+00 -6.69500E-04 -6.69500E-04 key = 20000 1.90825E+00 -3.86379E-04 -3.86379E-04 key = 23000 1.02570E+00 -2.17044E-04 -2.17044E-04 key = 26000 5.35978E-01 -1.18300E-04 -1.18300E-04 key = 29000 2.73194E-01 -6.24883E-05 -6.24883E-05 key = 31000 1.71942E-01 -4.03063E-05 -4.03063E-05 key = 34000 8.39789E-02 -2.04499E-05 -2.04499E-05 key = 37000 3.98684E-02 -1.01011E-05 -1.01011E-05 key = 40000 1.84276E-02 -4.80753E-06 -4.80753E-06 key = 43000 8.33464E-03 -2.23556E-06 -2.23556E-06 key = 46000 3.68523E-03 -1.01714E-06 -1.01714E-06 key = 48000 2.11067E-03 -5.94061E-07 -5.94061E-07 key = 51000 8.96675E-04 -2.58409E-07 -2.58409E-07 key = 54000 3.75967E-04 -1.09552E-07 -1.09552E-07 key = 57000 1.56114E-04 -4.60020E-08 -4.60020E-08 key = 60000 6.41810E-05 -1.91281E-08 -1.91281E-08 key = 62000 3.52835E-05 -1.05981E-08 -1.05981E-08 key = 65000 1.42552E-05 -4.33283E-09 -4.33283E-09 key = 68000 5.69707E-06 -1.75254E-09 -1.75254E-09 key = 71000 2.25155E-06 -7.01115E-10 -7.01115E-10 key = 74000 8.79692E-07 -2.77337E-10 -2.77337E-10 key = 76000 4.65189E-07 -1.51718E-10 -1.51718E-10 key = 79000 0 0 0 } }