OhioBob

You might try deleting settings.cfg before your next start up. I think Galileo may have made some changes that requires reselecting the Terrain Detail settings.

Just in case you didn't know, you can burn off all your ablator and still survive. All the ablator does is lower the temperature of the heat shield. When the ablator is gone, the temperature will jump up. But if you are still below the maximum allowable temperature of the heat shield, you'll be OK. In many cases you just need to have the ablator last long enough to get you past the period of maximum heating. Once the heating has begun to subside, the ablator can run out and you'll usually be alright (except for extreme cases).

In that case, something is definitely screwed up in your installation. Sounds like you still have stock Kerbin. Did you install Kopernicus? You should definitely not load into JNSQ a game started prior to installing JNSQ. JNSQ is a complete overhaul of the stock system, so anything from an old game will almost certainly not be compatible with JNSQ. If you plan to play JNSQ, you should start a new game after installing it.

I get to orbit using ~4900 m/s all the time. Sometimes a little more, sometimes a little less. But 4900 is a good median. What do you use?

It's only under certain conditions that the bug prevents science transmission. So the fact that you could doesn't necessarily mean it's been fixed. But I admit I haven't checked it, so maybe it has. I'll run some tests before our next release to see if I can verify one way or another.

That's what we've done in the new release. You're looking at outdated information. From the JNSQ Readme: * When starting new saves under JNSQ, we advise that you enter Difficulty Settings and raise the DSN modifier to 4x. JNSQ applies a patch to increase antenna range by 4x, so leave the range modifier at 1 (changing it triggers a bug that may prevent science transmission).

To fix the lag issue when switching to map view, try this: @Kopernicus:FINAL { useOnDemandBiomes = False }

The following page explains most of the math. Specific to your questions, look at the section Position in an Elliptical Orbit. http://www.braeunig.us/space/orbmech.htm

The exhaust plumes are the least of my concerns, but I thought I'd mention it. The integrated segments, however, needs a look. I did see the thrust change in the KER readout when swapping nozzle in the VAB, but not in flight mode. And I don't think the mass changed in either VAB or flight mode. I also did a flight test with both nozzles and saw no difference in performance between them.

@linuxgurugamer, I just ran a bunch of tests and most things seem to be working. As long as something is attached to the top it works fine; with nothing the exhaust escapes from both top and bottom. Here are some issues that I see: The long nozzles are suppose to include an integrated fuel section, but I see no difference between long and short. The in-flight KER readout shows the same mass and thrust with either. When using the long nozzle, the in-flight KER readout shows a specific impulse of 0.0s. Some of the exhaust plumes seem to be off a bit. They generally look to me like they start too high up on the booster.

Hopefully that will fix it. Because I just ran a test and was about to report that the problem is the same with or without a nosecone. I'll test again with the dependency.

Interesting. I haven't experienced that issue. All my reentries have gone without incident. I don't know if I'm lucky or good. (edit) I take it back, I did have one bad incident. One of my spacecraft had a part that wouldn't jettison due to a clipping issue. I had to reenter with the part attached, which made the vehicle aerodynamically unstable. The reaction wheels weren't strong enough to hold it retrograde and it flipped on me. Blew up almost instantly. And this was a low orbit reentry.

Congratulations on the release. I'll have to check it out. (edit) I'm experiencing the same issue as described by @ddavis425.

Try this... Find the file OPM_KopernicusSetting.cfg and edit it by adding the line shown in red below. This solved a lag problem in JNSQ. Might not work for OPM but it's worth a try. @Kopernicus:FOR[OPM] { useManualMemoryManagement = True useOnDemandBiomes = False }

