OhioBob

I haven't tired with Kopernicus 1.3.0-4 yet, but this mod has a pretty good track record of not breaking with Kopernicus updates. You're probably safe, but I need to check it out just to make sure.

I've never seen a node called "SolarLightColor". I've always seen it named simply "Light". Maybe both work, but I don't know. The brightness curve goes under the light node, something like this: ScaledVersion { Light { sunlightColor = 1.0,0.1,0.2,1.0 sunlightIntensity = 0.82 scaledSunlightColor = .0,0.15,0.2,1.0 scaledSunlightIntensity = 0.55 IVASunColor = 1.0,0.1,0.2,1.0 IVASunIntensity = 0.55 sunLensFlareColor = 1.0,0.1,0.2,1.0 sunAU = 13599840256 luminosity = 1360 brightnessCurve { key = -0.01573471 0.217353 1.706627 1.706627 key = 5.084181 3.997075 -0.001802375 -0.001802375 key = 38.56295 1.82142 0.0001713 0.0001713 } } } You should also give the star a luminosity. The luminosity as defined in KSP is the solar flux (measured in W/m2) at a distance from the star equal to the distance of the home world from its star (which may or may not be the same star).

This is the brightness curve for the stock sun: ScaledVersion { Light { sunAU = 13599840256 brightnessCurve { key = -0.01573471 0.217353 1.706627 1.706627 key = 5.084181 3.997075 -0.001802375 -0.001802375 key = 38.56295 1.82142 0.0001713 0.0001713 } } } I'd start with this by adding it to all your stars. You can then adjust the numbers until you get what you want. I'm assuming you understand floatCurves. If not, then I recommend you start here. What the brightness curve does is it determines how big the star's sunflare appears from a distance. The first number is the reciprocal of the distance in AU, and the second number is the diameter of the sunflare. For example the first number in the second key is 5.084181. This is a distance of 1/5.084181 = 0.196688513 AU, or 0.196688513*13599840256 = 2674932357 meters. At that distance the sunflare will have a diameter of 3.997075 (units?).

What do you mean? Planets are already round.

@Spaceception, there's some stuff you can do to make sure the atmosphere encompasses the whole planet, but it might not be entirely realistic. If you end up making your planet and want some help or suggestions when it comes time to make the atmosphere, just ask me. I'm sure I can figure something out.

As far as I know, there is no way to deform an atmosphere in KSP; it will always behave as if it's spherical.

I've noticed that too, but I couldn't remember what it use to do. I couldn't tell if it was something new, or something old that I just never noticed before. I agree that it looks very unnatural.

What GPP and Kopernicus version numbers are you using? I know there were several things in GPP that were broken by Kopernicus 1.3 (mainly PQSMod stuff). We've been working on getting a 1.3-compatible version of GPP ready for release. It's this GPP dev version with Kopernicus 1.3.0-2 that I've been using.

Let me make sure we're talking about the same thing when referring to "ejection angle". What I'm thinking of is the "angle to prograde" or "angle to retrograde". Is that right? If we assume that the departure asymptote is tangent to the orbit of the planet, then the ejection angle is simply the angle η as shown in figure 4.15 and computed by equation 4.81.

I just reinstalled GPP and started redoing my scans. You're right, the planets are showing up on the list but not the moons. I didn't realize this was the problem before because of the order in which I did the scans (planets before moons). So, @DMagic, what's the solution? Is it something you have to fix, or is there something we have to change in GPP?

@DMagic, I used the exact same KSP 1.3 installation that I had been using previously. The only thing I did differently was to uninstall GPP. It works now. I scanned enough bodies until the window filled up, and on the next one the scroll bar appeared. Do you have any idea why it doesn't work with GPP? I'm on the GPP dev team, so anything you can do to point me in the right direction would be helpful.

Kopernicus does support 1.3. The last official release of GPP does not, but I'm using the dev version that should be 1.3 compatible. I'll be happy to test it out in stock, I assume you mean with KSP 1.3?

Vbo is the burnout velocity. It the velocity the spacecraft is traveling immediately upon completion of the ejection burn, i.e. at engine burnout. Rbo is the magnitude of the spacecraft's position vector at burnout, i.e. the distance from the center of the planet to the spacecraft. For most computations we simplify things by assuming that the Δv is applied instantaneously. Therefore, Vbo is the initial orbital velocity plus the burn Δv, and Rbo is the radius at the ejection point, which we also assume is the periapsis of the resulting hyperbolic trajectory. In practice it's more complex. I don't know. I'll have to study that and get back to you.

