OhioBob

Thanks, guys. That's a much appreciated addition.

Drag is a complex calculation in KSP. Each face of each part has its own drag coefficient, which is modified according to Mach number and orientation to the air flow. The drag produced by each part is computed separately and then those values are summed to get the total drag. The vehicle as a complete unit has no drag coefficient that you can look up. All you can really do it take measurements during flight tests and deduce the drag coefficient from the measurements, which might allow you to derive an empirical formula. If you go to the cheat/debug menu, you can open the Aero GUI window. This will display aerodynamic data in real time. A couple properties displayed are dynamic pressure and ballistic coefficient. If you take the mass of the vehicle and divide it by the ballistic coefficient, that gives you the product CdA. Multiply CdA by the dynamic pressure and that's the drag. You really don't need to know the drag coefficient by itself, CdA will suffice for any calculations you need to perform. But if you really insist on knowing Cd alone, then just divide CdA by the reference area. The reference area is whatever you define it to be, like cross-sectional area of the rocket.

I don't remember if it's Porkjet's or not, but somebody's Mk1 command pod has a critical flaw in it. The bottom of the pod it too rounded. When a heat shield is attached, the very bottom of the pod sticks through the shield and is left exposed and unprotected. If that's Prokjet's Mk1, and I think it is, I don't recommend using it.

I still think the "gray" color scheme in the DLC looks green. Don't know why but it just does. For some reason my eyes tend to perceive gray as slightly green, at least when there are other colors in the image. I don't have that problem when I'm looking at a strictly black and white image.

It's the gray and orange that I'm talking about. To me that gray looks like a drab green, but maybe my eyes are just playing tricks on me. I have, however, seen photos of the real life article that looks distinctly green... That is green, isn't it? Looks way more green to me than it does gray.

