OhioBob

No, you want one Kopernicus folder. There shouldn't be anything in KSP/GameData/GameData. In the Kopernicus download is a folder GameData, inside of which are two folders - Kopernicus and ModularFlightIntegrator. Copy those two folders to your KSP/GameData folder. You also need ModuleManager, but the one in the Kopernicus download is outdated. You should download and install ModuleManager.3.0.1.dll, which should also be placed inside KSP/GameData. Also make sure you followed the SSRSS install instructions exactly. There are several components that you have to download and install separately: SSRSS, RSS, RSS Textures, Sigma Dimensions, and Kopernicus. If you're getting that Kopernicus error, then you didn't install something correctly. For instance, omitting the textures will trigger that error message.

The only way to do that would be to resize the textures in something like Photoshop or GIMP. You want to change them from 4096x2048 to 2048x1024, and then make sure to resave them in the correct format (you'll need a dds plugin). If you don't have the means to do that, then you're out of luck unless somebody is willing to do it for you. There's about 120 textures in all, give or take. If you want to give it a try, I or one of the other developers can give you the information on format and compression types. Also note that some of the format types are changing in the next GPP release, which should reduce RAM usage to some extent.

That's because SSRSS hasn't been updated yet to be fully compatible with the lastest Kopernicus. While you're waiting for an update, just delete the following file and it should work OK: SSRSS/configs/SunCurve.cfg

Clouds and city lights are parts of SVE, not SVT. Better check to make sure you installed SVE correctly. You need to download and install SVE, SVE Textures, and EVE. If you think you did all that, then we're going to need more information. How about a screenshot of your GameData folder for starters.

Yes, the planet actually spins slower. You'll lose quite a bit of the benefit of an eastward launch. (edit) Alternatively, if you want the actual rotation period to remain 8 hours, but you want a 24-hour clock, then just don't install Kronometer.

We can't help you if you don't help us. Just saying it doesn't work tells us nothing about what might be wrong. We need more information about your installation.

If you're playing SSRSS and want Earth days to be 24 hours, try the following and see if it works. Just copy and paste to a .cfg file and place it inside your GameData folder. @Kopernicus:BEFORE[SigDim2]:NEEDS[SigDim] { @Body:HAS[#name[Kerbin]] { @SigmaDimensions { @dayLengthMultiplier = 1 } } }

If you did everything correctly, you shouldn't get that message. It's impossible to diagnose your problem without more information.

Here are the EVE releases: https://github.com/WazWaz/EnvironmentalVisualEnhancements/releases You want the download the file named "EnvironmentalVisualEnhancements-1.2.2.1.zip", not the one named "EnvironmentalVisualEnhancements-Configs-1.2.2.1.zip".

Are you using old Sigma Dimensions too? You're probably going to have to look through all the Sigma Dimension releases until you find the one that's compatible with your KSP and Kopernicus versions. https://github.com/Sigma88/Sigma-Dimensions/releases

I don't know of any mods that look as good as that image. However, if you're looking for something to improve the stock visuals, I suggest you start with the following:

You're correct that this is not a "best TWR" discussion per se, but it is part of the discussion. The OP said that 1.2 TWR is one of his standard benchmarks and asked what specifications we use. So it's not just about subassemblies, it's also about what benchmarks/specifications we use, of which TWR is a big part. I made a post in which I said my preferred liftoff TWR is 1.3-1.4. That was followed a couple posts later by Tyko asking me why, to which I explained my philosophy on why I believe low TWR equates to low cost. In the middle of that you made a post in which you provided a design that sets the TWR to 2.0. I figured that some people might find it confusing why one poster is advocating for low TWR, while another posts a design using high TWR. So I just explained the difference. The specifications that we choose and why (which was the OP's question) can vary depending on design strategy.

What I find works pretty well is to give the second stage (the upper stage) a mass of propellant approximately equal to the mass of the payload. And the first stage (the lower stage) a mass of propellant equal to two times the mass of the payload. In this case the "payload" is everything that sits on top of the second stage, thus it includes the mass of decouplers, fairings, etc. You might have to tweak it a little bit, but generally those ratios result in a rocket that performs quite well.

There are few members of this forum whom I respect more than @Snark. He's quick to respond to questions and always provides good quality answers and advice, with which I almost always agree. However, these "best TWR" threads crop up frequently and Snark and I always post very different recommendations. I always advocate for the low TWR approach, while he routinely suggests a much higher TWR, around 2. But there's a very good reason why we seemingly disagree. Snark prefers and makes extensive use of solid-fueled boosters, while I prefer liquid-fueled boosters. That makes a big difference. My way of lowering the TWR of a liquid-fueled booster is to pack on as much propellant as its engines can reasonably lift (or by using smaller or fewer engines). This is not an option with SRBs. An SRB is a self-contained unit that has a finite amount of propellant. We can't add more propellant to an SRB, we can only add more SRBs. This means that SRBs by there very nature are going to have a high TWR. Since we can't lower the TWR by adding more propellant, the only way to decrease the TWR is by thrust limiting. I never advocate thrust limiting unless the TWR is just going to be ridiculously high if we don't. I believe that if you have the thrust, use it. So when making a first stage by clustering together SRBs, I agree with Snark that a high TWR is probably the way to go because it's going to reduce the gravity losses. But when using a liquid-fueled first stage, decreasing engine size and/or adding propellant, thereby lowering TWR, is going to get your payload to orbit for the least cost (even though the delta-v requirement may be greater).

