OhioBob

By flightmode I'm referring to the screen where I see and am actively controlling a vessel. So in that case I can see the PQS of a planet if close enough, or the scaled version if farther away. Then of course there is the solar illumination on the vessel itself. Do you know what curve applies to the illumination of the vessel? Of course the problem I've reported is that even when I'm seeing the PQS of the planet, its illumination is still being determined by ScaledIntensityCurve. Making changes to IntensityCurve doesn't do anything in the game. But if I edit ScaledIntensityCurve, the illumination changes for everything.

It's my impression that it's just something @KerikBalm made for himself (but he'll have to verify that). I'm not aware of any mod that makes that change.

That's a good point about processing power. Might not be worth it. I could live with MapMode and TrackingStation being the same, but I like the idea of doing FlightMode differently. I thought that's what we had with IntensityCurve and ScaledIntensityCurve (except it doesn't seem to working correctly at present). But I'm concerned about the transition between PQS and scaled space while in FlightMode. While I might want to use different lighting in MapMode/TrackingStation, I don't want it to create a weird lighting change when moving through that transition in FlightMode. If it does, then I would probably elect to make IntensityCurve and ScaledIntensityCurve the same. And that kind of defeats the purpose of having the two different curves. By the way, I've heard that IntensityCurve and ScaledIntensityCurve use different distance units - meters for IntensityCurve, and meters/6000 for ScaledIntensityCurve. Can you verify that? What about IVAIntensityCurve?

Yes, I'm aware IVAIntensityCurve already exists. I think it would be nice if MapMode and TrackingStation could have separate intensity curves, but if they are the same as far as KSP is concerned with no way to differentiate them, well then so be it. It may just be wishful thinking on my part.

@Thomas P., @Sigma88, here's something else I want to run by you guys regarding sunlight intensity curves. As I understand it, IntensityCurve controls the intensity in flight mode, i.e. the lighting on vessels and nearby celestial bodies. ScaledIntensityCurve controls the intensity in scaled space, i.e. map mode and tracking station. Is that correct? What I'm uncertain about, and what I was trying to test, is what happens in flight mode when moving away from a celestial body and transitioning from a PQS rendered surface to scaled space, or vice versa. If IntensityCurve and ScaledIntensityCurve have different values, will we see a change in light intensity when moving through that transition? That's when I discovered the bug that I reported in my last post (ScaledIntensityCurve is currently used in both flight and map/tracking station modes, while IntensityCurve apparently does nothing). Although I wasn't able to complete my test (because of the bug), it did get me thinking about something. Perhaps it would be more useful to have intensity curves for each game mode, rather than distinguishing between scaled space and not scaled space. I don't know if such a thing is possible to do, but perhaps there could be curves like this, FlightModeIntensityCurve (both near and far conditions) IVAIntensityCurve MapModeIntensityCurve TrackingStationIntensityCurve For instance, I might want to have Flight, IVA, and Map modes render sunlight intensity realistically, i.e. decreasing with increasing distance from the sun. But I might want to show all the bodies in the Tracking Station with the same bright illumination. By differentiating all those modes, it would provide greater flexibility.

Although it sounds like you already have it figured out, I'd recommend something like the following for the Sun. The @ is used only when you're changing an existing item. Since there are no existing intensity curves, you don't use @. You might also want to remove the existing intensity parameters, which are being replaced by the curves. The ! tag removes an item. If you are unsure, you can use %, which changes an item if it is exists, or adds it if it doesn't. @Kopernicus:AFTER[Kopernicus] { @Body[Sun] { @ScaledVersion { @Light { !sunlightIntensity !scaledSunlightIntensity !IVASunIntensity IntensityCurve { key = 0 0.30 key = 100000 0.28 key = 200000 0.26 key = 400000 0.24 key = 800000 0.22 key = 1600000 0.20 key = 3200000 0.18 key = 6400000 0.16 key = 12800000 0.14 key = 25600000 0.12 key = 51200000 0.10 key = 102400000 0.08 key = 204800000 0.06 key = 250000000 0 } ScaledIntensityCurve { key = 0 0.30 key = 100000 0.28 key = 200000 0.26 key = 400000 0.24 key = 800000 0.22 key = 1600000 0.20 key = 3200000 0.18 key = 6400000 0.16 key = 12800000 0.14 key = 25600000 0.12 key = 51200000 0.10 key = 102400000 0.08 key = 204800000 0.06 key = 250000000 0 } IVAIntensityCurve { key = 0 0.35 key = 100000 0.34 key = 200000 0.32 key = 400000 0.30 key = 800000 0.28 key = 1600000 0.26 key = 3200000 0.24 key = 6400000 0.22 key = 12800000 0.20 key = 25600000 0.17 key = 51200000 0.13 key = 102400000 0.08 key = 204800000 0.03 key = 250000000 0 } } } } } I'm not 100% sure whether ScaledVersion and Light require the @ or not. I think so, but if it doesn't work you can try removing them.

If I were to change Eve, those would be the exact same changes I'd make. I think its surface gravity is currently too high for its size, and to add some difficulty back for having reduced the gravity, increase the atmospheric pressure.

FYI, I think I just discovered a bug in IntensityCurve...

@Thomas P., @Sigma88, I just reported this as an issue on GitHub, but I thought I'd post it here as well... I don't think IntensityCurve is working as intended, or at least not as I understand it. I recently tried an experiment in which I used different values for IntensityCurve and ScaledIntensityCurve, in the hope that I could create different lighting conditions in map/tracking station mode versus flight mode. What I found is that the lighting in all modes is currently being controlled by ScaledIntensityCurve. From what I could determine, IntensityCurve currently doesn't do anything.

I don't really see anything wrong with the intensity curves per se, but I can see why the stars may be projecting light that far. The distances in the curves are kilometers/6000. So dividing your star's semimajor axis by 6000 we get, 1164929338593 / 6000 = 194154890 So that means at that distance your star should still be casting light with an intensity of a little greater than 0.10. If sun has a similar curve, then you should still be able to see its light around your star. Does that sound right, or are you seeing something else?

Rescue Me?

I suspect what happened is the old cache file was created when your planet was still using Laythe's old textures. Anytime you do something that changes the shape of a body (heightmap or PQSmod changes), you should delete the cache and let Kopernicus rebuild it.

High orbit is above 1 million kilometers, low orbit is between 1 million km and 1,600 km (which is the start of the atmosphere). I don't know if it even possible to reach 1 million km without overheating.

@Walesdark, try deleting the cache, i.e. the .bin file created by Kopernicus. Deleting it will force Kopernicus to create a new one. I'm not certain that's your problem, but it's a good place to start. If your planet cfg doesn't specify the cache file location, you will find it in the folder Kopernicus/Cache.

Pretty much everything in the GPP star configs where a collaborative effort between @Galileo and I. He did everything with the color settings and textures, and I did stuff like the intensity and brightness curves. So if you have any other questions, I should be able to answer. One thing about GPP is that we're actually using several different intensity curves, so you have to be careful about what you're looking at. For instance, the default ones in the Ciro.cfg are written to maintain a constant light level out to beyond the farthest planet. These are then replaced by the curves in the file SunCurve.cfg. This was done so that if somebody doesn't like the decreasing intensity, they can revert back to the old look by deleting SunCurve.cfg. There are also different curves for regular GPP and GPP_Secondary. We also recently decided to decrease Ciro's light intensity out around Grannus, so I tweaked the curves - they no longer match the one given in my first post. If you have questions about any of it, I'm happy to answer.

I don't know if there are any tutorials, but I've got intensity curves figured out pretty well. Below is a reproduction of the post I made in the Kopernicus thread explaining how I've done the sunlight intensity curves for GPP. In each key the four numbers are distance, intensity, and in/out slopes. Distance is kilometers divided by 6 (weird, I know, but that's what it is). Intensity just varies from 1 for maximum to 0 for no illumination. The last key is the distance at which the star no longer casts any light (in this example, the max distance is about 3 billion kilometers). CORRECTION: Distance in ScaledIntensityCurve is km/6, or meters/6000, but IntensityCurve and IVAIntensityCurve use units of meters. If you have a brighter star that has greater reach, or a faint one that has less reach, then I recommend simply factoring the distances up or down. For instance, if you want your star to cast light out to a maximum distance of 6 billion km, then double all the distances. Changing distances require that you recompute the slopes. There are actually a total of three curves that you must create, which replace the old settings of sunlightIntensity, scaledSunlightIntensity, and IVASunIntensity. These curves are, IntensityCurve{} ScaledIntensityCurve{} IVAIntensityCurve{} I recommend using identical curves for IntensityCurve and ScaledIntensityCurve. For IVAIntensityCurve you might want the light to be a bit more subdued, which you can do by simply factoring the intensities. For GPP I multiplied all the intensities by 0.9 for my IVAIntensityCurve. Changing intensities also requires that you recompute the slopes.

I'd say my most exciting moment was the first time I successful landed a unmanned probe on Mun. By accomplishing that feat I felt like I was really starting to figure the game out (the steep part of the learning curve was behind me). I was excited for not only achieving that particular milestone, but also for the future possibilities that it represented.

I wouldn't do much. If I wanted to make big changes, I'd just start from scratch and create an entirely new solar system. That being said, there are a few things about the stock system that bugs me from a realism point of view. Just a few tweaks here and there would take care of it. Some of the atmospheres aren't very realistic, but I've already fixed that with Realistic Atmospheres. Kerbol is really disproportioned compared to the other bodies. I'd reduced it's radius and give it properties consistent with real life main sequence stars (similar to Ciro is GPP). I think Eve is too dense, so I'd lower it's surface gravity to about 1.2 g. To compensate for Eve's lower gravity and keep it a difficult place to launch from, I'd probably bump its surface air pressure to 10 atm. I think Jool is not dense enough for its size, so I'd increase it's surface gravity to about 1.2 g. Mun is way too close to Kerbin (at its current distance, Kerbin would be tidally locked to Mun). I'd move Mun out to a semimajor axis of about 38,000 km. There might be a few other tweaks that I'd consider, but these are the main ones. (These changes assume the stock bodies are at a scale that is 1/10th the radius and 1/100th the mass of their real life counterparts.)

Yes, for airless worlds it was correct. Where I had a problem was with atmospheres. I don't remember, however, if it overestimated or underestimated drag, but the results were always consistent. My recollection is that it underestimated drag, which seems to agree with your experience. As I recall, my landings always came up short of the predicted position, and when aerobraking I always got an apoapsis lower than predicted.

How accurate is the Trajectories mod these days? I tried it out about a year ago, maybe more, and I was disappointed in its accuracy. For a return from Mun/Minmus, I got much better results using my method described earlier in this thread. Since I could do a better job without it, I uninstalled Trajectories and haven't tried it since. Has it gotten better since then?

I don't know when, but yes, I think it has changed. I started playing in 2014 and Eve has always looked the same since then. But I've seen maps of Eve from an earlier time that looked different. Although it is apparently no longer active, there use to be a kerbalmaps.com web site. The Eve map on that site showed a different Eve than the one we have today.

Low TWR is best for cost efficiency, but I think anything below 1.2 is too low. I generally aim for something between 1.2 and 1.5 at liftoff, but as close to the middle (1.35) as possible. Lower on the second stage, probably more like 1.0-1.2. And although it hasn't been mentioned, I generally like to distribute the propellant about 2:1 between the first and second stages. I find that if the second stage has a propellant mass approximately equal to the mass of the payload, the first stage has a propellant mass twice that of the second, and the TWR falls within the target ranges, then I get a launch vehicle that performs pretty well. I use these guidelines for all my launch vehicles. (These standards are for the stock game and do not apply to larger scales.)

Just as a side note... @meanAnomalyAtEpoch is where a body is in its orbit, and @epoch is when it is there. I'm sure RSS has a reason for using those settings, but for most mod packs it doesn't make much sense to use an epoch equal to anything but zero, which is the start time of a new game. If you want to change the initial starting position of a body, it makes more sense to alter @meanAnomalyAtEpoch. Mean anomaly is measured in radians from the body's periapsis. Epoch is measured in seconds from the initial start time of a new game, i.e. Y1, D1 0:00:00. (edit) Then again, I suppose it makes just a much sense to set @meanAnomalyAtEpoch to zero, i.e. the planet is located at its periapsis, and then use @epoch to specify the time that it was last there.

TextureReplacer

This might give you some ideas... https://engineering.purdue.edu/AAC/wp-content/uploads/2012/09/FastMarsFreeReturnsviaVenusGravityAssist-AIAA-2014-4109.pdf