OhioBob

I really don't see anything wrong with your config. If you haven't already done so, it might not be a bad idea to delete your cache file and let that rebuild. Other than that, the only thing I can suggest is to try disabling the PQS mods one at a time to see if perhaps one of those is causing the problem.

I would say a flyby is anything that enters a body's SOI, passes through periapsis, and the exits the SOI. The vessel's trajectory in relation to the celestial body is hyperbolic, meaning it has an eccentricity >1, a semimajor axis <0, and no apoapsis. Only a closed elliptical orbit can have an apoapsis; a hyperbolic orbit is an open or unbounded orbit. You might see an apoapsis outside the SOI, but this is the apoapsis of the vessel's orbit around the sun (or around the planet if we're flying by a moon). When inside the SOI we see the hyperbolic geocentric orbit, and when outside we see the elliptical heliocentric orbit. Because of the way KSP does patched conics, there could be the unlikely scenario in which a vessel passes through a body's sphere of influence while not actually being on a hyperbolic trajectory. That is, it could have an eccentricity <1 with an apoapsis so far away that it's outside the SOI. However, for any kind of normal interplanetary encounter, the vessel will be carrying enough excess velocity that the chances of this happening is nil. As far as contracts are concerned, I think we just need to enter a body's sphere of influence.

I've just learned some new information that I want to pass on to you. First, here is an explanation of how things are suppose to work: IVA mode The color of light seen in IVA mode is controlled by the parameter IVASunColor. The intensity is controlled by either the parameter IVASunIntensity (constant intensity), or by the curve IVAIntensityCurve (variable intensity). Scaled Space Scaled space includes lighting on celestial bodies in the tracking station, map mode, and flight mode at distances beyond where PQS is seen. The color of light in scaled space is controlled by the parameter scaledSunlightColor. The intensity is controlled by either the parameter scaledSunlightIntensity (constant intensity), or by the curve ScaledIntensityCurve (variable intensity). Flight mode/PQS This includes lighting on space vessels and on the surfaces of celestial bodies at near distances where their PQS is seen. The color of light is controlled by the parameter sunlightColor. The intensity is controlled by either the parameter sunlightIntensity (constant intensity), or by the curve IntensityCurve (variable intensity). (Note that constant intensity also means infinity distance.) As of Kopernicus release 1.3.1-2, things are not working as they are suppose to. It seems that the only things that are actually working are scaledSunlightColor, scaledSunlightIntensity, ScaledIntensityCurve and sunlightColor. It doesn't look like anything with IVA mode is working (we're just getting a constant white illumination with no way to adjust it). And although sunlightColor is working, sunlightIntensity and IntensityCurve are not. At present the intensity of sunlight in flight mode and PQS is being controlled by scaledSunlightIntensity or ScaledIntensityCurve. @Thomas P. is aware of these issues and has made changes that should fix it, hopefully to be included in the next release. I also need to correct an error in something I said previously. While the distance units used in ScaledIntensityCurve are meters/6000, or kilometers/6, the distances used in IntensityCurve and IVAIntensityCurve are meters. I had not noticed that the units in my existing curves are wrong because those curves are not currently being used. However, going forward we'll have to make sure all the curves use the correct units.

I left a crew of three on Eve for about 20 years, but I did eventually mount a rescue operation to bring them home. That was probably the biggest and most complex engineering and logistics operations I've ever conducted. By the time I got them back home they were a little ripe, but not rotten yet.

Yep, but not part of GPP per se. Although the GPP team has helped me out, it's mainly my personal project. It will be released as a separate add-on. I have no schedule for getting it done, progress has been in spurts and lulls.

Your extensive use of SRBs is likely why we differ so much in TWR. Other than for small rockets, I usually don't use SRBs unless it is to augment my main liquid fueled stage when I need a little extra thrust at liftoff. My philosophy has always been to trade engine for fuel. Reducing engine and adding fuel, (1) lowers TWR, (2) increases gravity losses, (3) reduces drag losses, (4) adds delta-v, and (5) reduces cost. So while my losses are greater, I have the extra delta-v to compensate for it, and overall I've reduced my launch cost.

I can show you the long complicated way of doing it, but I've been trying to come up with a simpler method that doesn't require as much information and math. The best I've been able to come up with is this: ZR = (Z1 + r) * (R * D)2/3 - (R * r) This only works if you happen to know the geosynchronous altitude at normal stock scale (1x). If you do, then the above converts the altitude to different scales. What we have is, ZR = geosynchronous altitude at rescale multiplier R Z1 = geosynchronous altitude at 1x scale r = radius of planet R = Rescale multiplier D = dayLengthMultiplier This only works for non-tidally locked bodies. There's probably a similar equation for tidally locked bodies, but I haven't worked it out. (And besides, most tidally locked bodies have a GSO outside their SOI.) Furthermore, the formula doesn't work for the home world. This is because it is the home world's solar day that get factored by dayLengthMultiplier, rather than its sidereal day. Some sort of correction will have to be made to account for this, but I haven't figured it out yet. EXAMPLE What's the GSO altitude around Eve at 10.625x? Z1 = 10,328.7 km (from Wiki) r = 700 km R = 10.625 D = 2 (from rescale cfg) ZR = (10328.7 + 700) * (10.625 * 2)2/3 - (10.625 * 700) = 77,174 km ------------------------------------------------------------------------------------------------------------------------ (edit) I've figured out the home world correction. In the formula for ZR we need to replace D with D', where D' is computed as follows: D' = ( R0.5 * P * D * S * (P + S) ) / ( (R0.5 * P + D * S) * P * S ) where P and S are the planet's orbital period and solar day at 1x scale. P and S must be in the same units. EXAMPLE Compute the GSO altitude around Kerbin at 10.625x. From Kerbin's Wiki page, we have P = 9,203,545 s S = 21,600 s Z1 = 2,863.33 km Therefore, D' = ( 10.6250.5 * 9203545 * 2 * 21600 * (9203545 + 21600) ) / ( (10.6250.5 * 9203545 + 2 * 21600) * 9203545 * 21600 ) = 2.001811 ZR = (2863.33 + 600) * (10.625 * 2.001811)2/3 - (10.625 * 600) = 20,211.5 km Without the D' correction we'd be about 16 km too low.

I'm sure it's not the answer you want, but you've got to calculate them. There's no other way I know of other then doing the math.

Although I'm an advocate of lower TWR than Snark, I agree with him on the above. My choice of low TWR is because I think it is more cost efficient, not because I am trying avoid aero losses. As long as the rocket is reasonably streamlined, I never fret about aero losses. And I don't advocate throttling back or thrust limiting a liquid fueled engine just to get within some arbitrary TWR target range. The reason for using lower TWR is because we can use a cheaper and less massive engine. But if circumstance force the use of a large engine, i.e. there are no smaller options that will work, then use what you've got and don't throttle back. Throttling back a large engine means that we're spending big money and incurring large gravity losses to boot. It's the worst possible scenario. That's really important with high TWR. There's one number we can look at that's a very good indicator of how efficient our launch was. That's the amount of delta-v it takes to circularize the orbit when reaching apoapsis. If you require less than 100 m/s to circularize, then that was a pretty good launch. On the other hand, if you need, say, 500 m/s to circularize, then you could have done much better. A high circularization delta-v means that you spent too much time lofting the vehicle vertically. A trajectory that has a very pronounced arc to it is typically not very efficient. You want to try to flatten out the trajectory and spend more time thrusting horizontally. The best launch trajectories are those that end with the trajectory line wrapping all the way around the planet (or close to it) with the apoapsis far downrange of the burnout point. With a high TWR it is more important as ever to try to flatten out the trajectory as soon a possible. If you don't, you'll hit the target apoapsis altitude long before you've gain adequate horizontal velocity. The result will be a highly lofted trajectory requiring a large circularization burn at apoapsis. So while you may have reduced gravity losses, you've squandered away some of that savings by flying a poor trajectory. I also think that high TWR is much less forgiving if you do mess up the turn. If you don't turn soon enough, then the greater velocity that you get with a high TWR just makes it that much harder to execute the sharp turns needed to correct.

The only way I know to move it precisely is by using one of the maneuver node mods. In addition to Precise Maneuver, there is also Precise Node. They are similar, so it's just a matter of which one you prefer.

I've landed on and returned from all of the stock celestial bodies. This includes crewed landings on everything from Moho to Dres, and robotic landings on Jool's moons and Eeloo.

@seanth, why don't you try something like this, Mods { VertexHeightOffset { offset = -2000 order = 100 enabled = True } FlattenOcean { oceanRadius = 0 order = 110 enabled = True } } I just tested it out and it worked great. VertexHeightOffset shifts the terrain up or down, and FlattenOcean fills in everything below the specified altitude. So in this example I moved the terrain down 2000 meters, which effectively moved the datum up 2000 meters. I then filled in everything below the datum. I ended up with big flat plains just like on Minmus, with the elevation of the plains equal to zero. Of course the body I tested it on is heightmap generated. I can't guarantee it will work exactly the same on a PQS generated body, but I don't see why it wouldn't.

This test at least answered the question that prompted me to do this in the first place. The color does change from red to green when crossing the PQS/scaled space boundary in flight mode. That was really what I was trying to figure out. Discovering this other problem was just an accident.

@Sigma88, here's what I started out with: And then I changed it to this: In the first case I was getting red and green light as you described, with both colors dimming with increasing distance from the sun. In the second case I changed ScaledIntensityCurve to produce even illumination across all the planets. Since only ScaledIntensityCurve was changed, only the green light should be affected. But what happens now is both the green and red light are producing constant illumination at all distances. So while the color is correct, the red light intensity appears to be controlled by ScaledIntensityCurve. We can move the rest of the conversation back to the Kopernicus thread if that is more appropriate.

@Sigma88, OK, I'm getting the same colors as you. In IVA mode I'm just getting normal white light, no blue. I'm now going to play around with the intensity curves and see what happens to the brightness.

I've been working on something else all day and haven't had a chance to test it out yet. I'll give it try in GPP using the intensity curves. Give me a little time to report back.

Can you be a little more specific about what kind of mods you think you might like? Also, what mods are you currently using?

I played around with FlattenOcean a long time ago. It fills in all the areas below a certain elevation to create a flat ocean bottom. I'm guessing it can be used to produce the same effect even when there isn't an ocean, i.e. no water. It's certainly worth looking into.

There are PQS mods that can be used to flatten areas. I don't know much about them, but @Galileo has used them. How about something like FlattenOcean?

I doubt anyone has every done that before, so it looks to me like you're the guinea pig. Let us know what you find out. I'm curious, what advantage do you think having a super-dense ocean gives you over just making it a solid surface? Why not just make it solid? You can add oceans to any template. You just need to add an ocean node and set all the parameters. The advantage to using a template that already has an ocean is that you're using the already existing settings. You only have to worry about changing the settings you want to tweak.

Icarus and Thalia both produce heat above normal solar heating (using HazardousOcean), which is what makes them so difficult. While both can be brutal at the surface, the excess heating in orbit is much worse around Thalia than Icarus. Above 15 km around Icarus you are in the clear, that is, you only have to worry about solar heat. But around Thalia you'll receive elevated temperatures all the way out to 9,480 km. Eta is above that height, so the heating there should be as normally expected. There's a local minima in Thalia's heating curve at an altitude of 1,800 km, so if you had to place a station in orbit <7,000 km, that would be the most habitable spot.

I'll try it out when I get a chance.

The problem here is that "best" has different definitions, and everybody has their own opinion. If you gave a concise and unambiguous definition of "best", then the answers would likely start to converge toward a consensus. For instance, if best means you want to minimize losses and get to orbit using the least amount of delta-v, then I agree with @Snark. But that's not how I typically define best. I usually play career mode, so I'm concerned with cost. I want to put the most payload in orbit for the least funds. If I'm designing for the best cost efficiency, then my recommendations would be very different than Snark's.

I didn't test IVAIntensityCurve, so I never noticed if there was a problem with it or not. What I did to test the other curves was this: I started out with identical IntensityCurve and ScaledIntensityCurve, in which sunlight dimmed with greater distance from the sun. I had a probe in orbit around the sun that I could hyperedit to different distances to test the changes in illumination. I also had a probe landed on an outer planet so I could test up close the illumination of the surface. With this set up, everything seemed to be working normally, i.e. dimmer sunlight the farther away from the star I got. I then changed ScaledIntentityCurve to a curve that gave even sunlight intensity all the way out to just past the farthest planet. I first check the planets in the Tracking Station and all where illuminated the same, as expected. I then checked the landed probe and the surface was very brightly illuminated with the same intensity as the inner planets, which was unexpected. When I moved my orbiting probe closer to or farther away from the sun, its illumination did not change. From this I concluded that all these lighting conditions were being controlled by ScaledIntesnityCurve, because they all exhibited behavior consistent with the change I made to that curve. I then retuned ScaledIntensityCurve to what I had it originally and instead changed IntensityCurve to a curve that provided equal intensity across all planet distances. With this set up all the lighting in the game returned to what it was originally, with sunlight intensity diminishing with distance in all game modes, consistent with ScaledIntensityCurve. All indications where that changing IntensityCurve had no affect on any of the lighting conditions I could observe in the game.

I welcome you to do your own tests, but I already checked that out. The illumination on the vessel was also controlled by ScaledIntensityCurve.