OhioBob

I haven't built a successfully Eve lander/launcher since v0.90. Landing a probe is no problem, and launching is no problem if I use cheats to get there. But every time I try building something capable of landing and launching, I can't get it to the surface without it becoming unstable and burning up during atmospheric entry. I know many people recommend putting an inflatable heat shield on both the leading and trailing ends to stablize it, but I really don't like that solution. I'm still searching for another way, though I really haven't put forth a concerted effort.

First, I actually think 8000 m/s for stock Eve is a bit high. I've been able to do it for 7000-7500 m/s, but that involves some cheating by teleporting a very well designed are aerodynamic rocket there. Designing something that can not only takeoff from Eve but also survive entry, descent and landing would likely require some compromises that could hurt efficiency. As for why JNSQ Eve may actually be easier than stock Eve, I can suggest several reasons. The first you've already mention, Eve's surface gravity in JNSQ is only 1.4 g rather than 1.7 g. This means the gravity losses are going to be less. The biggest reason, however, is that Eve's atmosphere in JNSQ is quite a bit different from the stock version. Even though the atmospheric pressure at sea level is higher (10 atm vs. 5 stm), the JNSQ atmosphere thins out much more quickly. The density of the JNSQ atmosphere is greater only for the first 7400 meters of altitude. Above 7400 meters the JNSQ atmosphere is thinner than the stock version. The fact that the stock atmosphere thins out so slowly is very unrealistic for a body with such high gravity. The JNSQ atmosphere is much more realistic in how it changes with altitude. So while JNSQ presents a greater challenge for those first 7 km, after that it becomes much easier. This is the reason we increased the sea level pressure to 10 atm - to add back some difficulty that was lost by making a more realistic atmosphere. So despite the higher sea level pressure, drag loses are much less in JNSQ than in stock. Furthermore, because of stock EVE's unrealistically thick atmosphere at high altitude, it is necessary to maintain near vertical flight for quite some time before it's possible to pitch over and really start accelerating. Because JNSQ's upper atmosphere is much thinner, it's possible to transition to horizontal flight sooner, which further decreases the gravity losses. So while orbital velocity is much higher in JNSQ than it is in stock (about 5200 m/s vs. 3200 m/s), we save that difference or more in lower gravity and drag losses. The 10 atm sea level pressure is at first a real problem as far as engine efficiency goes (higher ambient pressure means lower thrust and specific impulse), but remember how quickly the atmosphere thins. Engines may really struggle at first, but once above about 8500 meters (where the JNSQ and stock air pressure is equal) you're going to get better engine performance in JNSQ than in stock. So while engine efficiency has no effect on the delta-v require to achieve orbit, it does effect how much delta-v a rocket can deliver for the same fuel mass. So overall, Eve launch vehicles in JNSQ should require a lower fuel mass ratio than those in stock.

Perhaps that's true, it's been a very long time since I used a Stayputnik. If so, I stand corrected.

Just to clarify something that @DVQuill talked about... SAS can be thought of as the computer system that controls attitude, but it does not actually produce any torque whatsoever. To produce the torque (the turning force), reaction wheels, RCS thrusters, gimballed engines, or aerodynamic control surfaces (e.g. fins) must be provided. In other words, to control attitude you must have both SAS and some torque producing mechanism. SAS is a completely separate thing from that which produces the torque. While it is true that most probe cores in KSP have both SAS and reaction wheels, don't conflate these systems. There are some probe cores that have SAS only with no reaction wheels (Probodobodyne QBE and OCTO2 for example). So while these probe cores have the brain to control attitude, they are unable to do so by themselves because that lack the machinery to produce torque. They can, however, control a rocket that has, say, gimballed engines or moveable fins. On the other hand, if you have torque producing parts but no SAS, there is no way to control those torque producing parts. The Stayputnik probe core, for example, has no SAS. Therefore a rocket equipped with a Stayputnik cannot be steered even if equipped with gimaballed engines or fins. There is simply no way to command those mechanisms to move without SAS to send the commands. One final note, a Kerbal pilot is equivalent to SAS and can perform the same functions. SAS can be thought of as an automated or remotely control system. If a pilot is on board and inside a command pod, he/she can perform those tasks without the need for SAS.

(EDIT: Note that when answering below I misread "attitude" as "altitude". Sorry about that. Hopefully some of it is still applicable to your question.) To change a rocket's altitude, its velocity must change, which means there must be a force applied to the rocket to accelerate it. This force is typically applied by firing an engine. In KSP this is the only way to change a rocket's velocity once leaving the atmosphere. However, in the real world the atmosphere doesn't just suddenly end like it does in KSP. So even rockets in orbit around the earth are still subjected to a small amount of atmospheric drag. This drag produces a force that causes orbits to decay. So in the real world altitude can change with firing an engine. Fins should have no affect on a rocket outside of the atmosphere because there is no air to produce aerodynamic forces. Reaction wheels should also have no affect on a rocket's velocity. Reaction wheels produce torque only, which causes a rocket to rotate about its center of gravity. This changes a rocket's attitude but not its velocity as there is no lateral force applied. RCS thrusters, however, can be used for both attitude control and translation, depending on their placement and how they are fired. If used for translation, the rocket's velocity vector will change, and hence the size and shape of its orbit.