@Snark, I've looked over your mod and I'm amazed by how much your changes exactly mirror my own thoughts. I was planning to mod the game myself, but now I don't have to. What you've done is almost exactly what I would have done had I done it myself. Even adding in those few extra Porkjet engines was on my to do list (the DLC didn't do anything to address some gaps among the small sized engines). This is, in my opinion, the perfect compliment to the DLC. Between the DLC and this, I don't think I really need any other part mods. Thanks for making it.

@Snark, @Jarin, et al. If you guys do make switchable textures for the 1.25 m tanks, I'd like to make a suggestion. The 1.25 m tanks really need to also have a drab green gray Vostok/Voskhod texture like those available on the 1.875 m tanks. I don't know if you've ever noticed before, but the center core of the first stage of all the R-7 derived launchers has a smaller diameter than the max diameter of the upper stages and the strap-ons. Here's a picture showing it: To make a proper Vostok/Voskhod replica, that section of the rocket really needs to be made using 1.25 m tanks. The RK-7 Kodiak engine is even made with a selectable 1.25 m shroud specifically for connecting to that size tank. All the parts are available for a realistic Vostok/Voskhod replica, but without the ability to change the texture on the 1.25 m tanks, it looks like dog poo. The option to change that texture to the green gray should have been made part of the DLC, but it wasn't. If you guys can make that happen, it would be fantastic. BTW, thanks much for this mod. It is exactly what I wanted and needed.

Thanks, @Galileo. @EleSigma, try replacing Sirona's ring texture with this one (1024x64): http://www.braeunig.us/KSP/GEP/Sirona_ring.dds Hopefully that will fix the problem. Please let me know what happens. I'll include the revision in the next GEP update.

@EleSigma, here is Sarnus' ring config: Ring { angle = 0 innerRadius = 1250 outerRadius = 2250 texture = OPM/OPM_Textures/Sarnus_ring color = 1,1,1,1 lockRotation = true unlit = False useNewShader = True penumbraMultipler = 10.0 } And here's Sirona's: Ring { angle = 0 outerRadius = 2333 innerRadius = 1333 texture = GEP/GEP_Textures/PluginData/Sirona_ring.dds color = 0.5,0.5,0.5,0.5 lockRotation = False unlit = False useNewShader = True penumbraMultipler = 10.0 } The immediate differences that I see are inner/outer radii, lockRotation, and the color. I wouldn't think any of those would cause the problem you're seeing, but who knows. I've been wrong about that stuff before. Since I might not be able to reproduce the problem on my computer, can you run an experiment for me? Can you try changing all the Sirona ring configs to those used for Sarnus (except for the texture) and see if that makes a difference? You can find the settings in GEP/GEP_Bodies/Sirona.cfg. If that makes no difference, then we can eliminate those as the cause. If none of those other settings makes difference, can you then try changing Sirona's ring texture to point to Sarnus'. If you then get Sirona in game with Sarnus' ring, then we know there might be something wrong with Sirona's ring texture. I see that Sirona's ring texture is .dds and resides in a PluginData folder, while Sarnus' ring texture is .png and is outside of PluginData. Maybe that's causing some problem. However, the way I did it is the same as it's done in GPP, and you said GPP's rings are fine. So I find it puzzling that it would work for GPP and not GEP. I'll also try changing my graphics settings to the same ones that you typically use to see if I can reproduce the problem in my game. If so, then that will allow me to run tests for myself. I've got to run out for awhile first, so I won't get to it for probably a couple hours. Also note that I have no idea what's going to happen when Kopernicus upgrades to 1.4.1. That could change some things. It might not be worth putting in too much effort on this issue until everything gets upgrade. Whatever we do now might be obsolete in a few days.

That's puzzling. I'll have to look at the configs to see if I can find anything different between them. Thanks for running the test.

@EleSigma, that's interesting. I've never tested it with all those graphics settings turned down like that. I have my settings pretty high. Odd that only Sirona's ring is affected by it. I'm guessing it's probably because Sirona orbits a secondary star. I know there are a lot of things that are buggy when there are multiple stars. If you have the time to run an experiment, try installing OPM as well and see if you have the same problem with Sarnus' ring. @Galileo, do you have any ideas on how to fix this problem?

@EleSigma, I've never seen that problem before. What versions of everything are you using? The following works for me: KSP 1.3.1 Kopernicus 1.3.1-7 GPP 1.6.1.2 GEP 0.9.0.0 EVE 1.2.2-1 If you are using anything different, I can't guarantee it will work.

The current version of Eve Optimized Engines works with KSP 1.4.0.

RSS isn't updated for 1.3. But I believe there is a patch somewhere that makes it work. You'll just have to go back through the thread until you find it.

It's included in the RSS download... RealSolarSystem/Compatibility/PlanetShineColors.cfg

When you start a new game, click the "Difficulty Options" button. While on the "Basic" window, turn on "Enable Comm Network". Next click the "Advanced Button" to switch the advanced settings window. Turn on "Enable Extra Groundstations". If you want to change an existing game, the press ESC while at the main KSC screen. In the window that pops up, click the "Settings" button. At the top of the settings window is a "Difficulty Settings" button. Click that and then the rest is as previously described. You may need to restart KSP for the change to take effect.

What you are doing sounds like what the mod Gravity Turn does, which is a launch autopilot. It has the ability to learn from previous launches. Gravity Turn sets when and by how much the initial turn is. It makes a more aggressive turn each successive launch as long as the dV to orbit is decreasing. But as soon as the dV starts to go up (because of excessive drag), it reverses direction, followed by small back and forth adjustments until it finds the optimum.

Yes. It doesn't do anything to change the topography, but it applies better looking textures to the surface.

My atmosphere creation tools are now available as interactive online tools that you can access and use through your web browser. There's no longer a need to download the spreadsheets or have Excel installed on your computer. You can find the web page links in the opening post. Edit... The online versions are no longer available.

The radiation belts work OK as I recall, but you'll have problems with solar panels. Kerbalism is incompatible with Kopernicus' solar panel module for multiple stars. Rather than fix the problem, Kerbalism just disables Kopernicus' solar panels. Therefore any of Kopernicus' solar panel features aren't present, and solar panels won't work at all around any star other than Ciro. If you just want to play GPP as a single star system, then you might be OK. But if you plan to visit Grannus or use any of the expansion mods like GEP or OPM, then you'll definitely have problems. And if any other issues crop up, you'll likely not get help from the GPP devs because we don't support Kerbalism. And I don't think the Kerbalism dev is supporting it any longer either.

GPP hasn't had Kerbalism support since before version 1.5.0 (released last September). Kerbalism doesn't support multiple star systems, and since GPP is a binary star system, we dropped support because it didn't work right. The Kerbalism dev promised to add GPP support on his end, but it looks like he has since abandoned work on the mod. So in short, GPP and Kerbalism don't work together and likely never will.

I know of somebody else who was having some weird problems like that, though I don't really recall all the details. I loaded up his mod and got the same problems. I resaved his images in the format/compression that I typically use and it started working for me. I'm not sure if he ever did get it working right on his end.

I second what @Kryxal just wrote. My advice is to try to minimize the delta-v that a particular rocket requires to get to orbit, but don't design your rocket solely for the purpose of lowering the delta-v it requires to get to orbit. The first part of that means you're flying your particular rocket as efficiently as possible, which is good. The second part means you could be making some ill-advised design choices. Delta-v is not necessarily the best metric by which to measure how well your launch vehicle performs, so don't obsess over trying to reduce it. As Kryxal said, trying to get to orbit for really low delta-v values generally means that you require a high TWR, which means big powerful engines. It is usually best to trade big expensive engines for cheap fuel. This means you'll have lower TWR and greater gravity losses, but it will cost less. A rocket that takes 3400 m/s to get to orbit could very well be a better launch vehicle from an economics standpoint than one that takes 3200 m/s to get to orbit.

I don't think I've ever seen that problem before. If it's OK up close but messed up far away, it sounds like there's something wrong with your ScaledVersion. I notice you're using .jpg images for your texture and normal maps. I don't recall ever seeing .jpg used. Maybe that has something to do with your problem. I typically use the following file types: Color map - .dds DXT1 when no transparency is required, and .dds DXT5 when transparency is required. Normal map - .dds DXT5nm. Height map - .dds L8, or .png greyscale 8-bit. Save all .dds images color and normal maps with mipmaps. Other than that, the only other thing that jumps out at me it that you haven't given your body a template. I've never seen a config without a template, so I don't know what problems that might cause.

Can you post your config and a screenshot?