I usually set my periapsis at around 35 km (as I recall) without any problems. All the ablator burns off, but by the time it does the heating rate has diminished to the point that the ablator-less heat shield can handle it. What happens with a high periapsis is that the vessel spends too much time skimming through the thin upper atmosphere. The thin air is enough to heat it up but not enough to slow it down very much. The peak heating rate in this case is not extreme, but you are absorbing heat for a long time without really slowing down. After all the ablator has burned away, the vessel is still going fast enough to produce a high heating rate. If the temperature rises above the maximum safe temperature of the remaining heat shield, the vessel will blow up. When you use a lower periapsis you are forcing the vessel into thicker air where it will experience greater drag. The heating rate (and g-load) will peak more sharply, but you'll slow down quicker. As long as the peak temperature stays below the maximum that the vessel can handle, you'll be OK. The vessel will still burn off all its ablator, but by the time the ablator is gone the vessel is traveling slow enough that the heating rate is much reduced. The temperature of the heat shield will spike up as soon as the ablator is gone, but the spike will remain below the maximum safe temperature of the heat shield.

Technically the correction burn shouldn't be done at the midway point. It should be done when the vessel is 90 degrees away from the arrival point. If a plane change is needed to intercept the target, it can be done most efficiently at this point in the orbit.

You should be able to add in OPM at any time without it disrupting anything you were doing in the stock system. The only exception is Eeloo, which OPM moves. So it you have a spacecraft in route to Eeloo, it will be headed to nowhere once OPM is installed.

It's listed in the delta-V map. About 1975 m/s.

GEP 1.0.1.5 should work fine with GPP and KSP 1.7.3, but I don't know about the scatterer configs. If when you get to Grannus you find that the scatterer atmospheres are messed up, you may need to roll back to GEP 1.0.1.3.

Really? GEP 1.0.1.5 configs are written for scatterer 0.0540. I didn't think they were backwards compatible.

To be honest, I don't remember. So much has changed recently that I've lost track. It might not work. I know Kopernicus implemented some big changes with, I think, version 1.7.1. You might have to roll back to KSP/Kopernicus 1.7 or earlier for GPP to work. The latest GEP definitely works with the current KSP, but GEP has been upgraded, GPP has not.

GPP is supposedly on CKAN, but GEP is not. I don't use CKAN myself, so I can't help with that. However, there's no reason that I know of that should keep you from using GPP_Secondary and GEP. Be advised, however, that GEP has been updated for the most recent scatterer and Kopernicus, while GPP has not. Some of those changes are not backwards compatible. So if you want to use scatterer with GPP, you have to use an old version of scatterer (v0.336 as I recall). And if you want to use GEP with GPP/scatterer, you have to use an old version of GEP that's compatible with the old scatterer (v1.0.1.3). To use GPP_Secondary and GEP, your GameData folder should include the following: GEP GPP GPP_Secondary Kopernicus ModularFlightIntegrator ModuleManager GPP_Secondary is included in the "Optional Mods" folder of the downloaded zip file.

Biomes are something that is not yet fully developed in JNSQ. Duna specifically need some love. You're right, it only has the four basic biomes at the moment. Thanks for the reminder, we need to work on that.

Correct, it is not.

As Snark said, it really doesn't matter as far as completing the contract goes. I wouldn't even worry about when it comes to contracts. But if you really want to know where zero longitude is just to satisfy your curiosity, it seems to be just some random direction. Kerbin doesn't have a vernal equinox, so we can't use that, or anything else like it, for reference. However, we can located 0 longitude using the positions of Kerbin and the Sun at specific times of year. Kerbin is located at 180 degrees longitude on Day 1, 00:38:53 of every year, and is located at 0 longitude on Day 214, 00:55:05 of every year. So whenever the clock reads "Day 1 - 0h39m", a line drawn from Kerbin to the Sun points in the direction of 0 longitude. And when the clock reads "Day 214 - 0h55m", a line drawn from the Sun to the Kerbin points to 0 longitude. (EDIT) I have to make a correction. The specific times that I cited apply only to Year 1. If Kerbin's year consisted of an exact number of integer days, then those times would reoccur every year. But since Kerbin's sidereal year contains a fractional day (1 year = 426.09 days), each new calendar year begins with Kerbin in a slightly different part of its orbit than the year before. It take an extra 32.41 minutes each year to get back to its staring place. So Kerbin doesn't reach 180 longitude on Year 2 until Day 1, 01:11:17, and the time continues to advance each year.