I think that may be more an issue with TWP and KAC than Kronometer.

As I recall, Transfer Window Planner only does interplanetary transfers, I don't think it's possible to do moon transfers.

If your problem is that the numbers don't match, I believe that's because they're not reporting the same information. Transfer Window Planner is showing the departure date, while Kerbal Alarm Clock is showing the time until departure. If your problem is otherwise, please explain.

You'd have to write a config for it. Perhaps you can reverse engineer what's already there for Ciro and apply it to the Sun.

That's normal. The white scatterer sunflare is for Ciro, not the Sun.

Per the JNSQ ReadMe: With the same mods installed that you are using, my KSP is using 7GB at rest.

There's a delta-V map included in the GEP folder (GEP_DV-01.png and GEP_DV-02.png). Unfortunately it's for stock size GEP only, not GEP_Rescale. But generally speaking, delta-V varies by the square root of the resize factor. So for 2.5x GEP you should be able to multiply all the numbers by 2.5^0.5 = 1.58 and be very close.

Most likely, but I can't guarantee it. In a clean install with just OPM, adding GEP shouldn't cause any problems at all. But I suspect you have other mods install, and that's where things can get messy, It's impossible to test all possible mod interactions, so one can never be certain what will happen.

No.

The screenshot is outdated. The issue is that I'm trying to make the color in scaled space match that of the lava texture. I actually screwed something up with the original lava texture that made it a darker red. When I fixed the mistake, the texture became a brighter orange, so I changed the scaled space texture to match. To be honest, I'm not sure I like the brighter orange, so I may try to do something in the future to darken it. In the meantime, the scaled space texture and the up close lava texture do match pretty closely. Unfortunately there's a bug in Kopernicus that messes up the transition between the textures (the dev knows about it but I don't think it's been fixed yet). When transitioning, parts of the lava sea actually turns blue.

I just found the problem. Go ahead and keep the previous change. While it didn't fix the problem, it does clean some stuff up in the MM Cache. The real problem is in the file GEP/GEP_Configs/Clouds.cfg. Make the following change. Delete this... EVE_CLOUDS:NEEDS[!GPP,!StockVisualEnhancements,!BoulderCo] {} @EVE_CLOUDS And replace with this... EVE_CLOUDS If you want to know the details of what the problem was, I explain here:

Taranis, Sucellus and Epona are all Celtic deities, as are all the other bodies in GEP. That's the naming theme that was chosen for GEP. Any reuse of these names from another mod is only coincidence.

@John007qwe, I don't think there is anything wrong with the @PQS_MANAGER part. It might be that first line in the GEP config. I don't really remember what the purpose of that is, but I might have to add AVP to the NEEDS. I haven't had an opportunity to test anything yet, but if you feel up to it, you might give this a try: PQS_MANAGER:NEEDS[!GPP,!StockVisualEnhancements,!BoulderCo,!AstronomersVisualPack] {}

@John007qwe, I don't remember what that file does exactly, but I know it is required for all gas giants. I see that AVP adds it for Jool as well as the OPM gas giants (AstronomersVisualPack/AVP_Configs/OPM/PQS.cfg). I also add it in GEP for Sirona. But this gives me a lead to follow up on. There could be some little thing in the configs that's causing it not to execute properly.

I suspected that AVP might be the culprit when I saw it on your mod list. I never tested GEP with AVP. In fact, I've never used AVP so I know nothing of how it's configured. I'll try to take a look at it when I get the chance. Hopefully it's something simple to fix.

I don't see any GEP related errors in the log. But I do see a bunch of lines like this for the gas giants, [LOG 18:57:35.325] [Kopernicus] New Jool detected, shaders stripped! Not sure what that means but it's there for both GEP and OPM. Are the OPM gas giants working? If not, then the problem isn't limited to GEP. Might be a problem somewhere else, like Kopernicus. You also have nearly 200 mods installed, so there could very easily be a conflict with one of them. Perhaps one of the visual mods. If it is a mod conflict, you're going to have help me and figure out which one it is. I can't possible check GEP to assure compatibility with every conceivable combination of mods that somebody might install.

@The Blazer Explodium Breathing Engines might just be what you're looking for. It's jet engines for Eve, but instead of carry the fuel and extracting oxygen from the air, you carry the oxidizer and extract fuel from the air.

Yes, "Sensitivity". The value entered here is the minimum throttle setting. So entering 1 means the throttle should never go below 100%. No

Those are SigmaDimension/Rescale settings. You don't need to change anything in RealisticAtmospheres.

Update! KSPatmoCalculator v2.0.0 is now availble. This is a complete rewrite of the previous version. You should find it much simpler and easier to use.