OhioBob

KSP uses G = 6.67408E-11 m3/(kg-s2) But really you don't need to know that, nor the mass. Just solve for the product GM, often denoted by the Greek letter μ, which is known as the gravitational parameter. All problems in orbital mechanics use GM, so there no need break it down further into G and M. That just adds an extra operation and more numbers to remember.

@fwdixon, I'm seeing the same problem that you're seeing, but I can't figure out what's wrong. I've looked at the configs and the logs and I don't see any reason why it's not working. I'm currently stumped, but I haven't given up hope yet. I'm going to continue working on it. Unfortunately we've made it a convoluted mess with all these installation options, so debugging can be difficult. And just because the problem appears when GEP is installed, that doesn't necessarily mean the bug is in GEP. GEP and GPP are both configured to do different stuff depending on what's installed with it. So the presence of GEP may be triggering something in GPP that's causing the problem. I did find a typo in one of the GEP configs, but it apparently has nothing to do with the current problem. Nonetheless, I'll eventually have to release an update to fix it.

This mod requires Kopernicus, and Kopernicus hasn't yet been updated. So no, this mod doesn't work with the latest KSP. Please wait for the mod authors to get caught up.

@fwdixon, I'd like to see a screenshot of your GameData folder.

@Zithorian, you have to specify a template, like this: Body { Template { name = Jool }

It varies depending on the particular launch window, but generally you want to launch when Eve trails Kerbin in its orbit by about 45 degrees.

That's interesting; I don't know how it got there. Since I'm not responsible for it being on CKAN, I can't vouch for whether or not it's up to date. I don't recommend installing it through CKAN.

Try it and see. The lasted release of Sigma Binary on GitHub (v1.7.0) is dated May 3. The last KSP release was in late April. So I assume Sigma Binary has been updated.

There's a celestial coordinate system used to measure the orbital elements. Zero longitude points in the direction of a point in space that is fixed relative to the stars. In real life, zero longitude is along the line formed by the intersection of Earth's equatorial plane and the ecliptic plane, pointing in the direction of the vernal equinox. In KSP it is not entirely clear what defines the direction of zero longitude. One thing I've noticed, and this is totally unofficial, is that when you look at the "milkyway" that crosses the sky, there appears to be a bright middle to it. Zero longitude seems to point in the direction opposite this brightest part of the milkyway. At least that's what I recall.

@Tonas1997, here's a post I made last year describing a method that I like to use for making sunlight intensity curves. Maybe it will give you some ideas.

If you enter slopes of 0 you'll get a curve with flat spots on it. It will looks something like this: You'd probably be better off using no slope. In that case, unity will compute a slope using a default formula. I believe it makes the slope at any given point equal to the slope between the two points straddling it. And for the end points it uses the slope between the end point and the point next to it. If you want the lighting to fade linearly, then you can simply do something like this, which is a straight line between the beginning and ending points: IntensityCurve { key = 0 1 0 -5E-13 key = 2E+12 0 -5E-13 0 } Or, in this case, you should get the same thing using no slope, IntensityCurve { key = 0 1 key = 2E+12 0 } By the way, I don't know what happens when we use a brightness greater than 1. I've never done that. Inside a certain distance from a star, I typically just set the value equal to 1. Regarding the second part of your question, IntensityCurve is the lighting that we see when we are in flight mode and close to the planet. For example, when we are in low orbit around it or landed on its surface. ScaledIntensityCurve is the lighting that we see when we are seeing the "scaled space version" of the planet. This occurs when we are far from the planet, in map mode, or in the tracking station.

Integrating GEP into GPP as a single installation adds bodies that some people may not want. It could be too much for some people's computers to handle. We prefer to keep the mods separate. If somebody wants the additional planets around Grannus, then it is a very simple process to go download and install GEP separately. GPP and GEP are for the most part finished products; we're not making any more changes.

Are you using Sigma Dimensions to scale RSS down to stock-scale? I see that the curves you're using are already scaled down to 1/10th scale. I don't think you want to do that. Since you are editing RSS's configs, and since RSS is a real scale system, you want to use curves that have real scale distances. Sigma Dimensions should then scale down the intensity curves along with everything else. I believe you are effectively doubling up on the 0.1 multiplier. Based on your curve, I think the light intensity at Earth is about 0.2 rather than 0.65 as apparently intended. Try multiplying all the distances in your curves by 10 and see if that fixes it. Also note that the distances in your IVAIntensityCurve are wrong. IntensityCurve and IVAIntensityCurve use the same units (meters). It is only ScaledIntensityCurve that should be different (meters/6000).

The single setting is still an option in Kopernicus, but in that case a star's brightness doesn't diminish with distance. In other words, a star's light has infinite range. With multiple stars that's a problem because objects near Ciro would also be brightly illuminated by faraway Grannus, and vice versa. GPP uses brightness curves so that the sunlight decreases with increasing distance from each star. You've got two options depending on what you want. First, edit the curves in the file GPP/GPP_Configs/SunCurve.cfg. These are the curves that produce the light intensity decrease as we move away from a star. The second number in each "key" is the brightness. Just increase the numbers to make the sunlight appear brighter. If you prefer to have all the planets equally illuminated with no decrease vs. distance, then use the second option. Just delete the file SunCurve.cfg. This will cause the sunlight intensity to revert the curves in the individual star configs - Ciro.cfg and Grannus.cfg. These curves produce even illumination across all the planets, but it then decreases to zero before reaching the neighboring star. In this case the curves are simpler with fewer numbers to change.

Realistic Atmospheres is not on ckan. (If you're seeing it on ckan, then I have no idea how it got there. It's nothing that I'm responsible for.) Download and install it manually.

Orbital period/speed is a function of the gravitational parameter of the primary body and the distance from it. Changing either of those parameters will change the orbital period, but otherwise it can't be changed. It is a hardcoded calculation that you can't override. The only other thing you can do is change the way that orbital period is calculated. Normally KSP uses a simplified calculation that takes into account only the mass of the primary body. But by using the setting finalizeOrbit = True, KSP will take into account the mass of both bodies in the calculation. It most cases it's only a very small difference, but if two bodies are close to the same mass, like binary stars, it can make a pretty significant difference in the orbital period. Better question, why would you want to? You could try giving a body a negative surface gravity, negative mass, or negative gravitational parameter (use only one), but I have no idea if that would work, or what the consequences would be. It might simply blow the game up. Just try it and see what happens.

GEP is designed to play nicely with OPM. With GEP, OPM and CustomBarnKit all installed, you'll get the same Level 4 Tracking Station that OPM uses. That by itself won't be enough to reach Grannus, however. If you want communications to reach all the way to Grannus, you'll also need an larger antenna. GEP comes with its own antenna, which you get when installing the optional mod GEP_CommNet. The antenna is an upscaled version of the Communotron 88-88 with a new texture, but you don't get it until very late in the tech tree. GEP_CommNet comes in the GEP download, but you have to install it separately. You can also use the JX2 antenna if your prefer it. GEP_CommNet also installs the Level 4 Tracking Station if GEP is used without OPM.

The appearance of Lili changed in one of the recent updates, but none of its physical or orbital properties. So everything you said is still true.

Sounds like you're just talking about visual effects. I assume you're OK as far as aerodynamic effects are concerned? I'm a lot more familiar with how to make aerodynamic adjustments, but I'm guessing that you can probably change the visible height of the atmosphere using the atmosVisualEffect parameter. Open the file 6.4xKSP.cfg and you will see the following: @SigmaDimensions { // Base Settings @Resize = 6.4 @Rescale = 6.4 @Atmosphere = 1.2 @dayLengthMultiplier = 1.75 // Advanced Settings @landscape = 0.57 @geeASLmultiplier = 1 @resizeScatter = 1 @resizeBuildings = 0 @CustomSoISize = 0 @CustomRingSize = 0 @atmoASL = 1 @tempASL = 1 @atmoTopLayer = 1.333333333 @atmoVisualEffect = 1.2 @scanAltitude = 1 } Near the bottom you see @atmoVisualEffect = 1.2. Try changing the setting to see if you can find something more to your liking.

It's possible, but it's one of the biggest challenges there is in KSP. The selection of engines is really important because, at Eve's high atmospheric pressure, there are only a few that can produce adequate thrust. The Aerospike and Vector are best. It also takes a lot of delta-v, though I don't remember what the generally accepted value is. Streamlining is also really important because of the dense air. One of the biggest hurdles, as I recall, is designing something that can be aerodynamically stable during entry and landing, and then can also be aerodynamically stable during liftoff. I've landed on and taken off from Eve once, but that was way back in KSP 0.90. It has changed much since then. The problem back then was the extremely high drag and designing a vessel with enough delta-v. I think the delta-v requirement is now much less, but aerodynamic heating and stability are now much bigger issues.

I've seen several mods that are not "kronometerized". Those mods are likely hardcoded to a 6 (or 24) hour day. From what I've been told, there are internal variables that define the length of day and year, and unless a mod references those variables, it's not going to work correctly with Kronometer. It's my understanding that it's the other mods that must change to make it work. Until that happens (if it ever does), you'll just have to deal with the inconvenience.

I've used the current version of Kronometer with KSP 1.4.3 and it worked OK for me.

This may be a silly question, but did you inflate the heat shield prior to entry? Your screenshot shows it in the deflated position. To work you have to right-click on it and select "Inflate Heat Shield". Other than that, as long as you don't enter too steeply and too shallow, I see no reason why your vessel shouldn't survive entry. And I agree that you don't need anywhere near that many parachutes. Eve air is very dense, so you typically require less parachute than you'd need to land the same probe on Kerbin.

Make sure your entry vehicle has a low ballistic coefficient. That is basically mass per unit area of heat shield. For aerocapture I'd recommend a periapsis of about 60 km, though that will vary depending on the ballistic coefficient and the entry velocity.

You have no idea how convoluted this stuff is. None of these configs were originally written in anticipation of the amount of complexity we're currently dealing with. If you look at this post, you see we have 15 different install scenarios to deal with. And then we have +EVE/no scatterer, +scatterer/no EVE, and +EVE/+scatterer variations. So that means we have 45 different ways people can install this stuff, and a handful of mods that all have to play nicely together in each one of those different combinations. It's amazing it works at all. If we can figure it out and fix it, we will. But seriously it could take somebody a couple days to track down the problem, and then make sure that whatever change is made doesn't break one of the other 44 combinations. And quite honestly, we're all pretty burned out at the moment and in need of a break.