OhioBob

It's not large variation, but there are seasons in GEP. It's because the ecliptic in GEP is tilted 10 degrees, so most of the planets have about a 10° tilt relative to their orbits. On Toutaits the temperature varies about ±10 °C at the poles, less at lower latitudes.

That sounds about right. The temperature will vary depending on several factors: solar zenith angle (how far the sun is from the zenith), elevation, and season (yes, Toutatis actually has seasons). Most significant is the solar zenith angle. On average you should expect temperatures to be about the following: Solar zenith angle = 0 (sun directly overhead) ---> Temperature ≈ 440 K (167 oC) Solar zenith angle = 45 ---> Temperature ≈ 390 K (117 oC) Solar zenith angle = 90 (day-night terminator) ---> Temperature ≈ 270 K (-3 oC) Solar zenith angle = 135 ---> Temperature ≈ 150 K (-123 oC) Solar zenith angle = 180 ---> Temperature ≈ 100 K (-173 oC) Of course you could read more or less depending on elevation and season. If HeatShifter isn't installed, or is not working, then all the temperatures will be shifted 45 degrees.

Epona - first planet past the gas giant Sirona.

Here are some screenshots highlighting some of the terrain updates from v1.1.5.

I've never used KS3P so I know nothing about it. GEP is using the same shader and textures used on the stock bodies. I just repurposed them and used them on the GEP bodies. I wonder if the issue you are seeing occurs in stock?

Excellent. I wondered if you had upgraded to 1.8.1. I recall you saying in the OP that you were using 1.7.3. Good timing indeed.

@GEPEG_Unconscious, you might be interested in this...

UPDATE Version 1.1.5 Changelog Upgraded to use shader introduced in KSP v1.8. New and improved terrain textures for all celestial bodies. Bundled Sigma TweakChutes and HeatShifter. See opening post for download link and instructions. This release works only with KSP v1.8.1 and later. Continue using GEP 1.1.3 for KSP 1.7.3 and earlier.

Kopernicus won't work without it, so your planet pack won't load. I think you'll just get the stock solar system. I think the date on the files is when you downloaded it, not when they were created.

@GEPEG_Unconscious, congratulations on thread of the month. The effort you've put into these missions makes it well deserved.

One word of warning about the Dart... it has no thrust vectoring. Just keep that in mind when designing your lifter. You may need to make other accommodations for steering, like control surfaces, RCS, or strong reaction wheels.

The basics haven't changed. I think what you see in that thread is probably still valid.

I don't know what's going on because Minmus has no oceans! You shouldn't be seeing any water at all. FlattenOcean is a bit of a misnomer, it really doesn't have anything to do with oceans. It just fills in any terrain below the elevation it is set to. So if you set it to -100, then any ground below -100 is filled in up to an elevation of -100 with solid ground. There shouldn't be any water anywhere unless there is a Ocean node in the config, and Minmus doesn't have one. I've flown around Minmus plenty of times and I've never seen this problem. Perplexing indeed. And, yes, "order" sets the sequence in which the PQSmods are executed. @linuxgurugamer, I remember talk some time ago about a problem in Kopernicus in which the fix was to add oceans to every celestial body. I don't recall specifically what the problem was, but I'm quite certain it has been corrected. Do you happen to have an old config left over from that fix somewhere inside your GameData folder? If so you should delete it. (edit) I found it... There was some sort of a lag issue that was reported last year. The temporary fix was to add oceans to all bodies not already having one, using this config. If you still have that config somewhere in your KSP installation, then that would certainly cause the problem you're seeing. The lag issue was fixed in Kopernicus 1.7.3-2, so you want to find and delete the patch if it's still there.

This is a good place to start...

It's a PQSmod in the planet config. If you open JNSQ/JNSQ_Bodies/Minmus.cfg you'll see this... FlattenOcean { oceanRadius = 0 order = 17 enabled = True name = _Height } You might try enabled = False to see if that changes anything. Edit: Disabling the mod will change the terrain. So if you have something landed on Minmus, it could be damaged or destroyed.

@linuxgurugamer, Minmus doesn't even have an ocean node, so it's quite strange that' you're seeing water. But it does use FlattenOcean to create some flat areas. It kind of looks like it's those flat areas where you're seeing the flickering water. I've been playing JNSQ but haven't had the issue, so I can't test anything if I can't recreate the problem. I wonder if you were to disable the FlatternOcean mod if the problem would go away?

