OhioBob

That's up to you to decide for yourself. Play which ever you prefer.

We won't know for sure what 1.8 does until 1.8 is released. But if things work as they do now, then JNSQ will override them. JNSQ completely deletes the stock planets and replaces them using its own textures.

Yes, my experience is that early career rockets typically require more delta-v to attain orbit than later rockets. 1.25-meter parts produce greater drag losses than the 2.5+ meter parts.* Also early rockets are often launched before fairings are available. While conventional wisdom says 3400 m/s is required for orbit, I usually figure at least 3600 m/s for 1.25m rockets, and even more if I have a draggy payload and no fairing. 4000 m/s may be overkill, but it's a wise precaution for somebody planning their first Mun mission. * It's not that 1.25-m rockets produce more drag, but because of their small size, they have less mass per cross-sectional area (i.e. a lower ballistic coefficient) than larger rockets. This means they have a large ratio of drag force to mass, so they are slowed down more by the drag they do produce in comparison to their larger cousins.

To be honest, I don't remember at what altitude it starts to exceed 1 minute. I've been playing scaled-up solar systems (when I do play, which isn't that much anymore); haven't played stock size in quite some time. I seem to recall that at 50+ km I'm still trying to keep it at <60 s. I usually throttle back at that point and slowly push the apoapsis up to my target altitude. I'm thinking it's more like 60-65 km before the time to apoapsis starts to grow, but I could be misremembering. Of course if the rocket is lofted into a steep arc with a large circularization burn, you're going to be cutting off the engine sooner and at a lower altitude. The fact I'm still burning at ~65 km is what happens when you minimize the circularization burn. It's not like it's a huge difference. I just know from past experience that, for a given rocket, my ascent is more efficient if my circularization burn is 100 m/s versus 500 or 1000 m/s.

That's very different from my experience. How much is needed for the circularization burn depends very much on the design of the rocket. But regardless of the design, I find that for any particular rocket, the smaller I can make the circularization burn, the less delta-v I use overall. I follow a standard set of guidelines for all my launch vehicles, therefore I get consistent performance and behavior out of all of them. When I fly them manually, I can often get the circularization down to 100 m/s or so. When I use an autopilot mod, like Gravity Turn, I can easily get it below 50 m/s. For some rockets, however, we may not be able to achieve numbers that low. I've had designs in the past where maybe a few hundred m/s was the best I could do. In pretty much all cases, the lower the circularization delta-v, the less fuel is used. If the circularization burn is large, then the rocket is being lofted into too steep an arc. The rocket is accelerating too much vertically and not enough horizontally. One of the most important things to keep an eye on is "time to apoapsis". I try to keep the time to apoapsis to not more than about 60 seconds. If the time to apoapsis starts to run away, pitch down, or even throttle back if necessary. Just keep the apoapsis slightly out in front of the rocket and slowly push it higher and higher. As you near the end of the burn, the time to apoapsis will start to rapidly increase, but that's OK at that point. Just don't let it get out of control during the mid part of the ascent. I find that high TWR rockets are much more difficult to control. The time to apoapsis often gets away from me and it becomes difficult to rein it in. I like a launch TWR of about 1.3-1.5. Of course that's just my personal preference, doesn't mean it's right. Of course there is also a limit to how flat you can make the trajectory. If too flat, drag will be too great and you may not get to orbit at all. I think there's a sweet spot where the trajectory is just flat enough to minimize gravity loses, and just steep enough to keep drag losses from getting out of control.

1542 m/s is about the minimum that it takes to reach Mun, resulting in about a 5-day cruise. It can be done quicker if you give it more delta-v. Proportionately the Kerbin-Mun system is about the same size as the Earth-Moon system. Apollo got to the moon in 3 days, you can too. To do that, Apollo didn't just raise it's apoapsis until it touched Moon's orbit. Had Apollo not intercepted Moon, it would have sailed on past and reached an apoapsis about 1.5 times the Moon's distance from Earth. This larger orbit was used to decrease the travel time. Had Apollo used a minimum orbit, it would have taken 5 days as well. (edit) Travel times to Mun are much longer in JNSQ than they are in stock because Mun was moved much farther away. Mun is unrealistically close to Kebin in stock. If it were really that close, the two bodies would be mutually tidally locked. In JNSQ Mun was moved to a distance determined realistic given the bodies sizes, rotation rates, and age.

Although I quoted you, I wasn't responding to you specifically. I was addressing the forum at large, and anyone who would benefit from what I said. You're not the only one reading.

What you call badgering I call trying to be helpful. Pointing out a simple helpful tip on how to measure the efficiency of one's ascent trajectory (minimizing circularization delta-v) is not "needless".

Sure, you can do all that. The developers, however, have no plans to write the configs for it. You'll have to do it yourself. You just have to install EVE along with JNSQ. https://github.com/WazWaz/EnvironmentalVisualEnhancements/releases/tag/EVE-1.4.2-2

That's not really a very efficient ascent. If your circularization burn requires 1000 m/s, then you're lofting the rocket into too steep an arc. You should try to flatten out the trajectory. I try to limit my circularization burn to about 100 m/s. Exactly how much you need is how much you need for the entire mission less how much the upper stages can deliver.

You should design the rocket as whole as required to complete the mission objectives. The first stage will end up with whatever it needs. Don't worry about trying to make it equal some specific number.

Just the initial release, v0.4.

Yeah, you're right. There are Kopernicus backports for 1.6.1 and 1.5.1, but not 1.6.0. Neither the 1.6.1 or 1.5.1 versions will work with KSP 1.6.0. There is a 1.6.0-1 version of Kopernicus that will work with your KSP, but it's not a backport. Unfortunately JNSQ will not work with the 1.6.0-1 version. The current JNSQ requires features introduced in later versions of Kopernicus (1.7.1+) that are only available in the backports.

No.

JNSQ v0.5 and later won't work with versions of Kopernicus older than 1.7.1. You have to either update to a newer version of KSP, or use a backport version of Kopernicus. JNSQ won't work with Kopernicus 1.6.1-2, but should with 1.6.1-9.

I can't say for sure, but I also have my doubts that GEP could be the problem. GEP isn't constructed any differently than any other planet pack.

It has been years since I last played RSS, but yes, it should have the same issue. Technically the moon is still tidally locked in that it completes one rotation per revolution. There just happens to be great deal of latitudinal libration due to the inclination between the moon's rotational axis and the normal to the plane of its orbit. Minmus in JNSQ has no ocean. I have no idea why you're getting that contract. You should probably decline it as there may be no way to fulfil the requirements.

@madindehead, regrettably I know nothing about either Contract Configurator or Field Research, nor how they interact with GEP. I haven't the slightest idea how to solve the problem.

No, this mod is strictly for the stock solar system. RSS, however, doesn't need it. The RSS atmospheres are already made to be realistic (I did them).

That's what I thought he might mean. @kerbnub, if that's what you're referring to, there's nothing that can be done about it. To have one face of a moon locked to the planet so that the planet has no (or little) north-south drift, then the moon must have no (or little) axial tilt relative to the axis of its orbit. In KSP we can incline the orbits, but we can't tilt the axes. So if we incline a moon's orbit X amount, it follows that the moon's spin axis will be inclined X amount relative to the orbital axis. There's just no way to get around it with the current KSP.

I don't understand, how is it not tidally locked anymore? I see nothing in the config that should cause Mun to be no longer tidally locked to Kerbin.

Below are the coordinates that Cartographer gives for Kerbin's highest point. I initially presumed it is the same mountain that @Snark is referring to, but this one is no where near Woomerang (Woomerang is at +45 latitude, not -45). Could we actually have two 14 km peaks? I was only aware of the one at the coordinates below. Highest Point LAT = -43.9625 LON = 103.9785 ALT = 14249.0251745675 EDIT I just extracted a Kerbin height map and checked it for the tallest mountain peaks. There is only one white pixel on the entire map, which is centered on approximately -44.033 latitude, +103.975 longitude. This is undoubtedly the peak located by Cartographer. There is another tall peak, though apparently not quite as tall, located at approximately +42.803 latitude, +140.449 longitude (near Woomerang). I think the second might be Snark's mountain (maybe he got the longitude wrong?). The coordinates above are limited by the pixel resolution of a 4k height map. The actually highest points will be nearby, but not precisely at the coordinates indicated.

@onlinegamesz, GPP is at a scale equivalent to stock. Although there are some very small differences, Gael is nearly a clone of Kerbin in regard to size, gravity and atmosphere. While the size of the other bodies vary, they are generally in the same size range as the stock celestial bodies. I have no idea about the Breaking Ground DLC stuff. GPP was developed and completed long before Breaking Ground was released, and nothing in GPP has been updated to accommodate it. I don't know how GPP or Breaking Ground will behave with both installed. ScanSat should work fine with GPP.

Dust storms are an EVE thing, not scatterer. Dust storms are not currently implemented in JNSQ.

Eve's sea level pressure is 10 atm in JNSQ. If you're planning to land near sea level, then I recommend using the 10 atm config. If you're planning to land at higher elevation, say greater than 2 km, then you're better off using the standard config.