I don't judge the effectiveness of my launchers based on delta-v. I look at cost per ton of payload. For any given engine, loading it up with as much fuel as it can carry will get the most payload to orbit for the least cost. Yes, the gravity losses will be greater, and I'll expend more delta-v getting to orbit, but I don't care about that. Generally speaking, low TWR yields the best cost efficiency, at least when using liquid fueled rockets.

I use to use standard subassemblies, but I stopped doing that. That was back in version 0.90 before the current aerodynamics, so any standards that I used are no longer applicable. Now when I build a launch vehicle I try to follow these guidelines as closely as possible: Second (upper) stage: propellant mass = 1 x payload mass, TWR = 1 to 1.2 First (lower) stage: propellant mass = 2 x payload mass, TWR = 1.3 to 1.4 where "payload mass" refers to everything that sits on top of the second stage, including decouplers, fairings, and maybe even a third stage. This configuration will usually produce a delta-v of around 3400 m/s depending which engines are used.

You've already gotten a lot of good advice here, but I would like to add just one more thing on the parachute question. To achieve the same speed of decent, a vehicle on Eve requires about 1/3 as much parachute area as an identical vehicle on Kerbin. We can compute this using the equation for terminal velocity, If we want the same speed of decent, i.e. the same terminal velocity, on both planets, then we just have to do this, SQRT( 2 * m * gK / ( ρK * AK * Cd ) ) = SQRT( 2 * m * gE / ( ρE * AE * Cd ) ) where subscript K refers to Kerbin and subscript E refers to Eve. The mass m and drag coefficient Cd are the same on both sides because it's assumed we have the same sized vehicle using the same type of parachutes. We can now simplify by squaring both sides and canceling out the like terms, gK / ( ρK * AK ) = gE / ( ρE * AE ) We can further rearrange like this, AE / AK = ( gE * ρK ) / ( gK * ρE ) So we can now solve for the ratio of the parachute areas by plugging in the values for gravity and air density on Kerbin and Eve. For air density we don't need to know the exact values, the relative value will do. The air on Eve is about 5 times as dense as air on Kerbin*. AE / AK = ( 1.7 * 1 ) / ( 1 * 5 ) = 0.34 Assuming we're using the same type and size of parachute, then we need only 0.34 times as many of them on Eve to fall at the same speed as we would on Kerbin. * Note that the formula uses air density, not air pressure. Density is a function of not only pressure but also of gas molecular weight and temperature. So while I used a 5:1 ratio of Eve density to Kerbin density, that's not because Eve's air pressure is 5 times greater. It is just a coincidence in this case that the ratio of the density is the same as the ratio of the pressure. The molecular weight of Eve air is about 1.5 greater than Kerbin air, but Eve is also about 1.5 times hotter. Those factors happen to almost exactly cancel out so we end up with Eve air near the surface being about 5 times denser than Kerbin air. This same type of calculation can be performed to find the parachute ratio for any two planets.

I would say the fastest way to any planet is a one-tangent burn (figure 4.12). Just use as much of your 10,000 m/s delta-v as you can afford to shorten the trip as much as possible. Gravity assists are used to save fuel, not time.

As long as you're talking asteroids, here's a something I wrote a few months ago about the asteroid size curve. You might find it useful...

Are you sure that's working? According to the Sigma Dimension definitions: That last sentence is important... CustomSoISize factors the SOI radius only when the parameter sphereOfInfluence is defined in the body's config. It's pretty rare that the SOI radius is defined by the mod developer. That's usually only done in special cases. The only body is SSRSS that I know of to use the sphereOfInfluence parameter is Phobos. When sphereOfInfluence is not defined, KSP computes the SOI radius using the equation, SOI = d * (m / M)0.4 where d is the distance between the bodies (KSP uses semimajor axis), m is the mass of the smaller body, and M is the mass of the larger body. In a rescaled system the ratio of the masses stays the same, so SOI changes proportional to "d". Since d is the semimajor axis, and the semimajor axis is factored by the parameter Rescale, then the SOI changes proportionally to Rescale.

No, that is intended. The length of day multiplier for 10x is 2.

I don't see ModularFlightIntegrator. It comes packaged with Kopernicus and must be installed. You might also want to upgrade ModuleManager to version 3.0.1.

How about a screenshot of your GameData folder? Seeing what you have installed would be a big help. Also, you shouldn't change the config inside the Sigma folder. That won't do anything anyway because RESCALE overwrites all those settings.

That's odd, I don't know why that would be. Unless a custom SOI radius is specified in the config, SOI are calculated by KSP. In the original RSS Phobos.cfg no SOI radius is given, however, SSRSS gives it a radius of 9059 meters. Sigma Dimensions factors the SOI radius only when SOI is user defined, else KSP computes it. Sigma multiplies it by the parameter CustomeSoISize if defined, else it multiplies it the Rescale factor. The global setting in SSRSS is to use the Rescale factor, except bodies with a Bop template (Phobos and Deimos) have CustomeSoISize = 2. Therefore Deimos' SOI should be 9059 * 2 = 18,118 meters. If you're getting 2 km, then there is definitely some unintended screwiness going on.

If you want to land at a spot under the apoapsis, you have no choice but to lower the apoapsis. The only other thing to do is wait until the area under the peraipsis is in daylight (which it will be eventually). (edit) Based on what I see in the screenshot, performing a retro-burn at periapsis should take only 62 m/s delta-v to circularize the orbit at an altitude of 6,475 km. That's pretty minor and shouldn't cost much fuel at all. Thankfully Minmus has really low gravity, so orbital maneuvers are pretty cheap to perform.