You're using some contract pack mods. You probably should ask your question in the thread for those mods. This isn't a general KSP question.

A screenshot of your vehicle would help immensely.

There's also a mod version of it...

@O5-7, others have already given you some sage advice, but here's some more... The atmospheric pressure at Eve sea level is 5 times what it is on Kerbin. High atmospheric pressure destroys the performance of rocket engines. Engines always work best in a vacuum and get progressively worse as the ambient pressure goes up. There are two strategies you can employ to make getting off of Eve possible: (1) take off from a location where the atmospheric pressure is lower, and/or (2) use the engines that are best suited for the higher pressures. While the sea level pressure on Eve is 5 atm, it decreases with altitude. So the higher the terrain from which you take off, the lower the air pressure and the less of a performance hit you're going to take in regard to your engines. This also means you'll have lower drag losses, reducing the amount of delta-v it requires to attain orbit. It might be hard to find a nice flat spot to land on at Eve's higher elevations, but if you can, every kilometer rise in elevation decreases the air pressure about 9%. For instance, if you can find a landing spot at an elevation of about 2500 m, you'll only have to deal with an atmospheric pressure of 4 atm instead of 5. Rocket engines come in all types. Some are designed specifically for use in a vacuum, while others are designed for use at higher atmospheric pressures. In real life this difference is attained by varying the expansion ratio of the nozzle. In KSP we see the difference in the engine specifications. The "sea level" optimized engines that we have in KSP are designed for use on Kerbin, where the sea level pressure is 1 atm. None of them are optimized for use on Eve where the air pressure can reach 5 atm (except arguably the Dart [aerospike]). This means that when on Eve we must make do with engines that are not designed for the conditions and produce quite poor performance. There are only a handful of engines in KSP that gives enough performance at 5 atm to make them even worth considering. One of the ways we can judge how well a particular engine will perform is by looking at its specific impulse. Here are the best options available to us, with the specific impulse listed for pressures of 5, 4 and 3 atm. Specific Impulse (seconds) Engine 5 atm 4 atm 3 atm Thud 140 174 209 Mainsail 148 184 220 Twinboar 148 184 218 Vector 193 220 246 Dart 230 242 251 Far and away the best performing engines are the Vector and the Dart, as others have already said. Unfortunately these are very expensive engines that don't come until very late in the tech tree. (Of course if you're not playing career that doesn't really matter.) You can make do with the other engines if necessary, but you can see there's a big performance hit. I wouldn't even consider any other engines not listed as their performance is just too low. My mod Eve Optimized Engines provides variants of several stock engines by adapting them specifically for use in the high ambient pressures found on Eve. This is justified by presuming the nozzle expansion ratios are modified to better match the operating environment. Some players consider it cheating, but it is based on real science and engineering practices. I consider it selecting the right tool for the job.

Even those working on it don't know when. Whenever they have the time and motivation to get it done.

My experience was different too, but I don't recall now specifically what it was. I know I had issues with the panels tracking the wrong star and power output not being what it should be. Whatever the case, it is definitely bugged. I tested the fix that the Kopernicus devs came up with and it seemed to rectify all the problems. So if and when Kopernicus updates, we should be in good shape. Since @Spartan125's symptoms are a little different than ours, it's possible his problem could be related to something else. But as long as the bug exists in Kopernicus, we can't diagnose the problem any further. We must eliminate Kopernicus as a potential source before we can see if something else is at fault.

There's a bug in the Kopernicus solar panel module for 1.8.1. I suspect that's probably the source of your problem. I reported the issue to the Kopernicus devs and they fixed for the next Kopernius release. No idea when that will be. JNSQ actually deactivates the Koperniucs solar panel module, but GEP_JNSQ reactivates it. If you want it deactivated, find and open the file GEP_forJNSQ.cfg. Scroll all the way to the bottom and delete the following bit: // ============================================================================ // Use Kopernicus solar panel module. // ============================================================================ @PART:HAS[#useKopernicusSolarPanels[*]]:FINAL { !useKopernicusSolarPanels,* = DEL } Hopefully that will solve your solar panel issue around the sun, but as you surmise, panels won't work around Grannus.

Principia is a mod that replaces stock physics with n-body physics. This means that the gravity of all nearby bodies influence the orbits of planets and moons. The shape of orbits vary with time and can even become chaotic. If a system is poorly designed the orbits can be unstable, causing moons to be flung out of their orbits.

@E for Earthling, you don't happen to have Principia installed, do you?