Yes, that's the window I'm talking about. But mine doesn't have the scroll bar... I've scanned the bodies listed, plus two others (Augustus and Tarsiss). When I go to the Color Management tab there is an scroll bar and I can select any body. I'm not sure what I'm suppose to be looking for in the logs, but I do see this: [LOG 12:43:38.665] [SCANsat] SCANsat Controller: Loading 1 known vessels [LOG 12:43:38.666] [SCANsat] SCANsat Controller: Loading map for Lili [LOG 12:43:38.668] [SCANsat] SCANsat Controller: Loading map for Tellumo [LOG 12:43:38.671] [SCANsat] SCANsat Controller: Loading map for Niven [LOG 12:43:38.673] [SCANsat] SCANsat Controller: Loading map for Gratian [LOG 12:43:38.675] [SCANsat] SCANsat Controller: Loading map for Augustus [LOG 12:43:38.678] [SCANsat] SCANsat Controller: Loading map for Tarsiss [LOG 12:43:38.680] [SCANsat] SCANsat Controller: Loading map for Gael So apparently the maps for Augustus and Tarsiss exist, but I just can't select them from the dropdown menu because there's no scroll bar. (edit) I've looked through the logs some more and I really don't see anything that looks specifically related to this problem.

By “velocity on escape” I presume you’re referring to what we call hyperbolic excess velocity, which is given by equation (4.88) in my web page. It’s a little different in KSP, however, because of the way patched conics are used. I’ve derived the following equation: Vsoi² = 2μ * (1 / Rsoi – 1 / Rbo) + Vbo² where Vsoi is the velocity at the sphere of influence, Vbo is the burnout velocity, Rsoi is the radius at the sphere of influence, Rbo is the radius at burnout, and μ is the gravitational parameter. This is the KSP version of V∞² = Vbo² - Vesc², except it takes into account that patched conics are used by giving the velocity at the sphere of influence rather than at infinity. Note that the equations are the same if we set Rsoi = ∞. In the KSP universe, Vsoi is functionally equivalent to V∞ because it represents the velocity remaining after escaping the planet’s gravity. There is no single or easy equation used to compute ejection angles, it can get rather complex. This section of my web site explains it.

A 2.5x was added in one of the GPP 1.2.x versions, don't remember which one. We added 10.625x in v1.2.3. So we currently have 2.5, 3.2, 6.4, 10 and 10.625x.

Kopernicus has been updated for KSP 1.3.0. The problem is that Kopernicus changed quite a bit from its previous version, which broke several things in GPP. We're still in the process of getting GPP fixed and ready for its next release. After the next release of GPP, you'll have to play it along with KSP 1.3.0 and Kopernicus 1.3.0-2. But until then you'll have to play GPP 1.2.3 on KSP 1.2.2.

@DMagic, I think I've found a bug with v17.7. From the main map view I click on "Celestial Body" to change bodies, but there are only 6 bodies listed and can't scroll to see anymore. I know I've visited and scanned more bodies than are listed, but I can't select them.

Solar panels should keep their power output relative to the planets without you having to do anything. The chargeRate defined in the solar panel configs is the rate that you get at the home world. Moving the home world closer to or farther away from the sun doesn't change this. The charge rate at other distances is computed from the value at the home world and adjusted according to the inverse square law.

In that case, @CatastrophicFailure should probably edit Rald's config and give it a flighGlobalsIndex number. Next number on the list is 88.

@CatastrophicFailure, I forgot you said you had Rald installed. My apologies, I can't see how that might mess something up.

That's probably a good idea. Anybody downloading GPP for the first time certainly doesn't need it, so it's probably causing more confusion than anything. Perhaps you can make GPP_CareerSaver available on Dropbox in case somebody needs to re-download it for some reason, but it probably doesn't need to be in the main GPP download anymore.

I don't understand why you are trying to change numbers. I think you'd either want the old numbers from before verison 1.2.0, in which case you use GPP_CareerSaver, or you'd want the new numbers, in which case you don't use GPP_CareerSaver. Starting with GPP 1.2.0, Galileo had to reorder the flightGlobalsIndex numbers, I presume because of the contact issue. What this did, however, was it had the potential to move already existing spacecraft from a previous saved game from one body to another. Let's say you had a space station orbiting Ceti. If you upgraded from GPP 1.1 to GPP 1.2.0 and loaded your old game, the space station would be relocated from Ceti to Niven. This is because in the old numbering system, Ceti was number 66, but in the new numbering system, 66 is reassigned to Niven. So if you are playing a game that was started using the old system of numbers, then you probably should continue using the old numbers, which is what GPP_CareerSaver does for you. The consequence of that is some of the contracts are messed up, but I don't think you can fix that by changing flightGlobalsIndex numbers around because you're likely to break something else. One bit of advice that I'd like to put out there to everyone is this: If you are playing an old game using GPP_CareerSaver, then continue to do so as long you continue playing the old game. But as soon as you're ready to end that game and start a new game, then delete GPP_CareerSaver before starting the new game. No good comes from using GPP_CareerSaver if you are starting a new game. You want to wean yourself off GPP_CareerSaver at the first opportunity, otherwise you'll be forever dependent on it.

Yes, it does affect heating. I've only done a small amount of testing, but what tests I did run showed that temperatures were lower around stars with lower luminosities.

@Thomas P., did you ever get a chance to investigate this issue?